Skip to content
6 min read

AI Can Write the Code. Reviewing It Is the New Bottleneck.

Ninety percent of technology professionals now use AI at work, up from 76 percent a year earlier. More than 80 percent say it made them more productive. Both numbers come from Google's DORA study of roughly 5,000 practitioners. The same study found something that sits awkwardly beside them: as AI adoption climbs, delivery throughput and delivery instability climb together.

Teams are shipping more. They are also breaking more. If you are paying for software right now, that sentence is your whole risk profile in one line.

A corridor of archive shelving stacked with identical boxes, receding into the dark
Everything filed. Almost none of it read.

The constraint moved and most processes did not

For thirty years the scarce thing in software was working code. Every process we built assumed that. Sprints, story points, standups, the whole Agile apparatus exists to allocate a limited supply of typing against an unlimited supply of requests.

That constraint is gone. Code is now cheap and fast. What did not get cheaper is the human hour it takes to read a change, understand what it touches, and decide whether it is safe to ship. Telemetry from Faros AI shows pull request volume and pull request size both climbing faster than review capacity. The queue is not a code queue anymore. It is a reading queue.

The bottleneck used to be writing it. Now it is believing it.

There is a study that makes this uncomfortably concrete. METR ran a randomised controlled trial with experienced developers on codebases they already knew well. With AI tools, they were 19 percent slower. They believed they were 20 percent faster. That is a 39 point gap between what happened and what it felt like, in people who were good at their jobs and paying attention.

You cannot manage a gap that size on instinct. If nobody on your project is measuring cycle time and change failure rate, the productivity story you are being told is a feeling, not a fact.

What AI-DLC actually proposes

The AI-Driven Development Life Cycle, coined by AWS, is the first serious attempt to redesign delivery around the new constraint rather than patch the old one. Strip the vocabulary away and the idea is simple. AI drafts the artifacts. Humans validate at explicit gates. The gates are the product.

It runs in three phases. Inception turns business intent into requirements and units of work. Construction produces the architecture, the domain model, the code and the tests. Operations takes it live. Each phase ends at a checkpoint where a person, not a model, says yes.

01 · Ask before you build

The load-bearing step is making the agent state what it does not know before it writes anything. Ambiguity gets resolved upstream of generation. Resolved downstream, it costs a sprint.

02 · Freeze the acceptance criteria

Criteria are approved by a human and immutable for the cycle. Tests generated from the same prompt as the implementation validate nothing. They inherit the same misunderstanding.

03 · Write the context down

Three artifacts carry most of the weight on a mature codebase: a domain glossary, a directory of architecture decisions explaining the why, and separate instruction files for planning, building and operating.

04 · Make the scanners blocking

At agentic volume, static analysis, dependency scanning, secret detection and infrastructure checks have to stop the build. Advisory warnings get scrolled past. Nobody catches a bad dependency by eye at this rate.

The part the marketing leaves out

AI-DLC is the newest entry in a long family. Test-driven development, behaviour-driven development, model-driven development. We have about thirty years of measurements on that lineage, and the pattern is consistent. The gains are real. They are also conditional and smaller than the launch material promised, and they arrive only for teams that already had their fundamentals in order.

DORA's finding points the same way. AI amplifies whatever your organisation already is. A team with clear ownership, good tests and a fast pipeline gets faster. A team with none of those gets the same mess at four times the rate.

Expect a J curve. Generation capacity arrives months before validation capacity does, so change failure rate goes up before it comes down. Teams that instrument first and accelerate second come out the other side. Teams that accelerate first spend the following quarter on incident reviews.

What this means if you are buying software

You do not need to run the methodology yourself. You do need to know whether the people building for you have solved the review problem or quietly skipped it. Four questions get you most of the way.

Ask What a good answer sounds like
Who approves the acceptance criteria, and when are they locked? A named person, before any code is generated, unchanged for the cycle.
Where do the tests come from? From the criteria, not from the same prompt that wrote the feature.
Which checks can stop a release? A specific list. If everything is advisory, nothing is a gate.
What is your change failure rate this quarter? A number they can produce without going to look for it.

A team that has thought about this will answer in under a minute. A team that has not will talk about velocity.

Where we land on it

We build with AI on every project, and we are unromantic about it. The generation half is largely solved. The interesting engineering has moved to the other half: what context the model gets, what it is allowed to touch, and who signs off before anything reaches a customer. That is the same argument we made about harness engineering, arriving now at the level of the whole delivery process rather than a single agent.

AI-DLC is not a revolution. It is a sensible response to a constraint that genuinely moved, dressed in more vocabulary than it needs. The underlying instruction is one sentence: build your validation capacity before you turn up your generation capacity.

If you have a project where the output is arriving faster than anyone can check it, that is not a tooling problem and buying another tool will not fix it. Tell us where the queue is backing up and we will show you which gate is missing.

AI code reviewAI-DLCAI driven development lifecycleagentic software developmentDORA reportsoftware delivery metricschange failure rateAI development CyprusMETR studyacceptance criteria

Let's build
something real.

Tell us about the workflow, the bottleneck, or the channel that's bleeding margin. We'll show you how we'd ship the fix.