Maybe You Can Get Rid of Code Reviews

Maybe You Can Get Rid of Code Reviews

June 6, 2026

The pesky human bottleneck of reviewing changes is a hot topic recently.

With AI blasting out PRs as fast as your CFO will let it, humans are sort of getting in the way of capitalizing on all that agentic feature shipping goodness.

Logically then, let’s get rid of human reviews and just have another AI do the reviews. Time is money!

And why not? Well that’s actually a fair question – maybe you can!

And to answer it, we have to review why we were doing reviews in the first place. Ostensibly or otherwise.

Why are code reviews even needed?

Code reviews, like most things, became a thing for a reason, and Chesterton’s Fence reminds us not to do away with things until we understand why they were there.

With code reviews, this is primarily:

Defect detection . Catching bugs and production incidents before your customers do, so that you don’t encourage them to churn out to a competitor or build their own with Claude.

Typically this is catching unconsidered edge cases, emergent behavior, incorrect assumptions and so on. I.e. the kinds of non-obvious logical bugs that would be unlikely to be caught by testing, but would be caught by a veteran developer who’s spent five years learning all the strange ways that codebase can hurt you.

Entropy suppression . Ensuring the codebase remains as simple, coherent, and maintainable as possible over time. This is to slow the superlinear decay of development speed, a key consideration if you’re no longer being showered by the ZIRP money fountain and don’t want to run out of steam quicker than you expected.

Runaway entropy is also a great way to end up with engineers and AI agents spending more time wrestling with the codebase than building the product, while customers discover ever more creative forms of emergent behavior.

Training . Code reviews are one way for developers who’re more experienced in the codebase, and programming generally, to share their knowledge with newcomers.

Of course, that doesn’t mean that’s actually how they’re always done…

That’s the theory, what’s the practice?

In high-performing teams, those goals are indeed usually achieved.

But often, code review becomes performative. A theatrical act, focused on the activity of code review rather than its intent.

The simplest malpractice is of course rubber stamping. Eyeball the code then merge.

One may choose to add a “LGTM” (“looks good to me”) instead of just clicking the button, to add a little more thickness to the facade.

Rubber stamping is common, but it does at least offer the benefit of saving time. If it’s the norm, you’ll lose little by shedding it and using dueling AI models as your code review. Or just telling your agent to check its work. Or nothing.

However there’s another, far worse use of code reviews, that lends itself to many anecdotal tales. And that’s: the pedantry show.

My personal favorite was from early on in my career, in which a coworker was subjected to a code review I would characterize as a struggle session for one.

It involved him being taken into an actual auditorium, and his code being placed on the big screen, whereafter a panel of senior developers plus the head of the division went through his code line by line, sparing nary a criticism that came to their minds.

I heard afterwards that it had “almost turned into a fight”, and that coworker was subsequently quietly shuffled away from coding.

The reason, of course, is that certain super senior developers enjoy the opportunity to pontificate their superior understanding of orthodoxy. The “big picture” is business talk – we’re talking about the craft now!

I’ve been in rooms where debates about indentation formats proceeded desperately, as if people were arguing how to save a patient in imminent peril.

I’ve seen a single line PR go through three change requests. No, they weren’t necessary.

I even once got a change request for having coalesced three exact duplicate blocks of code into a single function, because it might cost “clock cycles”. (This was a web application.)

And yes, tabs versus spaces. They were very serious about it (although I forget for which one).

In these cases, shedding code reviews doesn’t “lose little” – it’s a godsend.

As the recurring joke goes, the large PR gets the "LGTM" while the small one gets the pedantry. The joke, of course, is that this is exactly what happens.

Fortunately, AI has since thrown cold water on all that. Can’t justify arguing for an hour about indentation generated by a computer 40 seconds ago.

(To be clear, I’ve also enjoyed exceptionally well-thought-through code reviews by aces, which accelerated not only my understanding of the codebase in question, but also my development as a programmer.)

AI! must go faster

Given this backdrop, how does AI play into the picture?

I think it can go one of two ways.

In a company where pure speed is all that matters, and...