The title of this blog post is intentionally stupid. It’s actually a really crappy attempt at clickbaiting. It’s bad linkbait because I could have called it “Code review is dead in 2026” or “Code review isn’t dead in 2026”. I could have A/B tested whichever of those 2 headlines attracted more clicks. It’s also crappy linkbait because I have no reach and no plan to fix that.

The honest headline I should have written is actually “Do we want code review anymore in 2026?”. In fact I think that’s how all good engineers should be thinking. You rarely ever “need” something and instead there are tradeoffs that help you decide if you “want” it. The answer to the “need” question is obviously “no”. Nobody needs code review. In fact nobody ever needed code. And plenty of people have been shipping software for years without code review.

An aside about myself

I’ve been a software engineer for over 12 years. I worked as an engineer at GitLab for 8 years building many parts of our product all the way from low level infrastructure like moving search indexes around K8s stateful sets to user facing features like CI. My perspective is heavily influenced by my time at GitLab as this company was purely asynchronous and code review was the most important part of my day to day work for the entire time I was there. It was encouraged, rewarded and required, depending on what level you were at.

These days I’m working at Mistral AI. A company that is at the frontier of AI research and similarly builds enterprise software to help move software engineering practices into the future.

This blog post is purely my own opinions and I have not made any effort to reflect the values or goals of my past or present employer(s).

And back to the code review…

So to examine whether we “want” it we need to know what it was for in the first place.

But before then, let me point out the elephant in the room.

Around the beginning of 2026, or late 2025, many engineers started coming to the realisation that LLMs are just “good enough” or even “better than me” at writing code. This blog post would be a disgrace if I went any further explaining this overly repeated observation. So I end this paragraph here.

For me (and many of my peers) it came a few months later when we started to notice a slightly more interesting outcome. Junior engineers started submitting PRs that looked like they were written by someone with a lot more experience. I started seeing PRs that were implementing incredibly sophisticated database query optimisations with essay length descriptions. These looked similar to the amazing essays I’d see from my most experienced peers after they’d found some profound insight and spent days investigating deeply and they finally emerged to educate us all.

More interesting, however, was that over time I found it harder and harder to spot mistakes in their code. I used to take some satisfaction in spotting mistakes in someone else’s code. It made me feel useful but also it’s just a fun engineering puzzle and, yeah, I dunno, I just like it.

I shouldn’t have been surprised. By this point in time my LinkedIn feed (I don’t use Twitter/X) and podcasts had already been full of people saying this same thing. They were already certain that AI is smarter than you and you shouldn’t bother reviewing code. Many of these people may have been right earlier than me or they may have just had different standards. But, their smugness and mine aside, this was actually finally starting to make me think the same thing.

So today it felt like it was finally time for me to get my thoughts out there in words so I can at least figure out what I think about this topic.

Why did we do code review in the first place?

As I mentioned, people have been shipping serious production grade software for years without code review. Code review has always been questionable in terms of value/effort ratio. I’ve always known people that were convinced the practice was a complete waste of time. I also worked for a couple of years doing “Extreme Programming” where we just pair programmed full time and pushed to master. We never did code review. I liked it. It felt fun, but it’s hard to say if it was “better for everyone”.

One of the biggest complaints that I regularly heard about code review was that it just simply results in a lot of “nitpicking”. There’s the famous “Bikeshedding” parable which basically equates to “The bigger PR the less comments you get”. And this really is true in my experience. The proposed, mature engineering solution to this problem was always to try to codify all your “code style” practices into linting rules. At GitLab we went way further and our RuboCop linters would do a lot more than code style. They’d detect security vulnerabilities, performance issues and a lot more. Whatever we could automate we automated. This meant that human review was always reserved for the highest leverage work.

I have a slightly tangential rant here about the industry replacing real software with non-deterministic, slow and expensive token based automated analysis. My rant points out the sheer stupidity of writing a CODE_REVIEW.md that is translated to input tokens for every PR review bot that simply states “don’t import x inside of a y module”. When you could have just as easily asked an LLM to write a linting rule that enforces exactly the same thing. I could rant more here but, like I said, this was a tangent from my point.

