In 2013, two researchers at Microsoft went looking for what code review actually produces. Alberto Bacchelli and Christian Bird studied how teams ran reviews, what reviewers wrote, and what managers believed they were getting out of the ritual. Everyone expected the same answer going in: review is how you catch bugs before they ship. The data said otherwise. Comments about real defects made up about one-eighth of all review remarks, and most of those were surface-level. A missing null check here, a misleading log message there. The deep, design-level catches everyone assumed were the whole point turned out to be rare.

That paper has been quietly correct for more than a decade, and this week it is having a moment. A post arguing that the real purpose of code review is to find code that will be hard to maintain climbed the Hacker News front page, sitting a few slots away from a separate thread titled "Understanding is the new bottleneck." The timing is not an accident.

So if review barely catches bugs, why do the strongest engineering teams treat it as non-negotiable?

The thing review actually leaves behind

The Microsoft study answered that. The through-line in every team they looked at was not defect density. It was comprehension. Bacchelli and Bird concluded that code and change understanding is the key aspect of code reviewing, and that the biggest benefits were knowledge transfer, increased team awareness, and better alternative solutions surfacing before anything shipped.

Read that again with a manager's eyes. When a second person reads your change closely enough to leave a real comment, two things happen at once. The code gets clearer, because the author had to make it explainable. And the number of people who understand that code goes from one to two. The bug catch is a bonus. The understanding is the asset.

For most of software history this was a nice-to-have. You could argue that a fast senior developer who skipped review shipped more. That argument is now over, and AI is the reason.

The bottleneck moved

An agent can produce a 400-line pull request in about a minute. The slow part of building software was never the typing, and now the typing is nearly free. What has not gotten faster is the part where a human holds an entire change in their head and decides whether it belongs in the system. When code arrives faster than anyone can read it, the reading becomes the constraint on the whole operation.

We have written about both ends of what happens when that step gets skipped. On one end, the bus-factor problem: a codebase only one person understands is one resignation away from being a black box. On the other, the cleanup reality: code that shipped fast and unread does not disappear, it waits, and someone pays for it later at a much worse exchange rate. Review is the cheap, boring checkpoint that prevents both. It forces the understanding to happen while the change is still small and the author is still in the room.

What a maintainability review looks for

If you accept that comprehension is the product, the questions change. A bug hunt asks whether there is an off-by-one, whether the edge case is handled, whether the test passes. Useful, and largely automatable. A linter, a type checker, and a decent test suite now catch most of what a human bug hunt used to.

A maintainability review asks a different set of questions, and they are the ones a machine cannot answer for you:

Will the next person understand this in six months? Not the author. The next person, cold, with no context, at 4pm on a Friday.

Is there a simpler version of this that does the same job? Complexity that was obvious to write is rarely obvious to maintain.

Does this name tell the truth? A function called validate that also saves to the database will mislead every reader it ever has.

What breaks if someone misreads this? The most expensive defects are not the ones that fail loudly. They are the ones a future developer confidently misunderstands and builds on top of.

None of those show up in a test report. All of them determine what the code costs to own.

Why this is a business number, not a taste preference

A bug that ships gets found and fixed. It is a cost, and costs are bounded. Code that nobody understands is a liability, and liabilities compound. Every feature built on top of it inherits the confusion. Every estimate against it runs long. Every new hire takes weeks longer to become productive. The gap between those two outcomes is the difference between software you own and software that owns you.

This is why review is not a formality we bolt onto the end of a build. When we take a prototype to production, the review is where throwaway code becomes something a team other than its author can safely operate. And it is a large part of what you are actually buying when you commission custom software you intend to keep for years rather than months.

Turn off the mental model that code review is a bug filter. It is the cheapest moment you will ever get to make sure more than one person understands what was just built. In an era where writing the code is nearly free, understanding it is the part worth paying for.