Review as the Scarce Resource

Review as the Scarce Resource is the reclassification this book's operating model depends on. Reviewer attention is a capacity with a size, an owner and a utilisation figure, and every organisation that treats it as goodwill discovers its limit as a waiting time rather than as a refusal.

Key takeaways

• Sadowski and colleagues, in a 2018 study of Google's review logs covering 9 million changes, measured developers spending an average of 3.2 hours and a median of 2.6 hours per week reviewing. That is the only public per-developer anchor I would use, and it predates agents by seven years.
• Capacity fails silently. A queue does not refuse work, it absorbs it as waiting time, which is why the symptom appears in cycle time and never in a capacity conversation.
• Faros AI, which sells engineering-productivity analytics, reports median time to first review up 156.6% and pull requests merged without any review up 31.3%, which are the two ways an overloaded queue expresses itself.
• Google's published standard is a response-time commitment, not a completion commitment: one business day is the maximum time it should take to respond to a code review request.
• Every review queue needs one named person accountable for its waiting time. A queue owned by a team is owned by nobody, and it will be nobody at four on a Friday.

Read this after Chapter 4, because the checks defined there are what make the arithmetic here survivable, and before Chapters 6 and 7, which are the two levers on it. Chapter 6 reduces demand for human reading, and Chapter 7 reduces the size of each unit arriving.

The engineering manager is asked how much review capacity the team has. The question sounds strange, and they answer with a process description rather than a number.

There is no number. There has never been a number. Review has always been paid for out of the slack in everybody's week, and the slack was invisible because it was never on a plan.

Then arriving volume rises by two thirds and the slack runs out. Nothing announces this. Pull requests just start taking eleven days, and the first person to notice is a customer waiting on a fix.

Reviewer hours are a budget nobody has written down

Every other constrained resource in an engineering organisation has a stated size. Compute has a budget, on-call has a rotation, and interview loops have a load calculation with a recruiter watching it.

Review has none of that in most places. It is scheduled by hope. The implicit assumption is that reviewing is a small tax on the person doing it, and that assumption held while authorship was the expensive step and volume was bounded by typing.

Volume is no longer bounded by typing. The tax stayed the same size per change while the number of changes rose, which is the entire mechanism of this chapter. That is the whole mechanism. Nothing subtler is required.

Writing the budget down does one thing before it does anything else. It converts an unbounded expectation into a finite one, which is the precondition for triage.

Review capacity, defined as a number you can put in a plan

Review capacity is the number of reviewer hours per week that an organisation can spend on reading changes without displacing the work those reviewers are also accountable for.

Three inputs make it concrete. The hours per person per week that are genuinely available for review, the number of people who can competently review each area of the codebase, and the effective utilisation, which is always well below one because review arrives in interruptions rather than in a block.

That third input is where estimates go wrong. A reviewer with four nominal hours does not deliver four hours of careful reading, because context switching costs real minutes and because deep review needs an unbroken half hour that a working day rarely offers.

The output is a weekly number and a per-area breakdown. Both matter. Aggregate capacity hides the fact that one payments specialist is the only person who can approve a third of the arriving change. Averages hide the constraint. The constraint is a person.

The one measured anchor, and it is eight years old

There is exactly one public, credible, per-developer figure I would anchor on, and its age has to be stated. Sadowski, Soderberg, Church, Sipko and Bacchelli published Modern Code Review at Google at ICSE-SEIP in May 2018, drawing on review logs for 9 million changes plus 12 interviews and 44 survey respondents.

Their measurement is that developers spend an average of 3.2 hours and a median of 2.6 hours per week reviewing code. That is the number to start from, adjusted for your own context, and it is more than seven years older than any agent in your pipeline.

Several other figures from that study are worth holding as the baseline the current numbers depart from. The median change modified 24 lines. Over 35% of changes touched a single file and about 90% touched fewer than 10. Median reviewer count was one, and fewer than 25% of changes had more than one reviewer. Overall median latency for the whole review process was under four hours, and 70% of changes were committed less than 24 hours after being mailed out.

Set that beside what the current telemetry reports and the gap is the subject of this book. Faros AI, which sells engineering-productivity analytics, reports average pull request size up 51.3% and files edited per pull request up 59.7%, with median time to first review up 156.6% and time in review up 441.5% at the median, from between-quarter comparisons across 22,000 developers as of March 2026.

When arrival rate crosses service rate

The arithmetic here is unforgiving and it is worth being explicit, because most delivery conversations skip it.

A queue is stable when the rate at which work arrives is below the rate at which it is served. Below that line, waiting time is short and roughly predictable. At the line, waiting time grows. Above the line it grows without bound until something outside the system intervenes.

There is no gentle degradation on the way through. That is the part that surprises people: capacity does not gradually get worse, it holds and then it does not, because the queue absorbs the difference until it cannot.

Two interventions are available and they are the next two chapters. Raise the service rate by removing work that does not need a human, which is Chapter 6. Reduce the arrival load by shrinking each unit and limiting concurrent work, which is Chapter 7.

A third intervention exists and it is what organisations do by accident. Let quality of service fall, which is what merging unread is. Faros AI reports that share up 31.3%.

