Most AI written code is built on decisions nobody made on purpose. Give AI a few sentences and say “build this,” and it makes hundreds of them you never see. Today’s models are good enough that the result mostly works. That’s fine for a demo. It isn’t fine for software a business runs on. For that, you need a method.

There are several public methods for building responsibly with AI. GitHub’s Spec Kit, the BMAD Method and Superpowers are a few of the best known. Adopting any of them would put you ahead of most teams.

I’ve been a truly early adopter of having AI write essentially all my code, back to the Sonnet 3.5 days when it barely worked, and a methodology was an absolute requirement for building anything real with it. I created my own out of necessity, and a stubborn insistence that this was how all software would be built, before “AI skills” were a thing and before most of these public methods existed. Since then I’ve refined it almost daily on real client work shipped to production, and taught it to multiple engineering teams. Today I’m publishing it as the Enso Method. Here’s what sets it apart.

The real work happens before a single line of code is written: deciding exactly what you want built. That part is yours. Then, before it writes any code, the agent asks itself what questions it has about the implementation, and does a lot of work to answer them: exploring the data, writing throwaway programs to try the APIs, and testing what’s actually possible. Anything it’s at least 95% sure of, it just decides, so you’re never buried in questions it could settle itself.

Before any code is written, you and the agent write the requirements and technical design. Then the agent refines them on its own, finding gaps, researching them and folding the answers in, until nothing is left to guess. Anything it is at least 95 percent sure of, it decides; the rest goes into assumptions.md for the product owner

What’s left are mostly business questions, which only the business can answer. Most methods assume the person at the keyboard is also the one who decides, like a solo founder building their own product. Most professional developers aren’t in that seat, and when the person who decides isn’t available, an open question stops the build cold. But with AI, implementation is cheap and waiting isn’t. So each question becomes an assumption, a proposed answer with its evidence and a confidence level, for the product owner to confirm or correct on their own time.

The assumptions register: a question research can’t settle gets a proposed answer; from 20 to 94 percent confident, the agent builds on it and records it in assumptions.md for the product owner to confirm or correct, and below 20 percent it stops and asks

You don’t have to wait for an answer to that question. If someone can answer it now, great, earlier feedback is always better. But if the decision maker isn’t available, the agent builds as if the answer is yes and moves straight on. If the product owner says “no” a week later, after the whole feature is finished, that’s fine. Their answer goes into the requirements, and the agent rebuilds that piece. A rebuild takes far less time than the wait would have.

Once the requirements are settled, the build is cut into phases small enough for one agent session each, and the agent works through them, with no questions for you and nothing to approve. If it hits something nobody anticipated, it records an assumption and keeps going.

Here’s what that looked like over the last four weeks, across multiple client engagements and my own internal products, all built this way - over a million lines of code and 3,632 commits.

Lines written per week, September 7 to October 4, 2026, split into code, tests and docs: 337,000 lines and 968 commits the week of September 7, 197,000 and 713 the week of September 14, 239,000 and 992 the week of September 21, and 304,000 and 959 the week of September 28. Generated files are left out.

The volume doesn’t come from longer hours. It comes from running work in parallel. Once a build is underway it doesn’t need me, so I can start on the requirements for the next project while it runs. Several projects can be building at once, and phases of the same project that don’t depend on each other can be built side by side. Whenever any agent was working, 3.6 were working on average, and at the peak there were sixteen at once.

One engineer, several builds at once. Agents working at once: 3.6 on average whenever any were working, three or more in four of every five working hours, and 16 at the peak. A heatmap of the week of September 28 shades each hour by the most agents working at the same moment, with most weekday hours from 7 am to 11 pm at six or more.

Lines of code measure volume, not value. Value comes from delivering the right things, which is what all that work up front is for. What these numbers show is the other half. Point the method at the right work and the agent builds unattended. You aren’t checking in every few minutes, so your limited time and attention go to the next thing. That’s the real leverage.

The Enso Method is free and open source, as agent skills for Claude Code and Codex.

Whether you use mine or not, you should use a method. The method, not the model, is what makes it safe to hand AI the code for software people depend on, and any method beats a few sentences and hope.