I recently went to LeadDev’s LDX3 engineering conference in New York, and one question kept coming up: what happens to code review now that AI writes so much of our code? It’s been on a lot of people’s minds lately, including mine. It came up in many of the sessions I went to, even ones that weren’t specifically focused on code review.
One talk was titled “How to kill the code review.” Its speaker, Ankit Jain, argued that review as we know it is already breaking. Other speakers called review the new bottleneck, or told the room they’d never been good at reviewing everything in the first place. But many argued for keeping it, sometimes in the same talk. Critique of code review isn’t new, but AI is forcing a lot of us to rethink our original approaches to the practice.
Here are some of the main questions that came up, with ideas from each side arguing that we should kill or keep the code review.
What is code review even for?
Here are the arguments on each side.
Kill it
Part of the problem with code review is that we don’t all agree on its purpose. Jain cited a study where 44% of developers said review exists to find defects, yet when researchers looked at actual review comments, only a small share were about bugs. If review isn’t catching bugs, we’re spending a lot of time on “PR theater”. And the diff is a bad place to review anything. By the time code shows up in one, the important decisions were made somewhere else.
Keep it
Jain pointed out that review isn’t a good bug filter. Its real job is knowledge sharing and building a shared mental model of the system, and that’s harder to replace than bug-catching. He mentioned that review is often the only scheduled time developers talk about the system at all. Take it away, and those conversations don’t happen on their own.
Can humans possibly keep up?
What about the human factor?
Kill it
The numbers aren’t on the human side.
- A talk on building a software factory put it bluntly: you can’t review everything, you were never good at it, and you will always be the bottleneck. I’ve often heard a study cited which found that humans’ effectiveness drops quickly once the diff is beyond 200-400 lines of code.
- “Human in the loop” breaks down when the human faces too many decisions. Approvals turn into rubber stamps. That point came from a talk on governing autonomous AI.
- In a talk on visualizing the systems that drive your team, one team’s code output went up after adopting AI while their PR cycle time stayed flat. Once they charted it, review was clearly where everything got stuck.
Keep it
That same software factory talk also said code review that’s 90% good isn’t good enough, and that the limit on autonomy is how much of the result you can verify and trust. If you remove the reviewer, you haven’t removed the need for verification. Without a plan in place, now it’s just not b. A security-focused talk made a similar case: verification is now the bottleneck, and if auditing takes longer than writing, cutting corners on the audit becomes a security risk.
Can AI do the reviewing instead?
What about AI reviewers?
Kill it
Jain argued that an AI reviewer does have advantages. It reads every single line, and it applies the same standards each time. A talk on AI-native development recommended never trusting a single agent, so use several. Agents also tend to prefer output written by the same model, so it can be more effective to use a different model when reviewing output.
Keep it
Jain was just as clear about the downsides. An AI reviewer never saw the decisions behind the code. It won’t tell you that you shouldn’t have built the thing at all. And it isn’t accountable. He described what many teams are drifting toward: an agent writes the spec, a second agent writes the code, another agent reviews it, and a human skims it all.
There’s a testing version of this problem too. A talk on continuous integration at scale warned that AI-generated tests can reward-hack, passing without really covering the behavior you meant. If the tests and the review both come from AI, nobody has actually verified anything.
What happens to junior developers?
What about junior devs?
Kill it
Junior developers don’t learn much from rubber-stamping a giant PR, or from getting an “LGTM” on their own PR. A panel debate on whether we’re teaching junior engineers to think or just to prompt suggested pairing juniors on planning and architecture instead of PRs, and talking through how and why you’d build something before any code exists. One panelist took it a step further and argued we should shift both the review and the pairing left, to the spec. If the spec has been fully reviewed and it’s good, the code doesn’t need nearly as much review.
A talk on the junior developer crisis added a practical angle. Since AI generates more code than anyone can read line by line, teach juniors where to look. The speaker uses a code smells quiz generated from real code, where juniors have to name the smell or say there isn’t one.
Keep it
The software factory talk warned that automating away review is a trap, especially for juniors. We should automate what’s known, not the bigger picture thinking. Review is where that thinking can happen, and juniors are the ones who most need to see it. One of the junior engineer debate panelists also advocated for using pair programming time to review outputs to help them build the skills it takes to validate what’s being built.
A compromise: not all code needs the same review
Most people at the conference weren’t arguing for all or nothing. The most practical ideas treated review as something you adjust depending on the code in front of you. The security talk offered a useful test: “is ‘mostly right’ OK here?” For UI views or unit test templates, it might be. For auth, cryptography, payment flows, or cross-tenant data, it isn’t.
I still don’t think there’s a definitive answer that will work for every project. I do think it’s an important area to norm with our teams, be honest with ourselves, and take an inventory of what is and isn’t working. Review theater isn’t getting us anywhere, but we need to make sure we’re not removing it without prioritizing new processes that allow us to maintain the quality of our code as well as our shared understanding as a team.
How is your team handling code review? I’d love to hear about your experiments and strategies.
Talks mentioned
- How to kill the code review, Ankit Jain
- You’re already building a software factory, Chris Kelly
- Learning to see: Visualising the systems that drive your team, Francisco Trindade
- The accountability gap: Engineering governance for autonomous AI, Sandeep Bharadwaj Mannapur
- A practical framework for working with AI in modern engineering, Madona Wambua
- AI-native development: How to actually get the most out of your agents, Ameya Kanitkar
- The continuous thunderdome, Jez Humble
- Debate: Are we teaching junior engineers to think or just to prompt? Rachel Laycock, Mattan Bitner, Nivia Henry and Randy Shoup
- Tackling the junior developer crisis in the age of AI, Giordano Scalzo