The interesting thing that many of us already learnt years ago was actually that code review was kinda always bad for spotting little mistakes or minor style issues. Not only did everyone hate giving and receiving such feedback but we also were really unreliable at doing it. Humans trying to compile code in their head to spot mistakes was always a waste of time. And good code reviewers would always prefer to give higher level feedback and would always be hoping that automated and manual testing would be how we caught the mistakes.

So what were good reviewers doing and what was the point of code review?

First and foremost, there are two people involved in code review. Some people seem to assume that the code review is intended to be for the person receiving feedback. Many strong leaders identified years ago that code review is just a practical way to share knowledge. They also knew that sharing knowledge was in both directions. Even if the code author surely knows more than the reviewer you still have knowledge sharing because now the reviewer gets to learn from the author even if they leave no comments.

The last paragraph is still rooted in the assumption that humans can and should be reviewing the code. And I don’t really want to take a stance on that and don’t trust anyone that thinks they know the answer to this question.

But it’s also beside the point. Because the code review has always had many levels of analysis. And for good reviewers the first level of analysis was always “why are you doing this at all?”. A second level of analysis was “OK so I guess I agree that we should do this, so then is this approach roughly the approach I’d take to solve this problem?”.

And both of these levels of analysis are educational in both directions. The reviewer and the author can both learn from asking and answering these questions.

The other really interesting thing is that these questions scale from 1 line of code to 1M lines of code. You can always ask and answer them at that level of granularity. In fact, if neither the author nor reviewer could answer them at some level of granularity then I’m quite confused whether or not these people are needed in the software development lifecycle at all.

It’s hard for me to explain this better but I hope you can see that there’s still a chance it might be useful for you to ask your colleagues “hey why are you doing that?” and that there may still be a granularity of code review slice that fits this question for your organisation. But again people got away without code review in the past. Those people tended to either be lone warriors or their team baked this question in at some other point in the process.

Which brings me to the final idea I want to convey. The question everyone is asking about code review today may not actually have anything to do with code review at all. They may actually be asking if we need teams at all. “Why do I care what my coworkers think about this PR if I didn’t even read it?” is kinda a bad question when the coworker may only need to read the title of the PR to tell you “yeah we don’t actually want this feature…” or “hey that’s an interesting feature that helps me solve some other problem”.

But like I said, I think many of the people asking whether or not we need code review today might also be asking whether or not they need peers. Do you think your coworkers have nothing to teach you? Do you think that it’s a complete waste of time to teach your coworkers about what you are doing? If the answer is “Yes” to both of these questions then you probably just don’t like working in teams. And maybe that’s okay. There have been some really awesome pieces of software built by clever engineers that suck at (or hate) working in teams. It’s okay.

But this is really my final thought and somewhat unanswered question. The rest of this debate is kinda stupid and the only thing I want to know is whether or not people still need teams. Most of us are still working in teams. Code review was just the step that teams evolved for asking “why are you doing this in the first place?”. It follows, for me, that code review has some value in that context.

But if people tell me that individual engineers can ship faster without a team then I’d probably respond with “no shit!”. It’s not even really AI. If you’ve ever worked on code before where you are “purely in the zone” you can arrive at this conclusion for yourself. It was true 20 years ago and it’s true today. Linux, Git, GitLab and Vagrant were originally built by one person. They were impressive from day 1 and then went on to be built by large teams of people. They arrived at a much lower awesome/engineer ratio. Bit by bit we learnt the lessons of the “mythical man month” and the obvious fact that “nine women can’t make a baby in a month”. But for some reason we kept working in teams. Teams have overhead, teams are painful, communication is painful. All of this was always “bad”.

But we kept doing it. So why did we do it? It must have worked. Nearly every successful startup or product grew their team over time. Every one of them learnt the “less than linear” scaling laws that come with team work. All of them also learnt the challenges that come from managing people or just working with people that aren’t exactly the same as you.

But we kept doing it! We kept doing it…

Why?

Maybe it works?