The cost of slow code review rarely appears on a dashboard, which is exactly why it compounds. No invoice arrives for the pull request that sat four days. The bill shows up shredded into a hundred line items nobody attributes: a context switch here, a rebase there, a feature that shipped a sprint late, a senior engineer who quietly stopped asking for review on small things. Add the line items back together and slow review is one of the most expensive processes an engineering organization runs.
Counting the cost of slow code review
Start with inventory. A finished, unmerged change is completed work earning nothing, and every day in the queue is a day the business paid for software it cannot use. But idle inventory is the cheapest item on the bill. The expensive ones are what the delay does to everything around it.
Context evaporates first. Reviewing a change is largely reconstructing the intent behind it, and that reconstruction gets harder on both sides of the table as the diff ages. By day four the author has to re-load their own reasoning before they can even answer a question about it. Each review round now costs two context switches: the reviewer swapping in, the author swapping back. Meanwhile the author has started something new, so every comment arrives as an interruption to different work, and the response latency stretches accordingly.
Then the mechanical costs stack. Main moved while the branch waited, so conflicts and rebases multiply, and each rebase risks fresh mistakes in code that was already finished. Follow-up work stacks on top of the unmerged branch, coupling its fate to the queue. And under all of it runs the morale cost, which Google’s review speed guidance treats as a first-order harm, not a soft one: slow review damages both the velocity of the team and the developers waiting on it. People who learn that finishing work changes nothing stop hurrying to finish work. That lesson, once taught, is expensive to unteach.
There is also a selection effect that compounds quietly. When review is slow, the changes that suffer most are the careful ones: refactors, test improvements, dependency hygiene, all the work that is easy to defer and easy to abandon. Urgent fixes get escalated past the queue; virtuous maintenance dies in it. Over a few quarters the codebase records that bias. Slow review does not delay work uniformly; it filters out exactly the work that keeps future changes cheap.
The AI-era multiplier
All of this was true when humans wrote every line. What changed is the arrival rate. Code generation accelerated by an order of magnitude while review throughput stayed human, a mismatch we have written about before: the queue math that was merely unpleasant at human authoring speed becomes unpayable when every developer ships multiples of their former volume.
The evidence on what happens next is the alarming part, because the answer is not longer queues. Addy Osmani’s agentic code review essay cites a Faros analysis of 22,000 developers reporting zero-review merges up 31.3 percent, alongside defect rates jumping from 9 to 54 percent. When review becomes the bottleneck, teams do not throttle generation to match. They route around the bottleneck. The cost of slow code review, at AI throughput, is not slowness at all: it is the silent disappearance of review as a safety function, discovered later as a defect curve.
Cheap fixes first
The encouraging part of the bill is how much of it responds to process changes that cost almost nothing:
- Set a first-response SLA. Most turnaround time is time when nobody was looking, and a one-business-day expectation attacks exactly that slice. It requires no tooling, only agreement.
- Shrink the changes. Small diffs get picked up sooner, read faster, and approved in fewer rounds. Size is the one variable that shortens every stage of the pipeline at once.
- Plan reviewer capacity. Review is real work that appears on nobody’s sprint, which is why it always loses to work that does. Budgeting review time explicitly turns the queue from an externality into a staffed function.
Tooling comes after process, and its honest job is narrow: make the read itself faster without making it shallower. That is the problem we work on at Pyor (disclosure: this is our product), but the ordering stands regardless of whose tool you use. Fix the queue with agreements, fix the diff with size, and only then buy speed for the reading. A team that does the first two often finds the third is smaller than it looked, because the cost of slow code review was never really about how fast anyone could read.
Frequently asked questions
What is the real cost of slow code review?
The direct cost is idle work: finished changes waiting in a queue. The compounding costs are worse: authors lose context and switch tasks, rebases and conflicts multiply, follow-up work stacks on unmerged branches, and reviewers face ever-larger diffs. Google engineering guidance is blunt that slow review harms both team velocity and morale.
What happens if review stays slow while AI speeds up coding?
The queue does not just grow; it gets bypassed. Addy Osmani cites a Faros analysis reporting zero-review merges up 31.3 percent alongside sharply rising defect rates. When review becomes the bottleneck, teams do not slow generation down to match. They quietly stop reviewing, and the safety function fails without ever announcing it.
What is the cheapest way to speed up code review?
Set a first-response expectation and make the queue visible. Most review delay is not reading time; it is time when nobody was looking. A one-business-day SLA, smaller changes, and explicitly planned reviewer capacity fix the bulk of latency before any tooling change. Measure elapsed time from request to first response, and start there.
