Code review: what humans catch, what tooling should, and why latency is the real cost

A 1,800-line PR lands Friday at 5pm: a new billing flow, a schema migration, and a refactor, all in one diff. Two reviewers leave four comments — a rename, a missing semicolon, a “nit: prefer const” — and approve. Three weeks later the migration double-charges a cohort of customers because a retry path wasn’t idempotent. Nobody saw it. The diff was too big to actually read, so the reviewers reviewed what was easy to see: trivia. The real flaw was in the design, and the design is exactly what a giant LGTM’d PR hides.

Review catches what tooling can’t

A senior reviewer’s scarce attention should go to the things a machine cannot judge: is this the right design, does it actually do what the ticket intended, will the next engineer understand it, is the error path correct, does it open a security hole. Google’s own standard puts design first — “the most important thing to cover in a review” — because design choices compound and are expensive to undo later, while a misplaced brace costs nothing.

Everything a tool can decide deterministically should never reach a human. Formatting, import order, naming conventions, lint rules, unused variables — run a formatter and a linter in CI and make them blocking. The moment a person types “nit: spacing,” you’ve spent the most expensive review resource you have (senior judgement) on the cheapest possible problem, and you’ve taught the author that review is about surface. Google’s engineering culture is explicit: automate style enforcement so style never reaches review, then train reviewers to spend their attention on correctness, security, and architecture.

Latency is the cost nobody measures

The number that matters most isn’t defect count — it’s turnaround. A PR is blocked work: the author can’t merge, often can’t start the next thing cleanly, and every hour it sits is an hour of someone’s progress frozen. The data is stark. Analysis across roughly 8 million pull requests found elite teams close the full review cycle in under 26 hours, while lagging teams let PRs sit a week before review even starts. The single biggest chunk of that time isn’t reviewing — it’s the initial pickup, the gap before anyone looks. Distributed teams pay another 8–16 hours per round just to timezone gaps.

That idle time has a price. The same analysis put the cost of review-bottleneck waiting at roughly 5.8 hours per developer per week, around $238K/year of frozen time for a ten-person team — and that’s waiting only, not the review itself. This is why DORA treats lead time as a core health metric: slow review directly degrades throughput, and a team optimising purely for “thorough review” while ignoring latency is trading a small defect win for a large flow loss.

Small-PR economics: defect detection falls off a cliff

SmartBear’s study at Cisco — 2,500 reviews over 3.2 million lines of code, the largest of its kind — found the sweet spot is 200–400 lines of code per review. Inside that band, with the review spread over no more than 60–90 minutes, you get around a 70%+ defect yield. Push past 400 lines and detection drops sharply; the human stops reading and starts skimming. Pace matters too: reviewers going slower than ~400 LOC/hour were above average at finding defects, but past ~500 LOC/hour, defect density came in below average in 87% of cases.

This is the mechanism behind the rubber stamp. A reviewer faced with a 1,800-line diff doesn’t have the budget to hold it all in their head, so they do the only thing that fits: they comment on the things that are locally visible (a name, a style nit) and approve. The giant PR doesn’t get more scrutiny for being big — it gets less, because attention doesn’t scale with size and the reviewer’s cognitive limit is fixed. Big diffs are where real design flaws hide precisely because they’re the diffs nobody can fully read.

The senior tradeoff: thoroughness vs throughput, sharing vs gatekeeping

Every review is a bet on where to spend a fixed budget. Crank thoroughness to the maximum and you slow the whole team’s flow; optimise purely for throughput and defects leak. The senior move is to spend depth where the risk is — the design, the data migration, the auth boundary, the money path — and to let low-risk diffs through fast. Google’s standard codifies this with a deliberately humane rule: approve once the change definitely improves overall code health, even if it isn’t perfect. “Not perfect” is not a reason to block; “makes the codebase worse” is.

The second axis is cultural: review as knowledge-sharing versus review as gatekeeping. Done well, review spreads context — the author learns the system, the reviewer learns the change, and the bus factor goes up. Done as a status game, it becomes bikeshedding (Parkinson’s Law of Triviality: people argue endlessly about the colour of the bike shed because it’s the only part they understand) and gatekeeping, where a reviewer blocks to assert control rather than to improve the code. The tell is a thread with twelve comments about naming on a PR whose actual design flaw shipped untouched. A review that nitpicks trivia while waving through a flawed design has inverted its entire purpose.