The reviewer has to know something the writer did not

Itamar Friedman of Qodo spent a talk this week on when a human can stop reviewing every diff, and he starts by asking why code review exists at all. He lands on two reasons. Checking that the code is safe, maintainable, and fits the architecture. And giving a senior engineer one last gate for alignment and teaching. Automate the first and you owe somebody a plan for the second.

His claim about models is the one worth arguing with. He says the model stopped being the barrier, and that he has watched code review benchmarks move very little across recent releases. What is missing is context. Without it, even a strong model asks whether you considered error handling, which he notes is sometimes critical and often noise. He wants the knowledge sitting in developers’ heads written down instead: the service graph, the contract between two microservices, the outage from three months ago and the discussion that resolved it.

The vault’s notes on adversarial review reach the same place from the research side, and they are blunter about the failure mode. Critic loops pay when the critic brings an independent search path, a real verifier, or a bounded rubric that can actually reject the work. They burn tokens when they are same model second thoughts, vague persona panels, or critique carrying no new information. Telling a model to think again, with nothing added, can make the answer worse than it was.

So the test for an automated reviewer is not how good the reviewer is. It is what the reviewer has that the writer did not.

Friedman’s own warning is the line I would keep. If you are already shipping generated code faster than your people can review it, you are not ahead of the problem. You are in it.