Agentic Coding: Who Will Review All That Code?

March 1, 2026

League (my day job) recently enabled mandatory GitHub Copilot code reviews on all pull requests. Not that long ago, I would not have supported this idea. Models, and the agent systems that use the models, have improved to the point of frequently finding non-trivial issues with code in a pull request.

We’d had Copilot and Codex reviews enabled for a while, but they were optional. Easy to ignore. For those who actually read the reviews, we watched the quality get better and better. Good enough to make mandatory and see how it works.

As we use coding agents to create more code, it follows that we’re going to need to find ways to review all that code. Before I get side-tracked into talking about agentic code reviews, we should probably figure out what parts of code reviews matter the most.

Code Reviews Don’t Catch Many Bugs

Here’s the thing most engineering leaders don’t want to accept: human code reviews are not very good at finding defects. We all think they are. We’d like them to be. The research has been telling us otherwise for over a decade.

[this is where I asked Claude to summarize some research for me]

The 2013 Microsoft Research study by Bacchelli and Bird — “Expectations, Outcomes, and Challenges of Modern Code Review” — analyzed hundreds of review comments, surveyed 873 programmers and 165 managers, and observed developers in the act of reviewing. They found that only 14% of review comments addressed defects. The most common category? Code improvements: readability, consistency, dead code removal. A follow-up study by Czerwonka, Greiler, and Tilford at Microsoft (2015), bluntly titled “Code Reviews Do Not Find Bugs,” corroborated those findings across 25,000 developers: roughly 15% of reviewer comments indicated a possible defect, while about half concerned long-term maintainability.

And yet, 44% of developers in Bacchelli and Bird’s survey ranked “finding defects” as their number one motivation for doing code reviews. There is a persistent gap between what we believe code reviews do and what they actually do.

Mäntylä and Lassenius found that 75% of defects discovered during code review were “evolvability” defects — issues affecting maintainability and comprehensibility — not functional bugs.

Most code reviews find no bugs at all. This doesn’t mean the bugs don’t exist, only that reviewers didn’t find them.

Someone should point out that finding 15% of the defects is better than nothing, and I’d agree. It would be tragic if something happened to cause that detection rate to drop.

What Are Code Reviews Good At?

Google’s engineering practices documentation (SWE Book) says: “Checking for code correctness is NOT the primary benefit Google accrues from the process of code review.” Instead, Google identifies the core benefits as code comprehension, consistency enforcement, knowledge sharing, psychological ownership, and validation, with correctness listed last.

A study of code review networks at Microsoft, Spotify, and Trivago found that an average participant can spread information to 72–85% of all code review participants within four weeks. Information travels between any two participants in fewer than five hops and fewer than five days. Code review isn’t just a quality gate. It’s the primary nervous system through which engineering organizations maintain shared understanding of their own systems.

The real value of code reviews:

Knowledge transfer: Someone other than the author learns how the system works. This is how organizations reduce bus factor, onboard new engineers, and maintain the ability to debug systems at 2am.
Architectural oversight: Code owners and senior engineers catch changes that work locally but don’t fit the broader system design — wrong abstractions, inconsistent patterns, unintended coupling.
Norm maintenance: Teams calibrate on naming conventions, error handling strategies, testing approaches, and what “good” looks like. This is social, not mechanical. Once a decision has been made, it can become mechanical.
Shared awareness: Reviews keep the team aware of what’s changing and why. This context is invisible until it’s missing.

None of these are things a linter catches. None of these are things you get from a passing test suite. Most critically, these are exactly the things that get lost when AI generates code that no human fully understands. Read what others are writing about the “cognitive debt” that happens with coding agents.

Agentic Coding Makes the Problem Worse

The Cortex 2026 Benchmark Report found PRs per author up 20% year-over-year, but incidents per pull request increased 23.5% and change failure rates rose roughly 30%. The DORA Report documented a 7.2% reduction in delivery stability with heavy AI reliance — even though 75% of developers felt more productive. AI-assisted PRs are 18% larger on average. Median PR size increased 33% in 2025.

