Professional-leaning hook + takeaway. 1–3 short paragraphs perform best.
Code review rests on a quiet assumption: that a human can actually read what ships. I built an interactive piece to test that assumption. It doesn’t survive contact with the math.
Start with the one number that matters. The largest study of its kind — 2,500 reviews across 3.2M lines at Cisco (SmartBear) — found reviewers catch defects effectively at about 400 lines/hour, and detection collapses after ~60–90 minutes of reading. Give an engineer a generous 4 focused review-hours per sprint and you get a hard ceiling: ~1,600 lines they can truly review.
Now fill the tank. On a two-pizza team (6–8 people), coordination overhead alone pushes internal review most of the way to that line — before a single line of external code. Then add the part nobody talks about: 70–90% of a modern app is open-source code you pulled in, not wrote. ~900 dependencies in the average app. In some cases 95–97% of your codebase is someone else’s, and 71% of vulnerable components are transitive — dragged in by your dependencies’ dependencies.
Put dependency code against a 1,600-line budget and the meter doesn’t stretch. It snaps. Log4Shell was that arithmetic becoming visible overnight. XZ was caught by luck, not review.
The honest conclusion: at modern scale, the only reviewer that can read what actually ships is not a person. That’s not a process failure. It’s arithmetic — and it reframes what AI code review is actually for.
Playable version (slide the team size, flip on the dependency iceberg) in comments. 👇
Link back to: https://jasonburt.page/blog/code-review-capacity