Code review assumes a human can read what ships. Watch that assumption run out of room — one engineer, then three, then a two-pizza team, then the code nobody wrote.
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.
THE EMPTY TANK · 4 hrs × 400 LOC/hr = 1,600 LOC of genuine review per sprint.
A working engineer also authors roughly 800 lines of their own per sprint (~80 LOC/day sustained). 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 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. Slide through the sizes and watch one engineer's budget respond.
Alone, the tank is empty and the question never comes up. Review is a thing you skip because there's no one to do it. This is the world Fagan never had to worry about.
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.
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. Fagan's inspection 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.