So we’re producing more code, faster, in larger chunks, with more subtle defects — and asking humans to review it all. This won’t scale. Faros AI data across 10,000+ developers shows code review time has increased by roughly 91% as PR volume and size increased. An IT Pro/Qodo survey found that nearly half of developers don’t check AI-generated code at all, with 38% saying it takes longer to review than code from colleagues.

Using Agents to Review Agent-Written Code

This is why League enabled mandatory Copilot reviews. We’re using agents to cover some of the review capacity that human teams can no longer provide at the volume AI-generated code demands. And honestly, agents are pretty good at the mechanical layer of review. They catch the things that can be tedious for humans — improper framework usage, inconsistent error handling, basic security patterns. The models have gotten good enough at this to be worth mandating.

The emerging model is layered review:

Real-time IDE feedback — the agent catches issues as you write (or as another agent writes).
Automated PR review — Copilot, Codex, Claude, or similar tools handle the mechanical layer at submission time.
Human review for the hard parts — architecture, security threat modeling, business logic, and the “does this fit our system” judgment calls.

The key insight is that automated review should free up human attention for the things humans are uniquely good at, not replace human review entirely.

Focus More on Code Planning

Here’s a spicy take: we could probably do fewer code reviews if we got better at code planning.

With coding agents, we need to be very clear and explicit with upfront requirements. We’ve even started calling this “spec-driven development.” That extra time spent at the beginning of the process, along with guidance given to the agents through rules files, architecture documents, and the tests used to verify results. It could mean the need for code reviews decreases.

This isn’t a new idea, but agentic coding makes it more urgent. When a human writes code, they carry implicit context: they know the team’s conventions, the system’s quirks, the reasons behind past decisions. When an agent writes code, all of that context has to be explicit. It has to be written down. And the act of writing it down — of specifying what you want, how it should integrate, what patterns to follow, what to avoid — is itself a form of design review that happens before a single line of code is generated.

Addy Osmani’s “PR Contract” framework captures this well. Every PR should declare: what and why in a sentence or two, proof it works via tests or demo, a risk tier and which parts were AI-generated, and one or two specific areas requiring human review focus. The core principle: if you can’t explain why the code works, you shouldn’t be asking someone else to approve it.

The organizations adapting best are investing heavily in what happens upstream of the pull request:

Architecture decision records and design docs that agents and reviewers can reference
Project rules files (.cursor/rules, AGENTS.md, copilot-instructions.md) that encode team conventions so agents generate code that fits the system from the start
Spec-driven development where the specification is reviewed and approved before any code is generated
Test-first workflows where agents must execute and pass tests before submitting for review

When you invest in the inputs, you reduce the burden on the review. The review becomes a confirmation that the plan was followed, not a discovery process for whether the plan was any good.

Where This Is Heading

I’m not saying we should stop reviewing code today, but I do think we’ll stop reviewing as much code in a year.

The answer, I think, involves three shifts: let agents handle the mechanical review they’re now good enough at, invest heavily in what happens before code is written (specs, architecture, rules), and be intentional about preserving the knowledge-sharing function of review even if that means reviewing less code, more carefully, with a focus on system-level understanding rather than line-by-line correctness.

The risk is knowledge erosion and cognitive debt. If humans stop reading code because agents write it and other agents review it, the team loses the shared understanding that code review has always quietly maintained. The Opsera 2026 benchmark found that senior engineers realize nearly five times the productivity gains of junior engineers from AI tools — precisely because they already possess the system-level understanding needed to evaluate AI output. AI amplifies existing expertise. It doesn’t create it.

So the question isn’t really “who will review all that code?” The question is: how do we maintain the knowledge transfer, architectural oversight, and shared understanding that code reviews have always provided — when the volume of code outstrips our capacity to read it all?