The capacity math on human review broke years before AI arrived. That is an argument for spending the review budget deliberately, not for zeroing it.

The Diagnosis Is Older Than the Panic

There is a recurring argument on LinkedIn right now about whether anyone still reads the code that AI wrote. The best version of it points out something uncomfortable: exhaustive human review was already dead long before coding agents showed up.

The evidence is hard to argue with. SmartBear’s study of code review found that human effectiveness peaks at roughly 300 to 400 lines per hour and collapses after about an hour of continuous reviewing. Past that point you are pattern-matching on indentation, not reasoning about correctness. Meanwhile the offshore era of the early 2010s routinely asked one onshore engineer, already buried in meetings, to “review” the output of twenty remote developers. Nobody actually did that. They spot-checked, they hoped, and they clicked approve.

Read Less Code, Not No Code

Agents made the arithmetic worse, not different. A coding agent produces a couple of thousand lines in fifteen minutes, and it does that all day. If your quality story is “a human reads every line,” you do not have a quality story, you have a ritual. The approval is still there, but the comprehension behind it left years ago.

So far I agree with every word of the diagnosis. Where I get off the bus is the conclusion: that reading code is no longer the path, and fast quality gates should replace it. That treats review as one undifferentiated activity that either scales or dies. It is not one activity, and the interesting engineering starts exactly where that framing stops.

Pretend Review Is the Real Enemy

The strongest point in the “stop reading” camp is one I want to keep: pretend review is worse than honest non-review. A skim that ends in an approval launders unverified code through a process that looks like verification. The green tick tells everyone downstream that a human understood this change, and no human did. That is how a lights-on pipeline quietly becomes an unreviewed one wearing a review’s clothes, which I wrote about in Lights-On vs. Dark Software Factories.

A review process you cannot actually perform is a liability, because it manufactures false confidence at the exact point the system claims to be checking. If the choice really were “read all 5,000 lines badly” versus “read none and rely on strong gates,” the gates would win. The SmartBear numbers are not a criticism of reviewers, they are a description of hardware limits. You do not fix a hardware limit with exhortation.

But that is a false choice, and accepting it costs you the one thing gates cannot produce.

What Gates Do, and What They Cannot

I run heavy automated verification on everything: types, lint rules that encode architectural decisions, generated contracts, property tests, CI/CD suites, browser checks at the end of the loop. Quality gates are information filters: each one collapses a huge space of possible defects into a binary signal that costs me nothing to consume. The trust-but-verify protocol pushes this further by making the agent produce the verification artifacts themselves, so I review test output instead of implementation.

This stack does the bulk of the defect-catching, and it should. Anything a machine can check, a machine must check, because every mechanically checkable property that a human verifies by eye is review budget set on fire.

What the gates cannot do is tell me whether the change is right. They verify the properties I already knew to encode. The defects that hurt are the ones outside that set: the migration that passes tests but breaks during rollout, the abstraction that duplicates one we already have, the retry that hides a state-machine bug, the feature that satisfies the spec and misses the point. My review scope ladder exists because correctness above diff level depends on context no gate currently holds. Gates are a compression layer for human attention, not a replacement for it.

Spend the 400 Lines Where Being Wrong Is Expensive

Here is the reframe I think the debate needs. The SmartBear number is not the obituary of code review. It is a budget: roughly 400 well-read lines per reviewer hour. Once you see it as a budget, the question stops being “can we read it all?” (no, and you never could) and becomes “which 400 lines?”

Read Less Code, Not No Code

That question has an engineering answer. Blast radius decides how much budget a change deserves: a copy edit gets a glance at the rendered page, a billing migration gets release-scope and live-scope review with my full attention. Within a change, risk ranking decides which lines consume the budget first.

This is why I built diff-core. Agents open 50-plus file PRs as a matter of course, and a flat, alphabetically ordered diff at that size can only be skimmed. Diff-core builds a symbol graph from tree-sitter ASTs, clusters changed files into flow groups by data-flow reachability, and ranks the groups by risk, so I read the diff in the order the code executes, riskiest flows first. When my hour runs out, it ran out on auth and money, not on a README and a test fixture that happened to sort earlier in the alphabet. The answer to agent throughput is not removing the human gate, it is engineering the gate so a human can actually stand at it.

Reading Is Also How Judgment Compounds

There is a second thing the “stop reading” position quietly discards. Review is not only defect detection. It is how the mental model of the system stays current, and the mental model is what everything else runs on: which gates to build next, which failures to encode as lint rules, which parts of the codebase to never let an agent touch unsupervised.

The 30% cliff is what happens to individuals who skip comprehension: every fix becomes a blind edit to a black box. A team that stops reading entirely walks off the same cliff in slow motion, a failure mode I call cognitive surrender. The gates keep catching the defect classes they were built for, while the humans lose the understanding needed to notice the classes nobody encoded yet. Comprehension debt does not show up in CI. It shows up six months later as a system nobody can safely change.

The gate is where my judgment compounds. Every risky diff I actually read teaches me something about how the agents fail, and those lessons become the next lint rule, the next test oracle, the next category of change I can safely stop reading. That last part matters: the set of things I read shrinks deliberately, category by category, as the verification for each category earns trust. That is a controlled migration. “Stop reading, it never worked anyway” is the same migration performed as a shrug.

Where I Land

So my answer to “what are you doing instead of reviewing it all?” is a stack, not a substitution. Machines verify everything machines can verify, and that set grows every time a review teaches me a new rule. Risk ranking and flow ordering compress what remains into something a human can genuinely read inside the biological budget. And a human still decides what merges, because the properties that matter most are the ones nobody has managed to turn into a gate yet.

Reading every line has been impossible for fifteen years. Reading the right lines has never been more tractable. The lesson of the broken capacity math is to aim the reading, not to abandon it.

Related

Sources

What's your reaction?
This website contains links to some third party sites which are described as affiliate links. These affiliate links allow us to gain a small commission when you click and buy products on those sites (it doesn't cost you anything extra!). understandingdata.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for website owners to earn advertising fees by advertising and linking to Amazon and any other website that may be affiliated with Amazon Service LLC Associates Program.