If AI writes most of the code, a twelve-week build should now take four. That is the reasonable assumption, and it is the question clients ask us most often.

The data says otherwise. Teams with heavy AI adoption produce far more code and ship at roughly the same pace — sometimes slower. Understanding why is now the single most useful thing a non-technical buyer of software can know.

How much code is AI actually writing?

Adoption is close to total. JetBrains' Developer Ecosystem Survey 2026, covering more than 15,000 professional developers, found that as of May to July 2026, 90% were using AI coding agents at work at least weekly, and 68% were using them daily.

Sonar's 2026 State of Code Developer Survey put AI at 42% of all committed code, with developers expecting that to reach 65% by 2027.

So the input side is real. The generation of code genuinely has accelerated. That part of the promise was delivered.

Then why hasn't delivery sped up?

Because writing code was never the only slow step — it was just the most visible one.

Faros AI's telemetry study of more than 10,000 developers across 1,255 teams found what happens when generation accelerates and nothing else does. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. At the same time, pull request review time rose 91%, average pull request size grew 154%, and bug counts rose 9%.

The critical finding is the last one: organisational DORA metrics — deployment frequency, lead time, change failure rate — showed no measurable improvement. Individual developers got faster. The organisation did not.

CircleCI's 2026 State of Software Delivery, drawn from over 28 million CI workflow runs across more than 22,000 organisations, shows the same shape from a different angle. Overall throughput rose 59% year over year. But for the median team, main-branch throughput actually fell around 7%, and main-branch success rates dropped to 70.8%.

More code entering the pipeline. Less of it reaching production successfully.

Where the bottleneck went

It moved from writing code to deciding whether code is safe to merge.

This is not a subtle shift. A developer with AI tools can open five or six pull requests a day. A reviewer can still review roughly the same number they could review three years ago. The two halves of the pipeline no longer match, and the mismatch compounds every single day.

Three things make it worse than a simple queue problem.

Reviews are harder, not just more numerous

AI-authored changes are larger and touch more files. A reviewer facing a 400-line diff skims for style instead of reasoning about intent. Each review decision now carries more uncertainty, and more uncertainty means more risk slipping through.

Nobody fully trusts the output, and not everybody checks

The same Sonar survey found that 96% of developers do not fully trust AI-generated code to be functionally correct — but only 48% say they always verify it before committing. That gap between distrust and verification is where production bugs come from.

Confidence and reality have come apart

CloudBees' 2026 State of Code Abundance report captured the most uncomfortable number in this whole picture: 81% of enterprise technology leaders reported a rise in production issues tied to AI-generated code, while 92% said they were confident the code was production-ready before it shipped.

Those two numbers describe the same organisations. That gap is the warning.

What this means if you are buying software

You are not being sold a slower timeline than you should get. You are being quoted honestly by anyone who understands the above. Here is how to read it.

Be sceptical of anyone promising an AI-driven timeline cut. If an agency tells you AI lets them deliver in a third of the time, ask what changed in their review and release process. If the answer is only "we use AI tools now," the risk moved to you.

Ask what happens after the code is written. Who reviews it, against what, and how long does that take? A team that cannot answer this has a bottleneck they have not measured.

Ask about main-branch success rate, not lines of code. How often does a deploy succeed on the first attempt? That single number tells you more about delivery health than any velocity chart.

Expect the saving to show up as scope, not speed. This is the honest version. AI usually does not compress a twelve-week build into four weeks. It lets you get more built inside those twelve weeks — more features, better test coverage, more thorough documentation. That is a real gain. It is just not the one that gets advertised.

What actually fixes it

The teams keeping their AI gains have changed the workflow behind the tools, not just adopted the tools.

Cap pull request size regardless of how fast the code appeared

AI makes enormous diffs trivial to produce. Reviewers absorbed no extra capacity. Enforcing a size limit is the cheapest fix available and it works immediately.

Use AI as the first reviewer, humans as the second

The pattern being called the review sandwich: automated review catches surface-level problems first, human review focuses on architecture, intent and business logic. GitHub's internal data puts the reduction in human review time at 30–50%.

Verify by default, not by discipline

Given 96% distrust and 48% verification, the answer is not asking people to try harder. It is making verification automatic — tests, static analysis, and CI gates that run whether or not anyone remembers.

Measure review, not just shipping

If you track deployment frequency but not review queue depth or time-to-review, you are watching half the pipeline. The half you are not watching is the one that broke.

Keep releases boring

CI, automated tests, and one-command rollback. When a deploy is a non-event, a bad merge costs minutes instead of a weekend. This matters far more once merge volume doubles.

The uncomfortable summary

AI removed the constraint that everybody was measuring and exposed the ones nobody was. Code generation was never the whole job — reviewing, verifying, integrating and safely releasing were always the larger share, and they did not get automated.

Anthropic's 2026 research on agentic coding lands on the same point from the developer's side: developers use AI for roughly 60% of their work, but only a small fraction of tasks can be handed off completely. Humans still review and steer. That is not a temporary limitation to design around — it is the shape of the work.

Which means the teams that win the next two years are not the ones generating the most code. They are the ones who rebuilt the pipeline behind it.

How we handle this

This is why our delivery model puts a deployed environment in front of clients every Friday, runs CI with automated tests and one-command rollback, and writes documentation and decision records during the build rather than the week we leave. Not because AI made those things optional — because AI made them the constraint.

If you want to know what your own build should realistically take, ZAC Estimator gives a timeline and cost band in about two minutes with the assumptions written out so you can challenge them. Or describe the project to ZAC Consultant and it will map the solution, the features and the phasing.

More on how we build: custom software, web development, and systems we have shipped.