Used well, AI changes the economics of building software. On platforms I have built this way, build cost has come in roughly 80% lower and time to first value around 60% shorter than a conventional team would take. That is the result most leadership teams want to hear about, and it is why many are asking when their own build can start.
What they hear less about is what that result stands on. The code is the cheap part. What makes the result repeatable is everything around the code, and almost none of it is something the AI supplies for itself.
The cheap part is the code
When an AI writes the software, the cost of another feature, another service or another rewrite falls close to zero. That moves the effort. On a platform I built this way, now more than 400,000 lines of production code, the time went into the steps that come before the code. Design sessions fix the architecture, and each decision is recorded as an architecture decision record (ADR), well over a hundred of them, with the reason for it. Behaviour is specified by example: a working demonstration and a reference document for every pattern exist before the AI is asked to build anything. Planning and building are separate passes. A planning pass locks decisions and produces documents and no code; a build pass then executes against them from a written brief. Together these form the builder system: the decision records, specifications by example, standards and as-built records the AI reads before it touches anything.
Studies of AI-assisted teams point the same way. METR measured experienced open-source developers working on their own codebases with the tools of early 2025 and found they took 19% longer with AI than without, while believing they had been 20% faster. Faros, measuring real delivery data, found teams with high AI adoption merged 98% more pull requests, but reviews took 91% longer and delivery speed across the organisation did not improve. More code arrives faster. Whether the business ships faster depends on what the code arrives into.
Three things AI gets wrong with total confidence
It prices the wrong work: it quotes for the code, which costs almost nothing, and understates the design, documentation and checking around it. Ask an AI how long a piece of work will take and it estimates what it sees itself doing. In my experience the design and documentation system is the largest piece of work in the build and the one every estimate misses most. Plan from the system, not from the code.
It decides from an old picture of the world. Models learn from data with a cut-off date, so they reproduce the versions and habits that were current then. One study of code models found deprecated interfaces in 25 to 38% of plausible completions, and 70 to 90% where the surrounding code already used them. On one of my builds the AI coding agent chose a version of the runtime about a year from end of life. Challenged, it recommended the next version. Challenged again, it proposed the newest, which had been out for a year but was not yet generally available on the serverless platform we deploy to. Moving to the newest version and accepting that timing was a business decision. The AI could list the options. It could not own the choice.
It forgets its structure, its framing and even its important principles, and it repeats failure modes it has already made. An AI coding agent, the AI acting as the developer, will state a principle correctly and break it an hour later, so every build ends with testing and validation by a person who checks what it did against the documents. The instructions file for one platform I build has more than twenty recorded failure modes, each written down because it happened. In one, the AI left a second copy of a bot-protection check guarding the most exposed public route and described the deferral as "not urgent, and not wrong". It was wrong on both counts. The fix is not a smarter model. It is the system around the work: the process, the documentation, the order of the instructions, and above all a builder who knows when to challenge. When something does not look right, the builder acts on that instinct and makes the AI prove itself: reread the document, follow the practice, do the deep research on the subject before it goes on.
The architecture has to be rewritten as the build scales
A platform that works for one stream of development will not work for several, and the structure has to change as the codebase grows. I found this on the platform above. Early on, at under 300,000 lines, its code could have supported seven to ten streams of development at once, but it delivered one. Every stream ran through the same two shared things: a single infrastructure file of more than 8,000 lines, changed up to 40 times a week, and a single deployed environment.
Shared code was not the problem. A library of 34 small modules was imported by 23 packages without collisions. Sharing concentrated in one large file was the problem, and for an AI it is worse, because a session must load thousands of lines to change one.
So the architecture was rewritten for scale, in four layers, as the problems appeared. Each AI session was given its own working copy, so source control stopped colliding. The platform was divided into ten independent services. The one shared infrastructure file was carved into a module for each stream. The single deployment was restructured into independent stacks, so each service deploys on its own from the one environment. Six streams now work without touching each other's files. None of this was an AI decision. It came from measuring where the streams collided and carving there, one layer at a time, as the codebase grew. An AI will build confidently to whatever structure it finds, so the builder is the one who sees when that structure has stopped serving the next stage of growth.
The builder owns the task
One person, the builder, owns the task at all times. The AI proposes an initial architecture by inference, and the builder decides the architecture of the product. The builder works with the product manager and product owners, sequences the development, and checks the AI's work against the documents at the end of every build. Throughout, the builder relies on experience of when to challenge. When something looks wrong, the builder trusts that instinct and makes the AI prove itself by rereading a document, following a practice or researching the subject properly.
Experts are brought in for what only people know. That means knowledge of the business's processes and known problems, experience of its customers and users, and a check that what was built is authentic to them. A security specialist works alongside even where the methodology and a secure development lifecycle build testing such as SAST into the process. Someone sets policy, practice and internal standards; for example, behaviour-driven development and specification by example can be set as the way the AI is worked with.
As the product and the team grow, the work segments and new areas of expertise are added. The builder role stays. What changes is how many people the builder can call on.
What to settle before you scale the build
Write the builder system first. Design sessions, decision records, specifications by example and standards are what the AI reads. Without them every session starts from a guess, and the speed turns into rework.
Name the builder and the experts. Decide who owns the task, and which specialists they can call on, before the first sprint: product, security, policy and subject matter. If one person holds every role, that person is your constraint.
Plan to restructure as you scale. The structure that suits one stream will block the next. Watch where streams collide, and carve there before the AI builds more on top.
Decide what the AI may decide. Versions, dependencies and structure carry business consequences. Those choices come to a person.
Test and validate at the end, every time. Plan testing and validation against the documents as part of the build, not as an afterthought, and keep a person in the loop who knows what the software should do.