The tax lands on the people you can least spare

The load does not distribute evenly, and the reason is specific rather than cultural. Faros AI's report describes it precisely, and I would quote it rather than paraphrase.

AI-generated code, Faros AI writes, is often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase, and the structural and logical failures, when they exist, are beneath the surface. Catching them requires the reviewer to read carefully, reason about intent, and reconstruct the problem the code was meant to solve, rather than simply scanning for obvious errors.

That describes a specific kind of reading, and only senior engineers can do it. Faros AI sells engineering-productivity analytics and its conclusion argues for measuring this, which is what it sells. The mechanism stands independently, because it is about what the code looks like rather than about any tool.

The consequence for capacity planning is that the constrained resource is narrower than the headcount suggests. Your review capacity is not your engineer count times a few hours. It is your senior engineer count times a few hours, in the areas where they are competent.

What Google's one-business-day standard actually promises

Google's public review guidance sets a standard worth copying, and the precision of what it commits to is the useful part. One business day is the maximum time it should take to respond to a code review request.

The guidance is explicit that this is response time rather than total review time, saying that it is the response time they are concerned with as opposed to how long it takes a change to get through the whole review. That distinction is what makes the standard achievable.

Adopt the response commitment and publish it. It is enforceable, it is measurable as time to first substantive comment, and it converts an open-ended obligation into a bounded one that a reviewer can plan a day around.

What it does not do is promise a merge. Separating those two clocks also gives you the honest metric: pickup time is a capacity signal, and total time to merge is a size signal.

The capacity arithmetic, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A team of eighteen engineers has six who can competently review the payments and identity areas. Applying the Google anchor of roughly three hours per week, with an effective utilisation of 0.6 because review arrives as interruptions, gives about eleven usable reviewer hours a week for those two areas.

The second column is a functioning system with slack. The fourth row of the third column is the whole problem, and no amount of asking people to be diligent closes a fourteen-hour gap.

Two things follow immediately. Some of those 38 changes must stop requiring human reading, and each one must get smaller. Neither is optional once the arithmetic is on a page.

One named owner per queue

Capacity without ownership decays. The specific failure is that a queue with no owner has no one whose week gets worse when it grows, so it grows.

Give every review queue one named person, not a team and not a rota. Their accountability is narrow and checkable: the waiting time of that queue, the response standard being met, and escalation when arrival outruns service for two weeks in a row.

That person also holds the only decision that matters when the queue is full. What gets read first. In my experience the default, which is newest first because it is at the top of the page, is the worst available policy, because it starves exactly the large risky change that most needs attention.

The owner is also who answers when someone asks why a change sat for nine days. A team cannot answer that. A person can, usually in one sentence, and the sentence is normally about capacity rather than about diligence.

The objection: this is a plea for more headcount

It reads that way and it is not, and the distinction matters because the honest answer to "hire more senior reviewers" is that you cannot afford it and it does not scale.

Three things follow from writing the budget down, and none of them is a requisition. Triage becomes defensible, because you can show that reading everything carefully is arithmetically impossible rather than merely unpleasant. Investment moves upstream, because the cheapest hour is the one spent on Chapters 2 through 4 rather than in the queue. And size limits stop being a style preference and become a capacity control.

There is a fourth, less comfortable consequence. Some of the volume you are celebrating is not worth the review capacity it consumes, and a capacity budget is what lets you say so. Work in progress has a cost that is invisible until somebody counts the hours.

The claim I would not make is that this chapter solves anything on its own. It sizes the problem. CircleCI's 2026 report, published 18 February 2026, showing median default-branch throughput down 7% while feature-branch throughput rose 15%, is what an unsized queue looks like from the outside.

Chapter summary

Review capacity is a finite weekly number of hours, and the reason it fails silently is that a queue absorbs excess as waiting time rather than refusing work, so the symptom shows up in cycle time and never in a capacity conversation. Capacity has three inputs, the hours genuinely available per reviewer, the number of people competent in each area, and an effective utilisation well below one because review arrives as interruption rather than in blocks, and it must be reported per area because aggregate figures hide the one specialist who gates a third of the change. The single public anchor is Sadowski and colleagues at ICSE-SEIP in May 2018, measuring an average of 3.2 hours and a median of 2.6 hours per developer per week across review logs for 9 million changes, alongside a median change of 24 lines, a median of one reviewer, and overall median review latency under four hours, all of which predates agents by seven years. Faros AI's between-quarter telemetry as of March 2026 reports the departure from that baseline: pull request size up 51.3%, median time to first review up 156.6%, time in review up 441.5% at the median, and merges without any review up 31.3%. The load concentrates on senior engineers because generated code is superficially convincing and its failures are beneath the surface, which demands careful reconstructive reading rather than scanning. Google's one-business-day standard is a response commitment rather than a completion commitment, which is what makes it achievable and what separates pickup time as a capacity signal from total time as a size signal. Give each queue one named owner accountable for waiting time, ordering and escalation.

Sizing the queue does not shrink it. Chapter 6 is Automated First-Pass Gates and Risk-Based Triage, which is the first of the two levers: taking baseline correctness off people, and deciding which changes a human genuinely has to read.