{"slug": "production-ready-software-development-at-the-speed-of-thought", "title": "Production-ready software development at the speed of thought", "summary": "After six years of research, four years working with LLMs, and almost a year of agentic coding in a production-ready environment, software developer and researcher Osequi concluded that LLMs with the right guardrails and tools can safely automate the design, implementation, and verification of production-ready software, leaving humans to understand the problem and steer the machine toward a solution. In January 2026, after the Claude Code hype settled, Osequi began implementing a production-ready version of the Olog editor, aiming to \"vibecode\" the new web app with strong guardrails using battle-tested React, Next.js and TypeScript templates. The study covers the implementation and verification phases of the software development life cycle, arguing that almost every SDLC step is formally or semi-formally specifiable and thus verifiable cost-effectively by new tools and services.", "body_md": "# Speed of thought\n\nLLMs—with the right guardrails and tools—can safely automate the design, implementation, and verification of production-ready software. What’s left for humans is to understand the problem and steer the machine toward a solution. This is production-ready software development at the speed of thought.\n\n## Background\n\nAfter six years of research, four years working with LLMs, almost a year of agentic coding in a production-ready environment, I found that:\n\n- LLMs are truly useful for generating verifiable outputs\n- Almost every step in the SDLC process is formally or semi-formally specifiable, and thus verifiable in a cost-effective way by new tools and services\n\nLLMs do the heavy lifting. They are indispensable when creating production-ready software.\n\n## Research\n\n          In autumn 2022, when ChatGPT came out, I started a journey to find a\n          method for creating\n          [likely-correct software](https://www.osequi.com/slides/likely-correct-software/likely-correct-software.html)\n          through\n          [rapid iterations](https://www.osequi.com/slides/rapid-iteration/rapid-iteration.html).\n        \n\n          Last year, I presented a\n          [study](https://www.osequi.com/studies/list/list.html) on\n          how to use a mix of formal and semi-formal methods to achieve\n          likely-correct understanding and design—the first two phases of the\n          software development life cycle (SDLC).\n        \n\nThis year I cover the next two phases: implementation and verification—again—the likely-correct way. The remaining phases, deployment and maintenance, are not relevant in this context.\n\nThe goal of these studies is to find out what is possible in terms of correctness, and at what cost, in software development. To find a pragmatic approach to LLMs, to discover where they are truly useful and what we can do to make them truly useful. To eliminate the unpleasant surprises they often throw at us.\n\nThe final goal is to create better software faster.\n\n## Production-ready code, faster\n\nThere is no exact definition of what production-ready software is or how to create it. There is broad agreement that such software is:\n\n- Fully tested—from specifications to code—throughout all the phases of the SDLC\n- It is built for the long run. It’s not the first iteration. That would be an MVP, a prototype, a proof of concept\n- It is designed to evolve through rapid iterations and to face the challenges of real-world, large-scale use\n\n          You can see an example of production-ready code in\n          [A likely-correct list](https://www.osequi.com/studies/list/list.html), a prequel to this current study.\n        \n\nThe study presents:\n\n- The main aspects (Information Architecture), the process and the deliverables (SDLC) of a production-ready code\n- How these parts relate to formalism, correctness and cost\n- How, and which, formal and semi-formal methods ensure likely-correct deliverables and rapid iterations\n\nThe study concludes:\n\n            And in a future stage, it should provide AI/ML practitioners with\n            insights to combine generative AI’s speed with the rigor of these\n            new techniques to produce *better* software, faster.\n          \n\nNow let’s pick up from here.\n\nIn January 2026, after the Claude Code hype settled down, I decided to start the implementation of the production-ready version of the Olog editor—a project where the MVP received positive feedback and in which I saw potential for further investment. In my workflow, ologs ensure a likely-correct understanding of a problem domain.\n\nThe idea was to vibecode the new web app with strong guardrails.\n\nI had on hand a strong set of React, Next.js and Typescript templates created in Silicon Valley environments and battle-tested in production, ensuring that the written code was of high quality.\n\n          I had some strong opinions about an ideal code architecture.\n          Organizing and maintaining a codebase is\n          [a recurring top pain point](https://2023.stateofjs.com/en-US/usage/#top_js_pain_points)\n          for front-end developers and I had spent\n          [endless effort](http://metamn.io/react/) figuring it out.\n        \n\nIf it’s a pain point for humans it will be a pain point for LLMs. I asked the LLMs for help, and with three American and two Chinese models, we came up with such a solid production-ready architecture that they said they had never seen something similar before. Lol 😀\n\nIn the end, we’ve put together a generic multi-dimensional guardrail system in which:\n\n- The columns represent the app features\n- The rows represent the code architecture layers\n- A third, controlling dimension is error handling\n\nWith this toolset—my best knowledge ever—I started vibecoding the features one by one.\n\nA detailed workflow document would instruct the LLM how to implement a feature step by step across the architectural layers. My job was easy:\n\n- Feed in the specs\n- Make sure all the steps in the workflow are fully executed\n- Run all tests and achieve close to 100% code coverage\n- Verify the results live then create the end-to-end tests\n\n          We—the junior dev team provided by the LLM and I—were flying high. The\n          speed was right. The codebase looked promising. The investment in the\n          code architecture and the templates paid off. Even\n          [Simon Willison praised](https://news.ycombinator.com/item?id=48524489)\n          the results.\n        \n\n          On the other hand, the product experience was strange. Subtle user\n          interface errors, messy business logic, once-fixed problems\n          resurfacing, code smells, inconsistency, duplicated code, ghost code.\n          I had a bad feeling—[We were not ready for production](https://news.ycombinator.com/item?id=48421559).\n        \n\nAlso the Claude experience turned out to be awful. As the problems within the codebase grew that intellectual, tortured genius became more stubborn, over-refusing and always lecturing.\n\nWhat’s next?\n\nThe problem was that while the primary focus—implementing the specs—went almost flawlessly, the secondary focus—following the architectural layers and coding rules—drifted at a subtle level while it was looking good on the surface.\n\nTo fix this we’ve started a second iteration now focusing on the rows of the guardrail matrix, on the non-user-facing coding and organizational rules that make a product robust.\n\nWe also chose a much better harness (Opencode) and a coding agent with a dedicated engineering mindset (Deepseek Flash) at a fraction of the price and hassle.\n\nAlso changed the rules of the game with LLMs: Instruct — Never ask — Always verify.\n\n- From this point on, throughout the SDLC process, I’ll never ask for advice or brainstorm. I’ll handle this part myself using the old methods.\n- From now on, I give LLMs plain instructions to produce bite-sized chunks of code that I can skim for errors (ghost code, duplicated code, etc) without too much effort.\n\nThe result is more than promising.\n\nAfter two perpendicular iterations and an overarching, integrating error-management implementation I’ve got production-ready code: it follows the specs, it follows the rules, smells good, looks good, it is fully tested and easy to iterate on.\n\nI can affirm that the implementation and verification SDLC phases are safely doable with LLMs when the right guardrails, coding agents, and human supervisors are in place.\n\nWhy LLMs for I+V?\n\n- They write code and tests as well as humans, but orders of magnitude faster\n- They take these daunting, tiresome tasks completely off our shoulders\n- Writing code manually is now obsolete just as writing assembly code became obsolete when C, BASIC, and Pascal came onto the scene\n- Now software engineers can focus on higher levels of abstraction: pure problem solving vs. tiresome, good-old plumbing\n\n## Better production-ready code, faster\n\nWhile I was figuring out the magic formula ...\n\n          SDLC + LLM = U + LikelyCorrect(D) + SafelyAutomated(I + V)\n        \n\n... others reached the same or even better conclusions and created useful tools.\n\n          The age-old practice of\n          [Contract programming (Design by contract)](https://en.wikipedia.org/wiki/Design_by_contract)\n          took off in a new form—Vericode—and enhanced\n          [BDD to produce formally verified code](https://scidonia.ai/blog/from-bdd-to-proof/).\n        \n\n          A\n          [React/Typescript implementation](https://midspiral.com/),\n          which I’ll use in my next projects, comes with this thesis:\n        \n\n1. Humans define what should be built\n2. AI handles implementation\n3. Machines guarantee correctness\n\n          Meanwhile,\n          [Shopify went even further](https://shopify.engineering/shop-app-migration).\n        \n\nThey’ve managed to get the agents write specs (although from an existing production-ready app and its codebase) and implementation plans; then execute and verify these plans.\n\n          Before\n          [you get too excited](https://www.youtube.com/watch?v=vDjW_dRyKXY)\n          I should fill in the details about the invisible and hard work\n          [behind the scenes](https://shopify.engineering/helix) that\n          makes that possible. According to Shopify:\n        \n\n- Getting consistent, high-quality, and maintainable results out of the LLM black box is difficult\n- While the generated code satisfies the feature requirements it still introduces duplication, architectural drift, and performance problems\n- \n            Highly opinionated architecture, test coverage, rapid iterations\n            (verifiable chunks of output), visual and adversarial reviews are\n            the guardrails that make this picture *wondrous* .\n\n## Production-ready software at the speed of thought\n\n          In March 2024, the CIA presented\n          [a report](https://www.cia.gov/resources/csi/studies-in-intelligence/studies-in-intelligence-68-no-1-extracts-march-2024/future-of-intelligence-the-incalculable-element-the-promise-and-peril-of-artificial-intelligence/)\n          on the promise and peril of artificial intelligence concluding\n          “Generative AI is neither quite so wondrous nor quite so bleak”.\n        \n\nIn autumn 2026, I can confirm this. You cannot change the world with a single prompt, but you can safely automate most of the software development process.\n\n          Today in the SDLC+LLM process D+I+V are—*formally* and\n          *semi-formally*—solved.\n        \n\nNow agentic software development reduces to these steps:\n\n1. You start by understanding the problem domain\n2. (AI helps you) by sketching out the ontology and taxonomy in an Olog editor\n3. \n            In the [Stately FSM editor](https://stately.ai/) , you\n            model (together) how these parts behave and interact\n4. When the solution to the problem is clear you design the user interface and experience by using the concept design DSL\n5. Finally you let it loose: Using the guardrails and the vericoding techniques the AI creates the production-ready code\n\nThis is software development at the speed of thought.\n\n## Resources\n\n1. \n[Likely correct software](https://www.osequi.com/slides/likely-correct-software/likely-correct-software.html#/) — Osequi, 2023\n2. \n[Rapid iteration in software development](https://www.osequi.com/slides/rapid-iteration/rapid-iteration.html#/) — Osequi, 2023\n3. \n[A likely-correct list](https://www.osequi.com/studies/list/list.html) — Osequi, 2025\n4. \n[Future of Intelligence: “The Incalculable Element”: The Promise\n              and Peril of Artificial Intelligence](https://www.cia.gov/resources/csi/studies-in-intelligence/studies-in-intelligence-68-no-1-extracts-march-2024/future-of-intelligence-the-incalculable-element-the-promise-and-peril-of-artificial-intelligence/) — CIA, 2024\n5. \n[JavaScript Pain Points](https://2023.stateofjs.com/en-US/usage/#top_js_pain_points) — Stack Overflow, State Of Javascript, 2023\n6. \n[To React with best practices](http://metamn.io/react/) —\n            Metamn, 2018-2021\n7. \n[A Hacker News comment thread on Software Architecture Guide](https://news.ycombinator.com/item?id=48524489) — Simon Willison, 2026\n8. \n[A Hacker News comment thread on: Ask HN: Why is the HN crowd so\n              anti-AI?](https://news.ycombinator.com/item?id=48421559) — The author, 2026\n9. \n[Design by contract](https://en.wikipedia.org/wiki/Design_by_contract) — Wikipedia\n10. \n[From Vibecoding to Vericoding: A Gradient, Not a Jump](https://scidonia.ai/blog/from-bdd-to-proof/) — Scidonia, 2026\n11. [Midspiral](https://midspiral.com/) — 2026\n12. \n[Migrating Shop app from React Native to native](https://shopify.engineering/shop-app-migration) — Shopify, September 2026\n13. \n[Rails World 2026 Opening Keynote](https://www.youtube.com/watch?v=vDjW_dRyKXY) — DHH, September 2026\n14. \n[Helix: The internal tool powering our Shopify app's native\n              migration](https://shopify.engineering/helix) — Shopify, September 2026\n15. [Stately](https://stately.ai/) — 2026\n\n## About the author\n\n[The author](http://metamn.io/) holds a degree in\n          mathematics and computer science. He is a self-taught UX/UI designer\n          with works featured in online galleries.\n        \n\n          Recently, he has been running\n          [a research and development studio](https://www.osequi.com/)\n          specializing in software correctness and rapid iteration, providing\n          consulting services to companies.\n        \n\n## Credits\n\nThis document was created using Notion and published using a modified version of Tufte CSS.\n\n          It was checked with the Google Docs spell checker and the\n          `write-good` naive linter for English prose.\n        \n\nThen LLMs corrected the non-native English words and constructions—I’m inherently prone to using—to your delight.", "url": "https://wpnews.pro/news/production-ready-software-development-at-the-speed-of-thought", "canonical_source": "https://www.osequi.com/studies/speed-of-thought/speed-of-thought.html", "published_at": "2026-10-01 08:25:46+00:00", "updated_at": "2026-10-01 08:45:51.280749+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-tools", "developer-tools"], "entities": ["Osequi", "Claude Code", "Olog editor", "React", "Next.js", "TypeScript", "ChatGPT"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/production-ready-software-development-at-the-speed-of-thought", "markdown": "https://wpnews.pro/news/production-ready-software-development-at-the-speed-of-thought.md", "text": "https://wpnews.pro/news/production-ready-software-development-at-the-speed-of-thought.txt", "jsonld": "https://wpnews.pro/news/production-ready-software-development-at-the-speed-of-thought.jsonld"}}