Nobody Reads the Code Anymore
Code review was the last human checkpoint before production. Now, it's a bottleneck that can't scale.
The code review is a dying art. It used to be the last checkpoint before production. A human pulled up the diff, read it line by line, asked the questions that mattered, and signed off. That person was why you could sleep at night. They’d seen the failure before, so they caught it before your customers did.
That checkpoint is gone, and most teams haven’t admitted it yet.
The code still gets written, more of it than ever. An agent ships in an afternoon what used to take a week. It compiles, the tests pass, it looks right, so it merges. The diff that lands in the review queue is too big to read with any care, and there are forty more behind it. The person who used to read every line now skims for whatever looks obviously wrong. Nothing looks obviously wrong. That’s the problem.
Why reading harder won’t save you
The instinct is to read more carefully. Hire reviewers, buy a review tool that summarizes the diff and flags the risky parts, slow down and look.
It won’t hold. The bottleneck used to be typing; now it’s reading, and reading is the part that doesn’t scale. A reviewer can read a function and confirm it’s internally consistent. What they can’t do, at the speed agents now produce code, is hold every invariant of a live distributed system in their head and check each new function against all of them. The invariant that got violated lives in a different file, a different service, last week’s deploy. It isn’t in the diff, and no amount of staring will put it there.
Better review tools answer the reviewer’s questions faster. They don’t reduce the number of questions, and every question is about an invariant the code might have broken. Does this fire once? Does it roll back if it crashes halfway? Can these two writes race? The list is long, and it grows with every service you add. You’ll never read your way to the bottom of it.
Where the question goes next
If you can’t read your way out, the question has to change. Not “how do we review this code well enough to trust it,” but “how do we make the code trustworthy whether or not anyone reads it.”
That’s the only version of the question that survives a world where most code is written by agents and skimmed, not authored, by humans. Correctness can’t keep living in the reviewer’s head, because the reviewer can’t keep up. It has to move down a layer, into the substrate the code runs on: where retries fire once because the runtime makes them idempotent, where a crash halfway through a write rolls back because the transaction is atomic, where two writes can’t race because the system serializes them. Put correctness in the runtime, and the agent can write naive code on top of it while the system stays correct anyway. Not because someone caught the bug in review, but because the bug was never possible to write.
The fear is real, and reading harder won’t make it go away. The last human who read every line isn’t coming back. What can come back is the thing that person gave you: confidence that the code in production won’t betray you six weeks from now. That confidence used to come from a careful pair of eyes on a diff. Now it has to come from the ground the code stands on.