Skip to content

BlogAI

Code review when nobody wrote the code

Review was never only about finding bugs

For years we said review exists to catch bugs. People really did open it for that. A bug visible in a single line was the cheapest part of the job. The more lasting effect was different: a second person on the team held a model of the change in their head. They knew which behavior the change protected and which it did not. When the author went on vacation, the review was proof that the decision did not live in one head.

With hand-written code these two things came together. The author made decisions while writing, and the diff was a record of them. The reviewer reconstructed those decisions by reading the code. They could disagree, praise the solution, or suggest another one.

AI has separated the two. A diff is no longer a trace of decisions. It is a plausible solution to a task that could be summarized in a prompt. The person opening a pull request is often the first reader, not the author of the choices.

A second model is not a second person

It is easy to take an AI model's comment for an independent pair of eyes. The model that writes the code and the model that comments on it draw from the same distribution: the same examples, the same omissions, the same way of deciding that something “looks correct”.

It is most visible when a model fixes code it generated itself. In a study where models repaired code from four different generators, including their own, the weakest results came on their own code. The reviewer then has the same blind spot as the author, because it is the same author.

There is a second cost, a quieter one. A model does not only miss things. It also points to where to look. An experiment presented at ICSE 2025 involved 29 professional developers and more than 50 hours of recorded reviews. Those who received a model-generated comment up front found its remarks accurate. They read mainly the places the model had flagged. They caught more low-severity defects. They did not catch more high-severity defects than reviewers of the same code without that hint. The review was not any shorter. The human stops searching and starts confirming someone else's search. And someone else's search ends where the model's idea of the task ends.

What review has to protect

We will not read every line. At the current pace, that sentence is a description of the situation, not a demand. The question is what stays with the human in review, since the rest really is better handed off.

Approve is taking responsibility, a signature. It means: I understand this change well enough that if it misbehaves tomorrow, I know where to look for the fix. The build can be green. The AI model's comment can be right about a function name. Responsibility still stays with the team.

Review was the place where that decision had to be made a second time, in different words, by someone who had not written it. An AI model that reads the same text and finds it consistent cannot replace that place. A team that hands a system over to a client has to know how that system works.

Read next

Prefer to see this in a shipped project rather than in theory? Have a look at our case studies

Back to blog

Let's talk