# Code review throughput limits

Code review has measured limits, and they don't move with effort or tooling. Two findings from the review literature recur (see [[reviewing-ai-code]] for Depierre's use of them):

- **Effective speed caps around 400 LOC/hour.** Above that, defect-finding drops off sharply. Actual speed varies with the code's context, kind, and the reviewer's experience, but ~400 LOC/h is the ceiling where review still reliably flags defects.
- **A review session hits diminishing returns past ~1 hour.** This is an attention limit, not a code-coverage one — sustained review degrades after an hour regardless of how much is left, so a reviewer manages only a couple of effective hour-long sessions a day, separated by recovery time of unknown but nonzero length.

The consequence that matters for LLM-assisted development: review does not parallelize inside one head and does not speed up on demand. If the answer to "LLMs get things wrong a lot" is "review everything like an intern's code," then generation throughput is bounded by *review* throughput, which is fixed low. Every ~400 LOC of generated code costs about a senior developer-hour, and a developer has maybe 10–40 such hours a week that also compete with meetings, design, and incidents. The realistic ceiling lands under ~1k reviewed LOC/day including boilerplate, tests, and config. The bottleneck moves from writing to reviewing, and the writing tool can't relieve it.

## The overconfidence multiplier

The caps above come from research on humans reviewing *human* code. Applied to LLM output, the early (limited) evidence is worse on two counts: reviewers of LLM-generated code find fewer defects while reporting higher confidence that they found them all. So the human+LLM pair can ship lower-quality code than human+human while the reviewer feels more assured — the throughput ceiling doesn't even buy the correctness it promises. This is the measured version of the trust problem framed qualitatively in [[credibility-as-slop-test]] and reported first-hand in [[know-thine-enemy]].

## Relationship to other framings

- [[agent-principal-agent-problem]] — Crawshaw's account of *why* review breaks under agents (the effort signal between author and reviewer collapses); this page is the throughput arithmetic underneath it.
- [[code-review-knowledge-transfer]] — the empirical finding that <15% of review comments are about bugs, so review's real value is knowledge transfer; both pages draw on the same literature to deflate "review catches the defects."
- [[stop-using-pull-requests]] and [[ship-show-ask]] — process responses to the cost of blocking review.
- [[skill-atrophy-supervision-paradox]] and [[agentic-coding-fatigue]] — the human-side limits (the supervisor's eroding skill; the 4–5 hour daily judgment ceiling) that compound the throughput cap.
- [[control-the-ideas-not-the-code]] — the opposite prescription: since line-by-line review doesn't scale, stop doing it and hold the design instead.