AI生成代码激增下的代码审查：7种应对策略与实操案例

One question haunting the minds of CTOs and heads of engineering whom I’ve been talking with, is how to deal with large quantities of code review which have only been growing now that AI agents generate most code at many tech companies.

Since the end of 2025, it has seemed that the era of devs writing code by hand is over at startups and in Big Tech. AI agents work faster and generate more pull requests (PRs) than devs ever did, and the size of those pull requests is also increasing.

Today’s article summarizes some approaches to code review at various workplaces in this new paradigm, covering:

• Humans review the AI code reviews. The most popular approach: AI code review tools go through code changes, and devs review the review itself.
• Triage by “blast radius” & decide an approach. Low-risk changes don’t need human review, and high-risk ones do. Adopted by OpenAI, Anthropic, and others.
• Review the plan/tests/database schema, but not implementation. Focus on reviewing the “before” and “after” states of an implementation, rather than the implementation itself.
• Produce less code. Set up AI agents to produce smaller PRs that are easier to review and reason about.
• Review everything by hand. Not everyone has adopted AI code review tools – even those that have sometimes still expect devs to read through all the new code, before allowing it to go to prod.
• No human code review? There’s more talk about dropping human code reviews than there is evidence of this actually happening, so far. The most I could find was AI startups doing it and building additional layers for safer production rollouts.
• Why do we review code, anyway? Before figuring out whether or not code review should stay, it’s worth going back to the fundamental technical, team, and organizational reasons for code reviews.

Unsurprisingly, it’s clear there’s no one-size-fits-all solution to the question of how to handle a deluge of AI-generated code review. Please leave a comment below about how your team or company deals with this new, pressing issue!

A snapshot of what’s going on in code review at this stage of AI development is provided by the graphic from GitHub, below. The background context it provides is pretty stark. It shows the stats for the number of PRs and commits over the course of three years on the popular platform:

Change in number of PRs, commits, and new repos across three years. Source: GitHub

Over that time, the number of PRs opened has increased fivefold, which is a lot! And growth sped up from the end of 2025, when PRs and commits nearly doubled just in that period alone! So, how are teams dealing with this avalanche of extra work? To find out more, I asked around.

1. Humans review the AI code reviews

The most common approach is to add an AI code review step to every pull request in a variety of ways:

• Use one or more vendors to review PRs. There are dozens of vendors offering this functionality – ones like CodeRabbit, Gitar, Greptile, GitHub Copilot Code Review, Qodo, Claude Code Review, Ellipsis and more. Many teams choose one or more, and the bots then review PRs, leaving comments for devs. For example, the Bun project by Anthropic has CodeRabbit, GitHub Code Review, and Claude Code Review all generating comments on PRs.
• Multi-agent code review. Build a custom solution which triggers several models/agents to review the code and suggest fixes.
• Agents update PRs with fixes. Vendors and home-grown solutions can instruct agents to update PRs with fixes and then re-trigger reviews – if you trust agents to make sensible fixes, that is!

Typical processes:

AI code reviews increasingly part of the development cycle

In the above cases, engineers typically review the review itself, and not usually the code. Here’s Etienne Dilocker, cofounder and CTO at AI database software, Weaviate, explaining why he likes their approach:

“It’s very hard for agents to get the balance [of the code review] right. If you ignore human code review entirely and leave it to agents, every PR will either suffer from scope creep or ship critical issues. But, of course, you can’t review everything by hand. So my current favorite setup is:

1. an (adversarial) agent does a review

2. a human makes a scope decision

3. an agent implements the feedback

4. either repeat or break the loop (likely a human decision)

So basically, 90% is left to agents, with humans in the loop for critical scope decisions and exit criteria.”

Noise is a big problem with AI code reviews. WeTravel, a Series C travel tech company, decided to not use AI for code reviews because of the amount of noise it generated. In June, they did an updated evaluation which showed lots of improvement, but still not enough to justify adopting AI for the task.

As things stand, custom tooling is probably needed to reduce code-review noise. Uber built a clever approach for this; an agentic pipeline called uReview:

What uReview does:

• Bots generate lots of code review comments
• Comments are graded, and low-confidence comments removed
• Comments are merged, categorized, and unimportant ones removed
• … in the end, the AI review results in important comments being shown to devs

2. Triage by “blast radius” & choose an approach

Another common approach is to decide whether to review code by hand or with AI, based on how “risky” a change is:

• Low-risk change: only AI, without human review. It can ship to production once AI agents are happy
• High-risk change: mandatory human review

This is the approach that Anthropic and OpenAI follow, which I confirmed by talking with both companies. At Anthropic, Jarred Sumner told me that a human merges even low-risk changes, but that their goal is eventually to get another Claude instance to merge low-risk changes.

And it’s not just at leading AI labs: five-person startup, Duckbill Group, a cloud and AI cost management company, changed their process, as explained by cofounder and CEO Mike Julian:

“We ditched code review at Duckbill Group (mostly)

About a month ago, we found ourselves with 60 open PRs for a team of five. They had been accumulating for a few weeks and we all had the sudden realization we were looking at two days of just code review.

I had been tossing around the idea for a while about having AI do all code review and so I just asked the team: what if we just didn’t review the PRs?

We decided to do a couple of things:

• Switch to a risk-based system. With a risk-based system, we agreed that if your change touched the public API/MCP, auth, design system, non-additive database schema changes, or agent skills, it needed a human review. We then enforced that with a shell script to add a GitHub label.
• Improve our guardrails (unit and end-to-end testing, post-deploy observability, stricter linting and type checking, etc). Improving guardrails was pretty easy, just expensive in tokens and attention. We enabled nearly every rule in ruff/prettier/eslint/ty, and we improved our unit test coverage to a floor of 85%.

Results before vs after:

• PRs merged: 353 → 684 (80/wk → 154/wk, +94%)
• Merged within 1h: 28% → 45%; within 24h: 76% → 80%
• Human-reviewed PRs median merge time: 26h
• No human-review median merge time: 1h.”

Here’s how I’d visualize this approach:

Selecting a code review approach by “blast radius”

Some companies have built additional tooling to make it easier for devs to know which reviews to focus on. For example, Uber’s custom-built Code Review Inbox highlights high-impact changes, so devs know to spend more time and effort on them:

Evolving code review tooling to separate high-impact changes. Source: How Uber uses AI for development

3. Review the plan/tests/database schema, but not the implementation

Some devs and teams have stopped reviewing the code (the implementation), and instead review the “before” and “after” states: