Code review was never really about finding bugs

Here's where a few months of tiered reviews landed me: most of the code review process should be automated, and human review is only useful when applied strategically. Not line-by-line. Not as the mandatory gate on every change. The human belongs where machines are weak, building understanding and spreading knowledge, and almost nowhere else.

It feels uncomfortable to write after two posts arguing for a more careful, more measured review process. But the more I ran tiered reviews and the more I read the research, the harder it became to defend the way most of us still review code.

If you're just joining, the short version of the earlier posts: we were drowning in AI-generated pull requests, so we started classifying every PR into risk tiers
and applying different scrutiny to each, then went looking at how to make that classification measurable. It worked. We split large PRs into smaller ones, people paid closer attention, and adding AI to the review surfaced bugs and design problems we'd apparently been missing by hand for years.

That last part is what nagged at me. We'd been missing them by hand, for years.

We think we find bugs, but we're not

Line-by-line human review demands intense, sustained attention, and it doesn't scale. A careful reviewer can take a long time on a single PR, and the effort grows with the size of the change. Most people don't have the tenacity for it. Most teams have one lead developer who's good at it, and that person is a rare resource. So even in the best case, review is
bottlenecked on the attention of the one person who's good at it. That was true before AI. AI just turned up the volume and caused a bunch of trouble.

The research is blunter than my own experience was. Bacchelli and Bird's study of code review at Microsoft found that while finding defects is the number-one motivation for reviewers, defects were only the fourth most common outcome of reviews. The most frequent outcome by a wide margin was code improvement: readability, consistency, and dead-code removal. Taste, essentially.

Which raises a question I don't have a settled answer to: how much does taste-policing matter now that AI writes so much of the code? Some of it is genuine design judgment. A lot of it is style that a formatter or a linter should have handled before a human ever looked.

And as for the design judgment: Jurre Brandsen put this quite well when we discussed the topic: "Why didn't we address the design discussions before we started writing code in the first place?!" And I can only agree with his stance.

The same Microsoft study yielded two findings that I had to discuss with Joop Snijder, as they significantly changed my perspective. First, a small number of reviewers used the review to teach. They pointed the authors to documentation or resources that would help them solve the problem better. Review turns out to be good for more than catching mistakes. Second, and most important: what reviewers actually spend their time on isn't finding bugs, it's understanding what changed and why. You can only spot a design flaw or a logic error once you've reconstructed the intent behind the diff. Large pull requests make that brutal, because you're deriving meaning from a wall of syntax. That, I think, is the real reason AI-generated code causes so much review pain. And it makes me wonder, shouldn't we
spend our attention on understanding design before we write or generate code?

AI is a double-edged sword here. It makes changes larger and more complex, worsening the understanding problem. But it's also very good at exactly the thing humans are bad at: finding patterns across more syntax than any person can hold in their head at once.

The three places AI is powerful

If the goal is to spend human attention where it's valuable, the strategy writes itself. Three moves have made the biggest difference for us:

• Let AI summarize the change. A generated walkthrough that explains a diff in plain language cuts the single most expensive part of review, reconstructing intent, down to something you can skim before you open a file.
• Use AI as the first pass. Human review has value, but it shouldn't be the thing that catches the obvious stuff. Let the agent flag the prominent issues first. And I think you should go further and have AI fix that first batch before a human ever sees the PR.
• Let AI highlight the risks in your change. Have it identify the parts of a change that require human oversight and estimate their severity. That's less time hunting for the risky bits and more attention spent on them. This works well if you explain what you find important about your application and what parts are risky to change. Just add it to your AGENTS.md, and AI will have a great time identifying risk for you.

None of this removes the human. It changes what it means to be human. We still look at the code for now; AI enhances what we do rather than replacing it. Where this ends up, honestly, I'm not sure. What I am sure of is that I have better things to do during my workday than spend the whole day on review.

The field is already moving past the human gate

I'm not just shouting random things at you here. Martin Monperrus argues, quite effectively, for stopping human review before it becomes the bottleneck.
His case, boiled down:

• Enforcing style and catching bugs is now done more effectively by automation and agents than by people.
• "Agent writes the code, human mandatorily reviews it" is not a stable endpoint. It feels safe, but it provides the illusion of assurance while quietly turning review capacity into your next delivery bottleneck, one that grows in lockstep with the productivity AI delivers.
• The cost-benefit of human review versus AI-assisted review has flipped. Agent reviews are instantaneous, consistent, and auditable in a way a threaded comment history never is.

You don't have to accept every claim in that paper to feel the direction things are going.

Social friction is the final reason to switch

Social friction is the final argument to automate code review. Human review is a social act. It needs tact between the author and the reviewer, and it can be difficult to maintain.

Google's case study of its own review process showed that two recurring breakdowns were about tone and power. Negative-toned comments are less likely to be perceived as useful, so they simply don't get acted on. And people sometimes weaponize the review to drag things out and withhold approval. Both leave mostly junior developers frustrated, and frustrated junior developers are slower and learn less.

A machine sidesteps all of it. It delivers the same feedback without the edge, and people take it differently because it comes from software. I've watched teammates curse at the AI reviewer, and the AI, of course, does not care, does not remember, and does not retaliate on the next PR. No relationships damaged, no quiet delays as a result. The wrong tone and power games are a delivery risk.

Where I've landed

So, after spending months trying to find an answer to code reviews, here's the end of it:

• Automate most of the review process. It's cheaper, faster, and better for relationships on your team.
• Keep human review, but make it strategic. Point it at the two things machines can't do well: building an understanding of the system and spreading knowledge across the people who work on it.

Finding bugs was never what we were actually good at. Understanding, teaching, and shared ownership were. It took handing the mechanical part to AI for me to realize the valuable part had been hiding underneath it the whole time.

I don't know exactly where this goes from here because the capability curve is steep, and I'd be lying if I said I could see the top of it. But I'm no longer trying to defend line-by-line human review as the default. The default should be automation. The human is the exception, applied on purpose, where it counts.