How to review AI-generated code: a risk-tier checklist

To review AI-generated code without drowning in it, stop treating every pull request the same. Sort each change by risk, let machines do the first read (tests, types, an AI reviewer, a security scan), and spend human attention only where a missed bug is expensive: auth, money, data, CI and releases. Then cap how many rounds an agent and a reviewer can bounce a PR between them, because left alone they won't stop.

That's the short version. The rest is the data behind it and a checklist you can copy into a small team's repo this afternoon.

Why code review is now the bottleneck

Two things landed in October 2026 that say the same thing from opposite ends.

The first is a Harvard paper by Fiona Chen and James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production, built on Jellyfish analytics data: 445 million work events from 720,542 workers at 655 firms. The version I read (dated 28 October 2026, accessed 30 October) finds that after a firm adopts AI coding agents:

Their words: "Code review becomes the bottleneck." Code waits longer for a reviewer (+59.9% time in backlog) and spends longer in active review (+58.5%), which the authors read as both too little review capacity and lower quality code coming in. AI review tools don't fix it on their own: 79.1% of firms had used one by July 2026, but AI wrote only 23.3% of review comments.

If you saw Ars Technica's coverage on 9 October, its numbers (+30% lines of code, +23% pull requests, +49% review time) match an earlier version of the paper (first posted in January and revised since; the current one is dated 28 October). Same direction, different decimals. I've used the current version.

The second is the other end: a team that writes most of its code with agents and made review work anyway. On 15 October the Claude Code team published How the Claude Code team does code review (Addy Osmani, Morgan Westlee Lunt and Qing Wang). Claude writes about 90% of Claude Code's own code. From June to September, merged pull requests in that codebase more than doubled while the share that had to be reverted fell by more than 40%. They didn't do it by reading harder. They moved most of the reading to machines and made mistakes cheap to undo.

You are probably not Anthropic. But the parts that matter scale down to a team of two.

The idea: the change sets the risk tier, not the author

Anthropic's rule is that "the change sets the tier, not the author." A docs fix and an auto-updater change get different review, whoever (or whatever) wrote them. Their table:

They use a classifier to pick the tier. A small team doesn't need one: a CODEOWNERS file and a list of paths does 90% of the job.

A risk-tier checklist for small teams

Here is how I'd translate it for a team of one to five people shipping a typical web app (Next.js, Postgres, a payment provider, a few agents). Treat it as a starting point, then tighten or loosen it with evidence.

Tier 0: can auto-merge

• Docs, README, blog content, copy changes.
• Dependency patch bumps with a clean lockfile diff.
• New code behind a feature flag that's off in production.
• Tests that only add coverage (no edited assertions).

Gate: green CI (lint, types, tests, build), AI review with no open findings, a preview deploy that renders.

Tier 1: one human

• Ordinary product features and bug fixes.
• UI changes, new endpoints that reuse existing auth helpers.
• Refactors inside one module.

Gate: everything in Tier 0, plus one human approval. On an agent-written PR, the person who prompted the agent can be that human, which is exactly Anthropic's rule: they count as a required reviewer, "the same as if they'd typed the code themselves".

Tier 2: the owner, and a second pair of eyes if you have one

• Auth, sessions, permissions, row-level security policies.
• Payments, billing, anything that moves money.
• Database migrations and data deletion.
• CI workflows, deploy config, secrets handling.
• Agent instructions and system prompts that change what production agents do.

Gate: CODEOWNERS approval from whoever knows that area, plus a written rollback plan. If you're a team of one, this is the tier where you sleep on it and read the diff yourself the next morning. For Supabase apps, my pre-launch security checklist lists most of the paths that belong here.

What to read in every tier

The current top results for this keyword are long lists of AI failure modes. They're right, but you don't need 24 checks on a typo fix. These are the ones worth doing on every human-reviewed PR:

1. Scope. Does the diff match the task? Unrelated "cleanups" go in another PR.
2. Tests first. Read the test diff before the code. A deleted assertion, a new skip or a looser matcher is the agent making the test pass, not the code work.
3. Invented things. Every new import, function, config key and package must exist in the version you actually run.
4. Failure paths. What happens when the lookup returns nothing or the call times out? Look for fallbacks that let a request through.
5. Evidence. Ask for the command that ran and what it returned, or a screenshot. Anthropic asks its agents to "show the output instead of saying it's done".

Two rules that keep humans honest

• An agent's approval never counts as a person's. Automated review can clear a Tier 0 change. It can't fill a slot that calls for a human.
• Approvals belong to a commit. If an agent pushes after you approved, the approval is stale. On GitHub that's the "Dismiss stale pull request approvals when new commits are pushed" option in branch protection or rulesets. Turn it on.

Cap the loops between agents and reviewers

This one only shows up when both sides are machines. A human waves off a nitpick in two seconds; an agent fixes it, pushes, and triggers another review. Anthropic reports one CLI PR that went through more than fifty rounds of review and fixes overnight before its author stopped it. When they ran git blame on what the reviewer kept flagging, about 59% was code that had been there since the first pass: old bugs, found a few at a time.

Their fixes, which you can copy as-is:

• Hard cap at three rounds. After that, the reviewer asks the author to step back and rethink the approach.
• Diff-only re-review after the first passes.
• Flag the class of bug, so the author fixes every instance, not one line.
• No repeated findings.

If you run agents in CI, put the cap in the harness, not in a prompt. The same logic as budgets and turn limits in durable AI agents: a loop with no ceiling is a bill with no ceiling, and Claude Code cost per month is already hard enough to predict.

Write a REVIEW.md

CLAUDE.md (or AGENTS.md, see Claude Code vs Codex for using both) tells the agent what the project is. REVIEW.md tells the reviewer what matters. Anthropic's good ones are short and do five things: say what failure looks like in this repo, cap the nitpicks, list paths to skip, ask for a file and line as evidence, and ask for a summary that starts with a count and says plainly when there's nothing to fix.

A starting point:

# REVIEW.md

## What failure looks like here
- A user can read or change another user's data.
- A payment is charged twice or not recorded.
- A migration can't be rolled back.

## Rules
- Every finding needs a file and line. No guesses from names.
- Max 3 nits per review. Style is the linter's job.
- Skip: content/**, *.md, generated types, lockfiles.
- Start the summary with the number of real issues. If it's 0, say so.

When the reviewer keeps flagging the same thing, move it into REVIEW.md, a lint rule or a test. That's how the noise goes down instead of up.

Small-team setup on GitHub

• Branch protection or a ruleset on main: required checks, required review, stale approvals dismissed.
• CODEOWNERS for Tier 2 paths, including .github/workflows/.
• A PR template with three headings: Testing, Risk, How to revert.
• One AI reviewer on one repo first. Tune REVIEW.md for a few weeks, then widen. Code Review for Claude Code is generally available on Team and Enterprise plans, and /code-review and /security-review run locally.
• Previews, feature flags and one-click rollback, so a bad merge costs minutes. On Vercel, preview deployments and instant rollback are built in.

One caution from InfoQ's write-up: the open-source Claude security review GitHub Action says in its README that it "is not hardened against prompt injection attacks and should only be used to review trusted PRs". Don't point it at PRs from strangers.

What this doesn't solve

Anthropic is candid that it doesn't yet have circuit breakers that tighten approval when revert or incident numbers rise. Neither will you. Watch two numbers instead: how long PRs wait on a person, and how often you revert. If the first drops and the second climbs, you didn't save review time, you moved it to incident time.

And some PRs shouldn't land at all. Agents make starting things cheap, which also makes closing a PR cheap. "Should we build this?" is still a human question, and no reviewer, human or not, answers it by reading the diff. If you're designing the agents themselves, single agent vs multi-agent covers where the boundaries go.

I'm Joan Comadran, an AI engineer and full-stack developer in Barcelona (industrial engineering background). This guide is built from the Harvard paper and Anthropic's write-up, both checked on 30 October 2026, not from a review process I'm claiming to run at Anthropic's scale. If you want someone to set up the tiers, gates and rollback on a real product, that's what I do.

FAQ