Review Capacity Is the New Delivery Ceiling: What to Do When Agents Write Faster Than Humans Can Read
AI made code generation nearly free, but human code review capacity did not scale with it. Data from 8.1 million pull requests shows AI-assisted PRs are 2.6x larger, wait 4.6x longer for a reviewer, and merge at 32.7 percent versus 84.4 percent. Here is how to treat review capacity as the real constraint on software delivery.
Your engineering org did not get faster this year. It got a bigger queue.
That is the uncomfortable read on most AI delivery programs I see right now. Leaders bought the tools, adoption climbed, commit volume went up and to the right, and the quarterly deck says the transformation is working. Then you look at the one number that actually pays the bills, which is how much verified value reached production, and it barely moved. Something absorbed all that new output before it ever became a release.
That something is code review. Generation got cheap. Verification did not. And in any system, when you relieve one constraint, you do not eliminate the constraint. You relocate it.
The data is no longer ambiguous
For a while this was a hallway complaint. Now it is measured.
LinearB's 2026 Software Engineering Benchmarks Report, built from an analysis of more than 8.1 million pull requests across 4,800 organizations in 42 countries, puts hard numbers on the shape of the problem:
- AI-assisted pull requests are 2.6x larger than unassisted ones, 408 lines of code versus 157.
- AI pull requests wait 4.6x longer before review even starts. Agentic AI PRs sit idle 5.3x longer in pickup, 1,055 minutes versus 201.
- AI-generated PRs are accepted at 32.7 percent, against 84.4 percent for manual ones.
Sit with that last one. Roughly two out of three AI-generated pull requests never merge. They still consumed a spec, a context window, a CI run, and, worst of all, a human's attention. That is not throughput. That is a very expensive way to generate work in process.
Google's DORA program lands in the same place from a different direction. The 2025 State of AI-assisted Software Development report confirmed what its authors call the amplifier effect: AI raises throughput, but it raises instability too when the foundation underneath is weak. AI does not fix your delivery system. It applies pressure to it, and the system fails at whatever was already its weakest joint. For most organizations, that joint is review.
I made a version of this argument about measurement in DORA Metrics in the Agentic Era, where deployment frequency quietly stops being a signal of health. This is the operational twin of that post. If deployment frequency is a lying metric, reviewer utilization is the honest one nobody is watching.
Why review is structurally worse than you think
The intuition most leaders carry is linear. If PRs double, hire another reviewer and you are square. That intuition is wrong, and it is wrong in a direction that hurts.
Review is a queue, and queues do not behave linearly. Expected wait time scales roughly with utilization divided by one minus utilization. At 70 percent reviewer utilization you have headroom, and a surprise costs you a little. At 85 percent, the queue starts to bite. At 95 percent, wait time does not degrade, it detonates.
This is why doubling agent output does not double delivery. It just pushes your reviewers further up the curve.
Now stack three compounding effects on top of the raw math.
The diffs got bigger. A 408-line PR is not 2.6x the review effort of a 157-line one. Review effort scales with the interactions a reviewer has to hold in their head, not with lines. Bigger diffs cross more boundaries, touch more call sites, and blow past the point where a reviewer can keep the whole change in working memory.
Intent got harder to recover. When a colleague writes code, the commit history is a record of their reasoning. When an agent writes it, the artifact arrives without the thinking. The reviewer is not just checking correctness. They are reverse-engineering purpose, and that is the expensive part.
Reviewers learned to flinch. That 5.3x pickup time is not a scheduling artifact. It is a behavioral signal. Engineers see a large, machine-authored diff at the top of the queue and pick something else. The queue is not slow because reviewers are busy. It is slow because reviewers are avoidant, and they are avoidant because the expected value of the read is low.
The dangerous adaptation follows naturally. When the queue is impossible and the pressure is real, teams stop reviewing. They rubber-stamp. Approval becomes a formality performed to unblock a merge, and your quality gate quietly becomes a turnstile. You now carry all the risk of an unreviewed change plus the false comfort of a green check mark.
Treat review capacity as a budget, not a virtue
The fix is not "review harder" or "hire more senior engineers." Those are wishes, not plans. The fix is to run review the way you would run any constrained resource: subordinate the rest of the system to it, and stop feeding it work it should never have seen.
Four moves, in order of leverage.
1. Put a gate in front of the agent, not just behind it
Most teams govern the output and leave the input wide open. That is backwards. A pull request with no articulated intent is a review tax you volunteered to pay.
Require a short spec or a decision record before an agent run of any consequence. This is exactly the argument I made in The ADR Comeback: an architecture decision record is not documentation debt, it is the context that makes a machine-authored change reviewable at all. If a human cannot state what a change is for in three sentences, an agent is not going to discover it for them, and a reviewer is going to spend forty minutes trying.
No spec, no agent run. It sounds bureaucratic. It is cheaper than the alternative by an order of magnitude.
2. Make machines do every check a machine can do
Every class of defect a pipeline can catch is a class of defect a human should never spend attention on. Tests, type checks, linting, dependency and license scanning, security analysis, mutation testing, and, for AI-behaviour features, evals. I have written before that evals are the new acceptance criteria, and this is the operational reason why: an eval suite is a reviewer that never gets tired and never flinches at a big diff.
Add one more automated check that almost nobody has: a diff-size budget. If a PR exceeds the threshold, it does not reach a human. It gets sent back for decomposition. You are not being pedantic. You are protecting the only resource in the system you cannot buy more of on demand.
3. Put an explicit WIP limit on human review
This is the one that gets the most resistance and delivers the most value.
Budget reviewer capacity the way you budget a cloud spend. Decide what percentage of an engineer's week is reviewer time, make it visible, and cap the queue depth. When the review queue is full, generation stops. Yes, that means idle agents. Idle agents are cheap. A 1,055-minute pickup time and a 32.7 percent acceptance rate are not.
Then tier the depth of review by risk rather than reviewing everything at the same intensity. A payments path, an auth boundary, or a data migration gets a deep, adversarial read. A test fixture or a copy change gets a light one. Reviewing every change at maximum depth is not rigor. It is a failure to prioritize dressed up as rigor.
And retarget what humans actually look for. Machines check syntax, style, and coverage. Humans should be reviewing intent, boundaries, and blast radius, which is to say the things that get you paged at 2 a.m.
4. Move risk off the gate and into production
The last move is the one that buys back the most reviewer time, and it is the least intuitive: make merging less consequential.
If a bad change is catastrophic and irreversible, review has to be perfect, which means review has to be slow. If a bad change is caught by a canary and rolled back in ninety seconds, review can be proportionate. Progressive delivery, feature flags, tight SLOs, and fast automated rollback are not just reliability practices. They are review capacity practices, because they lower the cost of being wrong.
That is the same throttle logic I laid out in Error Budgets Over Deadlines. You are not lowering the bar. You are moving the verification from a place where it costs a scarce human hour to a place where it costs a cheap machine minute.
What to put on the dashboard Monday morning
If you lead a delivery org, you likely cannot currently answer the question "what is our reviewer utilization?" That is the gap. Five metrics, and none of them require a new tool:
- Reviewer utilization. Share of engineering capacity consumed by review. If it is above 85 percent, your queue is already compounding.
- PR pickup time, segmented by AI-assisted versus unassisted. The gap between those two lines is your avoidance signal.
- Median PR size. A rising line here is a leading indicator of everything else going wrong.
- Rework rate. Code rewritten shortly after merge is the tax on review you skipped.
- Share of PRs merged with no meaningful review. The most honest number in your organization, and the one nobody wants to publish.
Track those five for a quarter and you will know, with evidence rather than vibes, whether your AI investment is producing delivery or producing inventory.
The uncomfortable conclusion
There is a version of this story where the answer is simply "AI will review the AI," and to be fair, AI-assisted review tooling is genuinely useful and getting better fast. Use it. It will catch a real share of defects and it will shrink the queue.
But it does not dissolve the problem, because it does not resolve accountability. Somebody signs their name to the change. Somebody answers for it when it takes down checkout on a Friday. That signature is the actual scarce resource, and it does not scale with model capability. It scales with human attention, judgment, and the organizational willingness to say no to a merge.
The organizations that win the next two years will not be the ones that generate the most code. That contest is already over and everyone tied. They will be the ones that built the cheapest, fastest path from generated code to verified, accountable, deployed code.
Generation is a solved problem. Verification is the whole game now. Fund it like it.
References
- LinearB. 2026 Software Engineering Benchmarks Report. linearb.io
- Google Cloud DORA. State of AI-assisted Software Development, 2025. dora.dev
- Nathen Harvey, DORA. DORA 2025: Year in Review. dora.dev