The reviewer shortage is a specification shortage
Reviewers are slow because they are doing two jobs at once, and only one of them is review. The other is working out what the change was supposed to do, which is specification work smuggled into the most expensive part of the pipeline.
Watch what a reviewer actually does with an agent-authored pull request and you will see two distinct activities.
The first takes most of the time. They read the diff, then the ticket, then some surrounding code, and they build a theory of what this change was supposed to accomplish. They may open the linked issue, skim a thread, or ask the author, who in this case is a service account. What they are doing is reconstructing intent from evidence.
The second is fast. Once they have a theory of intent, checking the diff against it takes a few minutes, because that is a bounded comparison and they are good at it.
The industry describes this as a reviewer shortage. It is not. Reviewers are being asked to perform specification work at the point in the pipeline where it is most expensive, and then to review on whatever time is left. My position: the constraint is a shortage of stated criteria, not a shortage of people, and adding reviewers scales the wrong half of the job.
The two jobs, and which one moved
The reconstruct-intent job existed before agents, and it was cheap, because the author was a colleague sitting nearby with a memory of why they had done it. You asked, they told you, and the exchange took ninety seconds. Intent was recoverable on demand from a human who still had it in their head.
Two things changed at once. The author is now frequently a process with no memory of intent to recover, because it did not have intent, it had a prompt. And the volume of changes went up sharply, so the reconstruction cost is paid many more times per week.
The benchmark numbers make more sense read this way. LinearB’s 2026 figures put median review duration up over 400 percent and pickup time on agentic pull requests roughly 5.3 times longer. Reviewers are not four times slower at reading code. They are spending most of their time on a job that used to be a ninety-second conversation and is now an investigation, and pickup time reflects the reluctance that produces: people put off opening a pull request when they know the first twenty minutes will be archaeology.
Review without a stated criterion
- Reconstruct intent from diff, ticket and surrounding code
- Author cannot be asked, or has no intent to report
- Reviewer's own theory becomes the standard
- Two reviewers can reach opposite conclusions honestly
- Unbounded: you can always read more code
Review against a stated criterion
- Intent supplied, in writing, before the code existed
- Nothing to reconstruct
- The standard is external to the reviewer
- Disagreement is about the criterion, which is the useful argument
- Bounded: finite checks, and you know when you are done
Why adding people makes it worse
The obvious response to a queue is more capacity, and here it backfires specifically.
Each additional reviewer performs their own independent reconstruction of intent. The work is not shared, because a theory of intent lives in one person’s head and is not written anywhere. So doubling reviewers doubles the reconstruction labour while producing a set of theories that do not necessarily agree.
Worse, the standard becomes whatever the assigned reviewer happened to conclude. Two competent people reviewing the same change against two reasonable reconstructions will approve different things, and neither of them is wrong. There is nothing to be wrong against.
That variance is corrosive in a way the queue length is not. Authors learn that approval depends on who picks it up. Reviewers learn that their judgement is unbacked, which makes saying no expensive and rubber-stamping cheap. And the visible outcome is the number that should worry everyone: pull requests merged with zero review up around 31.3 percent. That is what happens when a job is unbounded, unshared and unsupported. People stop doing it.
Move the work upstream, where it costs less
The fix is to supply the missing input rather than to scale the response.
A criterion here means a statement, written before the change exists, of what must be true for the work to be done, in terms specific enough that two people would agree on whether it holds. “Users can export transactions” is not one. “An account administrator can export transactions for any account they administer, over a date range they choose, and deleted transactions are excluded” is close to one.
This is not free, and I want to be honest about where the cost lands: on whoever writes the ticket. That is the trade. You move effort from the most expensive, most contended part of the pipeline to the cheapest, least contended part, and the people who pay are not the people who benefit, which is why it does not happen by itself.
The return is well attested. Controlled studies on specification quality put the reduction in downstream errors from human-refined specifications at up to fifty percent. That is a defect reduction, and it is also a review-time reduction, because a large share of what reviewers currently spend time on is not defects at all, it is the ambiguity that produced them.
The test that settles the argument
If you want to know whether this describes your organisation, there is a five-minute exercise that is hard to argue with.
Open the last ten merged pull requests. For each, without opening the code and without asking the author, write down the condition that would have made it fail review. Not “the code should be correct”. The specific, checkable thing.
For most teams the honest count is two or three out of ten. Those seven other changes were approved against a standard that existed only in the reviewer’s head at the time and no longer exists anywhere. That is not a reviewer capacity problem, and no amount of hiring touches it.
It also tells you something about trust. Developer trust in AI output fell from around forty percent to twenty-nine percent in the Stack Overflow 2025 survey. Some of that is warranted scepticism about generation quality. Some of it is that people are being asked to trust output they have no external standard to judge, which would erode anyone’s confidence regardless of how good the output was.
Where this breaks down
Plenty of review work is genuinely not about intent. Security flaws, performance regressions, concurrency mistakes and violations of local convention are all found by reading code against expertise, not against criteria. A stated criterion does nothing for any of them, and those are exactly the defects that hurt most. My argument addresses the time cost, not the whole value of review.
Writing good criteria is a scarce skill, and scarcer than reviewing. The number of people in any organisation who can write a genuinely unambiguous criterion is smaller than the number who can review code well. Moving the load upstream may move it onto a narrower group. I think it is still the right trade because the artefact is reusable and a reconstruction is not, but it is a trade, not a free win.
Criteria written to satisfy a gate are worse than none. Once “every ticket needs criteria” becomes policy, you get criteria that restate the title in more words, and reviewers now have a document that looks like a standard and is not. That is more dangerous than an empty field, because it discourages the reconstruction that at least produced a real theory.
Some work should not be specified in advance. Exploratory changes, spikes, refactors where the shape emerges from doing it. Demanding a checkable criterion before that work starts is how you get either fiction or paralysis, and a policy without an exemption for it will be routed around within a month.
And I sell tooling in this space, so weigh the argument accordingly. We make software that connects acceptance criteria to what changed, which means “the reviewer shortage is a specification shortage” is a conclusion that suits us commercially. The ten-pull-request exercise costs nothing, involves no vendor, and will tell you whether the argument holds in your organisation better than I can.
The takeaway
Reviewers are doing two jobs. One is checking a change against a standard, which they are fast at. The other is inventing the standard from evidence, which is specification work, and it is being done at the most expensive point in the pipeline by the person with the least available time, once per reviewer, with the result written down nowhere.
Adding reviewers scales the second job. Stating criteria before the work starts eliminates it.
If you take one thing into next week: open your last ten merged pull requests and, without reading the code or asking anyone, write down what would have made each one fail. The number you cannot answer is the size of your actual shortage.