Nobody reads the code anymore

Code review in the age of code you didn't write

An 800 line pull request lands in your queue. A model generated it in about ninety seconds, at the request of a colleague who read maybe half of it. You scroll through it for four minutes, leave a comment on a variable name, approve. If this hasn't happened to you yet, it will this quarter. And I want to argue something slightly uncomfortable about it: the problem isn't that you skimmed. The problem is that we keep pretending reading was ever the point.

This is a follow-up to The long walk away from the machine, where I argued that AI writing your code is the next rung on an 80 year ladder of abstraction, and that the one genuinely new thing about this rung is that it's probabilistic where every previous one was deterministic. That post ended with a tidy sentence about the human's job shifting from writing instructions to verifying intent. Tidy sentences are easy. What does verifying intent mean on a Tuesday afternoon with six generated diffs in the queue? This post is my attempt at an answer.

Reading was always the cheap check

Code review has a stated purpose and an actual track record, and they diverge more than we like to admit. The best data I know of is old: in 2006 SmartBear instrumented ten months of code review on Cisco's MeetingPlace team, about 2,500 reviews, and published the results in Jason Cohen's Best Kept Secrets of Peer Code Review. The finding everyone quotes is that past roughly 400 lines in a single sitting, defect discovery falls off a cliff. Which means reviewers were skimming long before AI showed up. We just didn't have to notice, because a productive human wrote a few hundred lines a day and the budget roughly covered it.

What reading the diff actually bought you was a bundle of verified claims: this does what the ticket says, it doesn't quietly break an invariant three files away, the next person will be able to change it. Reading was the cheapest available way to check those claims. That's all it ever was.

Then the volumes came apart. Claude or Cursor will hand you two thousand lines before lunch, and the 400 line budget didn't move an inch. Something in the ritual had to snap, and what snapped, quietly, is the meaning of approval. It used to mean "I verified this". On a lot of teams it now means "this looks like code". I've written before about how a model's confident wrong answer and its correct answer look identical until you hold ground truth; the same goes for diffs. Wrong code that reads well is the failure mode, not an edge case.

Compilers earned it once

But hang on, you might say: you don't read your compiler's output either, and nobody calls that negligent. True. The reason is worth spelling out though, because it doesn't transfer. GCC's translation is deterministic. Same input, same output, for everyone, for decades, across hundreds of millions of builds. When a compiler bug surfaces it makes mailing lists, gets a number, gets fixed for everybody at once. The trust was built up once, and every compile since has gotten the benefit. Your build inherits it for free.

A model's translation starts from zero every time. Same prompt, different code tomorrow. Yesterday's correct output tells you nothing about today's, and there is no equivalent of "this compiler has been stable since 4.2" to lean on. Each generation has to earn trust on its own. Per-output verification, at ten times your reading budget, by reading? The arithmetic doesn't work, and I don't believe anyone diligences their way out of arithmetic.

Review the evidence, not the text

What does work is the thing we already do for every other component too big to read. Nobody at your company has audited Postgres. You trust it because it keeps your data, enforces your constraints, and has survived every pulled plug so far. Verification at the boundary, against behavior, is how software has always absorbed things it couldn't afford to read.

Applied to a generated diff, that means the evidence gets reviewed instead of the code itself. Did a human write the tests, or at least read them and agree they say what "done" means? Do the schemas and types actually reject wrong shapes, or are they decorative? Did anyone run it? CI passing is the bare minimum; I mean a person exercised the feature and watched it do the thing. When that evidence is solid, whether line 412 is elegant stops mattering. When it's missing, no amount of staring at line 412 will save you.

The tenth you still read

Behavioral checks have a blind spot, though, and it's a big one: they only catch the failures somebody imagined. A test suite is a list of the ways you already knew things could go wrong. So the code that still deserves a slow human reading is the code where the unimagined failure is the expensive one.

My list, held loosely: auth and anything that parses untrusted input, because an injection hole passes every test that doesn't attack it, and models have no instinct for adversaries. The irreversible stuff, payments, deletes, outbound email, migrations, the same category I flagged when writing about what your agent can't do, because there's no retry. Interfaces that ossify, since a bad line of glue costs an afternoon while a bad shape in a stored format costs years. And the silent failures, concurrency, money arithmetic, timezones, which pass every test for months and then one day don't.

On a typical diff that's maybe a tenth of the lines. Read that tenth like it matters. Let the rest go the way you let the bytecode go. I'm aware this is uncomfortable advice, it feels like being told to lock one door carefully and leave the others open. The counterargument is that right now we pretend to lock all of them, and pretend-locked doors are worse than doors you know are open.

What survives the rewrites

There's a longer-term thought here that I keep circling without quite landing. The tests, the schemas, the invariants, the gates, the short list of files that still get real reading: that collection is starting to look like the actual source code, in the original sense of the term. The artifact humans author and trust, from which everything else is derived. Meanwhile the generated code keeps getting rewritten underneath it. GitClear's report on 211 million changed lines had code revised or discarded within two weeks climbing from 5.5% to 7.9% as assistants spread, and I'd bet this year's number is higher. The contracts are what persist.

I don't know how far that inversion goes. Maybe code review survives as a named activity, maybe it dissolves into spec review plus a security pass. But when I ask myself what I'd want a new engineer to be good at five years from now, "reading a 2,000 line diff quickly" doesn't make the list, and "writing down what correct means, precisely enough to check it mechanically" is near the top. That skill was always underrated. It might be about to become the job.