Maybe You Can Get Rid of Code Reviews
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 tokenmaxxing is the order of the day, the three goals of code review don’t apply anyway.
Defects are basically being asked for, and customers are the QA. “Entropy” is some engineering gobbledygook (along with “technical debt”), which will maybe affect us in the future if at all, so no need to worry about that. Training is wasted time that could have been spent spawning more agents.
Hence, get rid of it, or have AI check itself and call it code review. And if the AI does flag something, well it won’t get upset if we hit merge anyway. XGH methodology for the win.
In a company that’s looking to remain competitive in the future though, instead of having vibe coding entropy grind it to a halt, the original goals very much do apply.
First and foremost, this means the reviewer must understand both the code being changed and the code surrounding it. They should also understand it better than the pull requester – code reviews should go in the direction of increased experience.
That doesn’t mean they must have read and understood every last line. Experienced developers cultivate a kind of “skim reading for code” skill, quickly identifying and concentrating on high risk areas rather than mentally playing through the entire logical flow.
Secondly, the reviewer’s mandate is to achieve the goals of code review only. No pedantry. (A big blind spot in many companies is not having someone periodically review the code reviews and call out weak or performative reviews.)
That’s it. A code review from an experienced developer is actually quite fast. No stylistic requests, no minor refactors that make little difference, no bikeshedding. Instead you’ll more often see a single consequential intervention, like “module X has a dependency on this and this change will break it in situation Y because Z”.
AI-based development shoots you up the entropy curve faster. So you either try to suppress that curve, by having engineers understand the code, use that understanding as guardrails, and share that understanding with others, or you accept a future rebuild.
It’s easier for a competing startup or self-builder to get the green light on that rebuild, though. “Build the exact same thing but right” will not be getting “WSJF’d” by product.
So should you code review?
It basically comes down to three questions.
Do you care how fast your development pace is in two years?
Does it bother you how often you have production incidents or your customers report bugs?
Do you have someone capable of reviewing your code reviews and intervening when they drift into rubber stamp or pedantry territory?
If the answer to all three is no, then code reviews are just overhead. Time to get rid of them.