What are we actually getting out of code review? — My Blog

← All posts

I've been sitting with a question I can't fully shake: at what point does mandatory code review stop being a safety net and start being a tax?

The standard framing is that code review exists to catch mistakes, share knowledge, and maintain standards. All of that is real. But I think it quietly does something else too — it functions as a continuous, low-grade signal of "I'm not sure I trust you yet." And unlike most trust signals, it never expires. After 100 pull requests in the same part of the codebase, the ritual looks identical to the first one.

I'm not saying trust should be unconditional. Open source projects genuinely depend on skepticism — the "Mini Shai-Hulud" supply chain attack is a good reminder that goodwill from strangers can be exploited slowly and patiently. That's a real threat model. But a company where you know your colleagues, where someone gets paged when production breaks, where accountability is clear — that's a different situation. I wonder if we've imported the open source model wholesale without asking whether it fits.

When Code Review Works

There's a version of code review where it's genuinely valuable: a senior engineer catches something subtle, a teammate spots an edge case the author was too close to see, a new hire learns how the team thinks. I've experienced all of those. They're good.

But there's also a version where review becomes a queue that everyone submits to and hopes empties fast. Where refactoring sits unloved because it lacks the urgency of a deadline. Where the developer who owns a system — the one who gets woken up at 2am when it fails — waits on someone else's availability before they can merge a fix they've already thought deeply about.

The cost of that waiting is real, and it's oddly invisible in how we talk about engineering productivity. We measure time-to-merge rarely, and friction almost never.

Common Objections

A few counterarguments I find myself taking seriously:

"Someone else will have to maintain this eventually." True, and fair. But I'd push back gently: the best thing you can do for future maintainers is write clear, well-tested code — not necessarily have it reviewed. Review can catch some of that, but it's a pretty indirect mechanism compared to just making the standard explicit.

"Even trusted engineers have bad days and make mistakes." Also true. Though I'd note: we've all shipped bugs that sailed through review too. The question isn't whether review catches some things, it's whether the cost-benefit math works out across all the changes, not just the ones that went wrong.

"Compliance requires it." This one I'm least convinced by. If you need an audit trail, there are more targeted ways to get it than requiring human sign-off on every change. AI can produce a review artifact. The auditor cares that a check happened, not necessarily who performed it.

The Changing Landscape

What I keep coming back to is that code review made a lot of sense as a default when the alternative was undocumented cowboy deploys. In that world, any review is better than none.

But I think we're at a different moment now. AI tools are legitimately good at catching the class of bugs review was meant to catch — typos, logic errors, missing cases. Teams have better observability. Deploys are more reversible. The risk profile has shifted.

Maybe the question isn't "should we do code review?" but "what specific failure mode are we trying to prevent, and is mandatory review the most efficient tool for that?" For some teams, the answer might still be yes. For others, I suspect the honest answer is that the process has become load-bearing habit more than intentional design.

I'd be curious whether anyone has actually tried loosening review requirements for trusted engineers with clear ownership — and what happened. My instinct is that the results would be more boring than the discourse suggests.