Code review capacity: plan it like the finite resource it is

Your team plans sprint capacity, on-call rotations, and cloud spend down to the dollar. Almost nobody plans code review capacity, even though it is now the constraint every merge queues behind. Review time is a real, finite, measurable resource: some number of reviewer-hours per week, multiplied by an honest rate at which a human can actually evaluate code. Treat it like the budget it is and a surprising amount of chronic review pain turns out to be simple arithmetic, not a culture problem.

Estimating your code review capacity

Start with reviewer-hours. Not headcount hours: focused, interruptible-only-by-pager hours a person can actually give to reading other people’s diffs. For most engineers that is two to four hours a week before their own work suffers. Then apply a rate. The SmartBear peer review study is the standard reference here: effective review runs at no more than about 500 lines of code per hour, sessions should stay under roughly 60 minutes, and a single sitting should cover at most around 400 lines before defect discovery collapses.

So a five-person team giving three focused hours each has 15 reviewer-hours per week. At the generous 500-lines-per-hour ceiling, that is 7,500 lines of changed code the team can genuinely review. Compare that to what you merged last week. For most teams the merged number is a multiple of the reviewable number, and it always has been. The gap was papered over by skimming.

The ceiling is lower than the math suggests

Those rates are ceilings for finding defects, not targets to hit. Dense business logic reviews slower than generated boilerplate; unfamiliar code reviews slower than code you own. And latency eats capacity from the other side: Google’s review speed guidance asks reviewers to respond within one business day at the outside, because slow turnaround compounds. Authors waiting on review start batching work into bigger PRs, bigger PRs take longer to review, and the queue feeds itself. Capacity planning has to budget for responsiveness, not just total lines.

Spend it by tier, not by arrival order

The default allocation strategy is first come, first served: whatever hits the queue gets whatever attention is left. Deliberate allocation matches attention to risk. A dependency bump and a change to the payment path should not draw from the budget at the same rate. We laid out a concrete tiering scheme in review by blast radius: low-risk changes get automated gates and sampling, high-risk paths get full human attention, and the tier is chosen up front instead of by whoever happens to be tired that afternoon. Once you know your weekly budget is 7,500 lines, deciding which lines get the real hours stops being a philosophical question.

Make the budget visible, too. Teams estimate authoring work in every sprint planning session and never mention the review load that work will generate. A PR heavy sprint should book reviewer-hours the same way it books build time: named people, real hours, counted against their other commitments. When review is an unbudgeted side effect, it is the first thing squeezed and the last thing anyone admits to squeezing.

The AI volume math does not close

This arithmetic was survivable when authorship was the bottleneck. It is not anymore. Osmani, in his essay on agentic review, cites a Faros analysis of 22,000 developers reporting code churn up 861%, defect rates jumping from 9% to 54%, and zero-review merges rising 31.3%. Generation multiplied; review capacity stayed fixed, because it is made of human hours. We walked through the collision in AI writes code faster than you can review: when volume goes up 4x and the budget does not move, the difference is absorbed by shallower review, and nobody announces that decision. It just happens.

Signals the budget is spent

You do not need a dashboard to detect exhausted review capacity, though the metrics are easy to pull. Watch for these:

• Queue age. Median time from review request to first response creeping past Google’s one-business-day line, then past two.
• Rubber-stamp rate. Approvals landing minutes after the request on diffs that would take an hour to actually read.
• Comment density. Substantive comments per hundred changed lines trending toward zero while merge volume holds steady.
• Zero-review merges. The share of changes merging with no approval at all, the same number Osmani reports rising 31.3% in the Faros data.

Any one of these means the process still exists on paper while the attention behind it has quietly gone. The honest responses are the ones that change the arithmetic: shrink what needs reviewing, tier what gets the hours, or raise the effective reading rate. That last lever is where tooling belongs (disclosure: we build Pyor for exactly that), because a reviewer who can navigate a diff by risk instead of file order gets more evaluated lines out of the same fixed hour. What no tool can do is make the budget infinite. Plan it like the resource it is, and spend it where being wrong is expensive.