The shape of the problem
Every team I work with has had the same year. Output went up sharply. Delivery did not. The work is being produced faster than anyone can responsibly accept it, and the queue has simply moved to a new place.
This is now visible in the numbers, not just in the mood. A GitLab survey found that 85% of respondents say AI has shifted the bottleneck from writing code to reviewing it. Flow metrics tell the same story from the other side: median pull-request review time up several-fold while throughput rose by roughly a third. More arriving, each item waiting longer.
That is not a tooling failure. It is what happens when you speed up one stage of a system and leave the next stage exactly as it was.
Why review does not scale the way generation did
Generation scaled because it is parallel and cheap. Verification is neither. It is serial — someone has to hold the change in their head — and it is expensive in exactly the resource nobody added more of: senior attention.
Worse, agent-written code changes what review is for. Reviewing a colleague’s work, you can lean on knowing the colleague. You know what they habitually get wrong, and you know they understood the intent even where the code is clumsy. With an agent you have no such prior. The code often reads better than a human’s first draft, and it can still be confidently wrong about something nobody asked about.
So reviewers do one of two things. They read everything carefully, and become the bottleneck. Or they skim, and the organisation quietly accepts a class of defect it has no way to see. Both are common. Only one of them is visible on a dashboard.
The fair objection
There is a serious counter-argument worth stating. Some practitioners hold that review is not the true constraint at all — that the real limit is how often you can safely deploy, and that batching changes into large releases is what makes review feel like the bottleneck. Shorten the deployment cycle, they argue, and small changes flow through with far less review burden per change.
I think both are true and they are the same argument. Big batches make verification harder, and hard verification encourages big batches. Whichever end you attack, the fix is the same: make each unit of change smaller, and make the evidence that it is safe cheaper to produce.
Three things that actually move it
1. Make the machine produce the evidence, not just the change
The single highest-leverage change is refusing to accept work that arrives without proof. Not a summary of what the agent believes it did. The command it ran, the output it got, and an honest statement of what it did not check.
## Evidence of work
Every change you hand back must arrive with evidence a human can check in under two minutes:
- the exact command you ran and its output
- what you did not test, stated plainly
- the smallest diff that delivers the request
If you cannot produce that evidence, say so instead of claiming the work is done.The final line matters more than the rest. Most review time is not spent finding bugs. It is spent working out whether the claim of doneness is true. An agent that says “I changed this but did not run the integration tests” has done more for your throughput than one that says “all done” and is right 90% of the time.
2. Move the checks that need no judgement out of human hands
Anything deterministic should be a hook or a gate, not a reviewer’s responsibility. Formatting, lint, type checks, secret scanning, test runs, migration safety. If a rule can be expressed as code, a human reading a diff is the most expensive possible way to enforce it, and the least reliable at four in the afternoon.
What is left after that is the part review is actually good at: is this the right change, does it fit the system, does it do anything the request did not ask for.
3. Use a second model as a first reader, not as the decision
A structured review pass by a separate model before a human sees the change catches a genuine share of issues — inconsistencies, missed edge cases, work that drifted from the brief. It shortens human review. It does not replace it, and any process that treats it as a replacement has simply moved the unverified risk somewhere less visible.
The value is not that the machine review is trustworthy. It is that it makes the human review shorter and more focused.
What this means if you are buying AI delivery
Most AI pilots are scoped around generation. Can it write the code, draft the document, answer the query. Almost none are scoped around acceptance: how will a person confirm this is right, how long will that take, and who is accountable when it is wrong.
That is why so many pilots look excellent and never reach production. The demo optimises the stage that was already getting cheaper. The blocker was always the stage after it.
The practical test for any AI system going into a real workflow is not “how good is the output”. It is:
- What evidence does it produce alongside the output?
- Which checks are deterministic and automatic?
- How long does a competent human need to accept or reject one unit of work?
- What happens to that time when volume doubles?
If the answer to the last question is “it doubles too”, you have not built a system. You have built a faster way to fill a queue.
The reframe
The teams pulling ahead this year are not the ones generating the most. They are the ones who made acceptance cheap: small changes, machine-produced evidence, deterministic gates, and human judgement reserved for the questions that genuinely need it.
Speed of generation is now a commodity. Speed of trusted acceptance is the thing worth engineering, and it is where the remaining advantage sits.
Sources
From idea to operation
Make the next AI decision concrete.
NavAIgate helps leadership teams identify high-value AI opportunities, prove them safely and turn the winners into working systems.