01 Sep 2026
This week I have been thinking about code reviews. Or rather, about who will read all this code.
AI has largely solved the writing part. So we write more. A recent Meta study found lines of code per change up 105.9% in a year, with AI agents behind most of the growth. Pull requests are bigger and more complex. Human eyeballs, meanwhile, have not multiplied. Twice the code, same attention.
The obvious fix is to have the AI review the AI. Meta already does, with a system called RADAR. It automatically approves low-risk changes and flags the rest for a human. I like the approach; it does not try to do everything with AI. It spends scarce human attention where it counts.
But it raises a deeper question. Is a code review only a bug hunt? A classic study at Microsoft says no. Finding defects is the headline reason. Underneath sit knowledge transfer, team awareness, and shared ownership of the code. Reviews are how a team learns its own codebase.
So what is the answer? Two things, I think.
First, keep pull requests manageable. A sprawling, AI-generated change nobody can follow is not progress. Then use AI where it helps: writing tests, catching security issues, flagging high-risk changes, and grinding through repetitive, high-volume checks. That is where developers want AI anyway.
Second, protect what matters. Even if AI could review alone, would we still understand our own codebase? Would the team know about the hidden technical debt, or would it be a lovely surprise later?
Therefore, at 42 Questions we fold AI into the existing review process rather than replacing it. AI handles the security and compliance analysis, visualises a change's impact on the codebase and data structures, and highlights the risky areas. Then a human makes an informed decision.
The AI reads everything. The human still decides. And when the surprise comes, at least someone saw it coming.
Author: Petr Klus
