Code Reviews still matter

I read a lot of people saying that in a world of AI generated code, the bottleneck to productivity will become code reviews. Heck, at work too there is a lot of new scrutiny into the code review flow, which makes me think that there is a lot of chatter at the executive level of companies about the supposed impact of the new capabilities of AI systems to generate more code. I also see a lot of new tools in this space implementing automatic code reviews. While I understand that an assistant can be useful in this space, spotting things that humans wouldn’t necessarily see, removing the need of being annoying about typos and so on, the industry is generally missing a point about who we write code for and in connection to that, why we do code reviews. I’m writing this post to tell my take.

Who do we write code for?

We write code for other humans, we don’t write for the machines. Machines don’t need our higher level languages, they want much lower level representations (assembly) which ultimately turn into 0 and 1s. If we are writing only for the machine and no other human is supposed to look at the code, why are we bothering with higher level languages at all? The reality is that, even if code is generated by a machine, we are still writing code for other humans. We are because AI agents and co aren’t intelligent and they can’t reason. They don’t know why we do things, they don’t understand the wide state of the world and that means we are required to keep working on systems and contribute to them. To do so, we need to be able to read the code of those systems and understand what is going on. If that matters, even only during emergencies, code needs to stay easy to understand and read.

If we still write for humans, what happens to code reviews?

Basically, nothing. Code reviews are more than just looking at typos and seeing if code makes sense. Code reviews are a meeting point between an author that is familiar with the matter and someone that isn’t as familiar. Code reviews are a production test of the ability to understand code in a team. They are a knowledge sharing exercise, in which the reviewer learns something from the author and the author learns something from the reviewer. If we remove this learning, offloading the review experience largely to bots, what will happen to the skills of the team? If they get lost, they need not to matter, but they still do, with no significant difference with the past.

The open source case

All of those examples are about teams working relatively close to each other and inside the same company where the rules are clear and the patterns are clear as well. In the case of open source, things are slightly different. A contributor to an open source project is not necessarily trusted, and this means that a contribution looks different and a review is necessary because we are working in an adversarial context by default. Even a trusted contributor doesn’t always have the same level of trust that an internal contributor in a company or a colleague could have. In that setting, a code review has a lot of purpose. Often also open source project get requests that weren’t discussed before on work that wasn’t discussed before and that requires deeper understanding to grasp how it fits the current scope and goals of the project. In that case a human code review is a must and not something that is to be replaced by bots.

How to speed up code reviews

In my experience things haven’t significantly changed with AI. The best way to speed up code reviews is to pair. You immediately gain a shared understanding of code between two or more team members on a team. You get immediate feedback from a human being about what you’re writing, a feedback that is most likely critical and to the point. If you really want to speed up software production and quality, it’s important to think that pairing is not to be considered removed with the introduction of AI tools.

Is an alternative ever possible?

Maybe? I won’t even talk about AGI or actually intelligent AI, which currently doesn’t exist and we have no solid proof that it will ever exist. Current systems are using a gradual optimization approach, in which the existing systems are improved to the point of giving illusion of intelligence, which may be indistinguishable from actual intelligence in some cases. Not being the real thing though, we can’t assume the outputs to be correct or generally consider bots/agent as “team mates”. Unless all of that changes, there won’t be a general intelligent approach.

Something else may change: if we end up rewriting the architecture of systems so that applications are smaller and smaller and their delivery to production is built in a way that is close to a biological system, with changes put in production and watched closely for metrics, in environments in which risks like security are severely mitigated, then we may reach the point in which reading the code won’t be necessary anymore. That would be an interesting experiment to build, but at the same time most companies and teams aren’t rebuilding their whole products to be in this position and the rightmost part of the stack to do that is missing as the productivity conversation is strictly focusing on code editing, which isn’t where bottlenecks really are.

Conclusions

Code reviews are still important and critical and not something I would ever recommend skipping. The tips for good code reviews are still the same and AI generated content is not changing what matters in that stage. As much as developers will shift from code builders to confidence builders, there won’t be a change in practices in the code review part of a software team practice.