Reading mode. This essay has a playable companion — slide through team sizes, flip on the dependency iceberg, and watch a reviewer’s budget flood. Open the interactive version →

Code review rests on a quiet assumption: that a human being can actually read what ships. Not approve it, not skim it — read it, with enough comprehension to catch the defect hiding in line 214. Follow that assumption honestly, from one engineer to a team to the code nobody on the team wrote, and it runs out of room. Not because anyone is lazy. Because of arithmetic.

The budget

Start with the physical limit. The largest study of its kind — ten months and 2,500 reviews across 3.2 million lines at Cisco, run by SmartBear — found that reviewers spot defects effectively at around 400 lines of code per hour, and that detection falls off a cliff above 400 lines in one sitting and after 60–90 minutes of continuous reading. Review isn’t typing; it’s comprehension, and comprehension has a clock speed.

Give one engineer a generous, honest allowance of four focused review-hours per two-week sprint — real reading, not skimming. That’s a hard ceiling of about 1,600 lines they can actually review well before the sprint ends. Everything downstream is a story about what we pour into that tank.

A working engineer also authors roughly 800 lines of their own per sprint (~80 LOC/day sustained, per NDepend’s long-run averages). Alone, there’s no one to review it — so they self-review and ship. The tank sits empty because the demand hasn’t arrived yet. It’s about to.

The team

The moment a second person joins, code review stops being optional hygiene and becomes an obligation: your output has to be read by someone who isn’t you. Every teammate you add is another author whose lines land in the shared tank — and a fully-connected team means more context-switching, the single biggest drain on review throughput.

Amazon’s rule of thumb — a team you can feed with two pizzas, so usually six to eight people — exists precisely because coordination cost grows faster than headcount. At three engineers, internal review already eats a real slice of each person’s budget, but it’s still breathable; this is the size where code review feels like it “just works,” and where most of our instincts about it were formed. At the two-pizza team, the coordination tax pushes internal review most of the way to the line — and we haven’t added a single line of external code yet. This is why big PRs rot and reviews turn into rubber stamps.

The iceberg

Here’s the number that breaks the model. By most estimates, 70–90% of a modern application is open-source code you pulled in rather than wrote. Black Duck’s 2025 audit put the average application at roughly 900 dependencies; GitHub, describing its own dependency graph, says that in some cases 95–97% of your code is someone else’s. And 71% of the vulnerable components in that data were transitive — libraries your libraries dragged in. Nobody on your team chose them. Nobody reviewed them.

For every 800 lines an engineer writes, something like 3,200 lines of dependency code ride into production behind them at an 80/20 split. Put that against a 1,600-line review budget and the meter doesn’t stretch — it snaps. Roughly, dependency code alone is dozens of times an entire sprint’s review budget, reached the instant you resolve the tree.

Log4Shell in 2021 was this arithmetic becoming visible all at once: teams spent the weekend not fixing a bug but inventorying their own systems, trying to answer for the first time what was even in there. The XZ backdoor in 2024 was caught by a single engineer noticing a half-second delay — luck, not review. Michael Fagan’s original inspection process worked because a human’s understanding stood behind every line. We now ship systems where, honestly, it doesn’t — and the only reviewer left that can read at the scale of the flood is not a person.

---

Model inputs: 400 LOC/hr effective review (SmartBear/Cisco, 2,500 reviews) · 4 review-hrs/sprint · 80 LOC/day authored (NDepend) · 70–90% OSS + ~900 deps/app + 71% transitive (Black Duck 2025, GitHub) · two-pizza team ≈ 8. Figures are deliberately conservative round numbers meant to show a shape, not certify a decimal.