Review is the bottleneck. Adding reviewers will not fix it.
The numbers on agentic pull requests are worse than most teams realise, and the obvious response is the one that reliably fails. Queue length is a system property, not a staffing gap.
The argument going around at the moment runs like this: agents produce more code, review has not scaled, therefore hire or assign more reviewers. It is intuitive, it is what every engineering organisation reaches for first, and it does not work.
I want to be specific about why, because the failure is structural rather than a matter of effort.
The numbers are worse than the anecdote
LinearB’s 2026 benchmarks put figures on something teams had been describing loosely. Agentic pull requests show pickup time roughly 5.3 times longer than unassisted ones. Median review duration is up over 400 percent. And the number I find hardest to look past: pull requests merged with zero review rose about 31 percent.
That last one is the tell. A queue that is merely slow produces waiting. A queue that produces unreviewed merges has already failed, and it failed quietly, because nothing in the system announces it.
Stack Overflow’s 2025 survey has developer trust in AI output falling from around 40 percent to 29 percent over a year. Read those two findings together and you get the actual situation: people trust the output less, and more of it is going in unread. Those move in opposite directions and both are rational. Trust fell because people looked closely. Unreviewed merges rose because looking closely does not scale.
Why more reviewers fails
Production is divisible. Two engineers write roughly twice as much as one, minus coordination. Review is not divisible in the same way, for three reasons that compound.
It needs context that takes months to acquire. A senior hire writes useful code in week two and cannot usefully assess architectural fit until month four, because the thing being judged is the relationship between this change and a system they do not yet hold in their head.
It parallelises badly across a set. Ten changes reviewed competently by ten people is not the same as one person reviewing ten, because the question “do these ten cohere” is not asked by any of them.
And it degrades silently under load. Overloaded production shows up as less output. Overloaded review shows up as approvals arriving at the same rate, carrying less meaning. There is no dashboard for that.
What adding reviewers assumes
- Review capacity is a headcount problem
- A reviewer is productive on arrival
- Ten reviewers equal ten times the review
- Overload is visible
What is actually true
- Queue length is set by production upstream
- Useful review needs months of context
- Coherence questions go unasked
- Overload shows as unchanged approval rates
The three responses that also fail
Requiring more approvals per change. Feels like rigour. Distributes responsibility until nobody holds it, which is a well-documented way to make outcomes worse rather than better.
Adding process at the review step. A checklist, a mandatory field, a template. Process is a way of encoding attention, and attention is precisely what is scarce. You are spending the constrained resource to administer the constraint.
Pointing another model at it. Genuinely useful for mechanical defects, local inconsistency, missed edge cases. Not useful for the question review exists to answer, which is whether this change should exist in this system in this form. A second model has no more access to intent than the first. Two systems sharing a blind spot agreeing with each other is not verification, and treating it as such manufactures confidence nobody earned.
What actually moves the constraint
Two things, and only two, in my experience.
Reduce what needs a human at all. This sounds like heresy in an argument about review quality and it is the highest-yield move available. A large share of changes are low blast radius against paths with real test coverage and criteria that genuinely settle the question. A human reading those is spending the scarcest input in the building on something a machine established. Route by blast radius, not uniformly.
Move the check upstream into the specification. Review is expensive largely because it is answering questions left open earlier. When a ticket says what done means in terms something can evaluate, the reviewer stops adjudicating “is this what we wanted” and looks only at fit and coherence. That is ten minutes of unpleasant precision from whoever wrote the ticket, traded against an unbounded amount of downstream judgement from the person you can least afford.
Where this breaks down
Sometimes hiring is right. A team of three carrying a system that needs eight is understaffed, and no amount of routing fixes it. I have argued against headcount as a first response, not as a possible one. The test is whether people are waiting on review or whether nobody has the context to give it; the second is a hiring problem and the first is not.
Blast-radius routing will miss. Something classified low risk will cause an incident, and the organisational response will be to reclassify everything as high risk, which is uniform review with extra machinery. Surviving the first bad miss without over-correcting needs senior air cover agreed in advance.
Better criteria assumes someone will write them. The person who writes tickets usually does not report to you, is measured on something else, and experiences the precision as pure cost since the benefit lands in another team. This is the real reason the upstream fix is rare, and it is organisational rather than technical.
And review may not be your constraint. I have written as though it is universal. For plenty of teams it is deploy frequency, environment contention, or a security review with a five-day queue. Go and look at where work is actually waiting before acting on any of this.
The takeaway
The zero-review merge number is the one to put in front of your leadership, because it converts a vague sense of strain into a fact: changes are reaching production unread, and the rate is rising.
Adding reviewers treats a structural property as a staffing gap. Review does not divide cleanly, needs context you cannot hire quickly, and fails silently rather than loudly. The interventions that work operate on what arrives and where it is routed, not on capacity at the constrained stage.
If you take one thing into next week: find your own zero-review merge rate. Most teams cannot produce it, and the difficulty of getting it is itself the finding.