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.