How to Review AI-Generated Code: The Claude Code Team's Process

How do you review code when AI writes most of it? Anthropic’s Claude Code team has a practical answer: stop expecting people to read every line. Hand most of the checking to machines and AI, decide how many humans must approve based on how risky the change is, and back everything up with a merge queue, feature flags and fast rollback. Human attention goes to the few things machines can’t do: deciding what to build, reviewing risky code, guarding the architecture, reading the evidence and owning the outcome.

This post walks through that process in the order a change actually travels, from a laptop to users. It’s based on Anthropic’s October 2026 post How the Claude Code team does code review. The interpretation and opinions are mine.

Why AI-generated code is so hard to review

AI coding is everywhere now, but nobody agrees on how to review what it produces.

Read every line? You can’t keep up. An agent can write thousands of lines in minutes. In Anthropic’s monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September. Line-by-line human review at that volume is fantasy.

Skip review entirely? Then you have no idea whether the code does what you had in mind.

Review only the important parts? Sounds reasonable, until you ask who decides what’s important. Plenty of incidents start in code that looked harmless.

The Claude Code team faces an extreme version of this problem: Claude writes about 90% of Claude Code’s own code. So how do they keep quality up?

The headline result first. From June to September, merged pull requests in the Claude Code codebase more than doubled, while the share that had to be reverted fell by more than 40%. More code shipped, and a smaller share of it broke.

One thing to know before we start: the original post is titled “code review,” but it covers far more than review. Review is tied to the whole release pipeline, so this walkthrough follows the pipeline too.

Quick refresher: how a change normally ships

After you write code, it has to be merged into the main branch (main or master). Before that, you usually open a pull request (PR), which is basically a request to merge your change into main.

A PR typically goes through two kinds of checks:

• Automated checks: run the tests and the build to catch obvious problems.
• Human review: another developer reads the change and blocks anything risky.

Once the checks pass, the PR merges. Merging still doesn’t put the feature in users’ hands; there’s a release step after that.

So the whole path splits into four stages: before the PR, during the PR, at merge, and after merge. The Claude Code team keeps the same four stages. What changed is what happens inside each one, so the process can cope with AI writing most of the code.

Before the PR: make the agent prove it works, then bring in a fresh reviewer

According to the original post, most review now happens before a PR even exists. It comes in two steps.

Step 1: Let the agent verify that the product actually runs

Give the agent things it can run: tests, a build, a browser, a screenshot to compare against the design. Then ask it to show the output. “I’m done” doesn’t count.

Boris Cherny, who created Claude Code, has called giving Claude a way to verify its own work probably the most important thing for getting good results. He estimates it makes the final result two to three times better.

Step 2: Use a brand-new agent to check code quality

Here’s the trap. It’s tempting to think: the agent that wrote the code already has the requirements, its reasoning and the whole conversation in context, so it should be the best one to check its own work.

In practice it misses a lot. It remembers how it was thinking, so when it reviews, it follows the same line of reasoning and easily convinces itself the code is correct.

Anthropic’s fix is to spin up a subagent with a fresh context. It only gets the goal and the diff, and it has to judge whether the change achieves the goal and what could go wrong. It knows nothing about how the code was written. That sounds like a weakness, yet it’s exactly what keeps the review objective.

When the automated reviewer keeps flagging the same kind of issue, the team fixes it at the source: in a skill, with a lint rule, or in two instruction files:

• CLAUDE.md tells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so it has to stay short.
• REVIEW.md is written by code owners and tells the reviewer what matters in their part of the code. The good ones are short. They describe what failure looks like in that area, cap the nits, list paths to skip, and ask for a file and line number as evidence for every finding.

During the PR: four checks, and only one needs a human

Once a PR is open, it has to clear four gates: automated checks (CI), AI review, security review and risk-based approval. The first three are machines. Only the last one involves a person.

Automated checks (CI): anything that can run on its own goes here

CI is the suite that runs on every push: lint, type checks, tests on every platform, a build. A typical CLI pull request may run dozens of checks before anyone looks at it.

The PR template also asks two questions: how was this tested, and how do we undo it? Claude can fill that in, but the person who asked for the change signs off on it.

AI review: find issues, filter the noise, answer every finding

Every PR gets a Claude review before a human looks at it. It helps to think of it in three steps.

1. Find issues. The reviewer reads the diff against the whole repo and the PR’s stated intent, and asks three questions: Does the change solve its problem? Does it fit the system? Does it break something else? On a bug fix, it also looks for the root cause.

2. Filter issues. Several agents hunt for bugs in parallel. A separate group then votes on each finding, and it only gets posted if enough of them agree it’s real. Findings that are only about style, diagnostics or cleanup get dropped. The team A/B tested these filters on its own PRs before keeping them.

3. Handle issues. What’s left shows up sorted by severity and tagged as Important, Nit or Pre-existing. Pre-existing means the bug was already there before this PR, so it doesn’t look like the author’s fault. Every finding has to be answered: fix it, or close it with a reason. While any finding is still open, the PR can’t merge. Often an agent picks up the fix overnight, and the author comes back to a PR that has already been through another round.

When the team launched this reviewer as a research preview, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings, and most small ones come back clean.

Security review: a separate pass that can block the merge

Security gets its own automated review. Like the AI review, a PR can’t merge while any of its findings is still open. If a later commit fixes the issue, the finding clears on its own. To try it yourself, look at the open-source security review GitHub Action or the /security-review command.

Risk-based approval: a typo fix and a billing change get different treatment

Fixing a typo in the docs and changing billing or the auto-updater carry very different risk. So the team sorts changes into three tiers:

The rules around this table are, in my view, even more worth copying than the table itself:

• The change sets the tier, whoever the author is. One classifier reads the change and picks the tier. A second classifier asks whether this particular change needs another person even when its tier says it doesn’t. Paths that owners mark as sensitive, and every CI workflow file, always need a human.
• Only trusted authors get the lighter paths, mostly the team that owns the repo. Everyone else needs a second person to approve.
• An agent’s approval never counts as a person’s. Automated review can clear a low-risk change, but it can’t fill a slot that calls for a human.
• Whoever prompted the change is on the hook for it. The person directing the agent counts as one of the required reviewers, as if they’d typed the code themselves.
• An approval covers one specific commit. If new commits land that the system can’t vouch for, such as an agent’s push or a merge conflict someone resolved by hand, the PR has to be approved again.

How the AI reviewer keeps getting better

Building the pipeline is only half the job. The reviewer itself needs constant tuning, and the team focuses on three goals: catch real bugs, cut useless comments, and make sure review actually finishes.

Turn real incidents into an eval

The team collected past PRs that caused incidents, along with their fixes and reverts, and had engineers who know that code confirm each bug and where it lived. Each case becomes a test question. Together they form an eval set, and every new incident adds another question.

Scoring is simple. Run the reviewer on each PR in the set: if it finds the real bug, that’s a point; if it misses, zero. Every time someone changes the prompts, tools or model, the reviewer is rescored against the same set, and the change stays only if the score goes up. The eval runs every day.

Measure the noise

Catching real bugs isn’t enough on its own. A reviewer that flags everything scores well on recall while burying developers in comments they have to read one by one.

The team measures noise in two ways:

1. Watch how authors respond to each comment. Every comment is sorted into four buckets: the author fixed it, said it was wrong, said the behavior was intentional, or decided it didn’t matter. Only the first bucket counts as useful.
2. Run the reviewer on PRs known to be clean, and count how often it reports something that would have led someone to make a harmful change.

Their written priority: catch real bugs first, cut review rounds second.

Noise costs more when the author is an agent. A person can wave off a nit in seconds. An agent dutifully fixes it, which means another commit and another round of review.

Make review converge

How can review fail to finish? The AI reviewer leaves comments, the coding agent fixes them and pushes, the next round brings new comments, and so on. In one case, a CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it.

When the team ran git blame on what the reviewer kept flagging, about 59% of it was code that had been there since the reviewer’s first pass. The reviewer was rarely finding new bugs. It was finding a few more old ones each round.

So they changed how re-review works:

1. Cap the rounds. After three rounds, the reviewer asks the author to step back and reconsider the overall approach instead of patching line by line.
2. After the first few passes, review only the new diff. Early rounds look at the change together with everything it touches. If you modify a function, the reviewer checks every place in the project that calls it. That’s thorough, but if every round re-reads the whole picture, it will always dig up something that was already there, and review never ends. So after a few rounds, the scope narrows to the lines that just changed. By then the change and its blast radius have been read several times, so the narrower scope rarely misses anything serious.
3. Flag the whole class of bug. If the same mistake appears in several places, the reviewer points out all of them at once, so the author fixes every instance in one go instead of getting caught on the next one in the following round.
4. No repeats. A finding that has already been posted doesn’t get posted again.

The effect was clear. According to the chart in the original post:

Review agents also run nightly over existing code, so old bugs get caught before they show up somewhere else.

At merge: a merge queue protects main

Even after all those checks, a PR doesn’t go straight into main. It joins a merge queue first.

When a PR reaches the front, the system applies it on top of the latest main and re-runs every check. Only if they pass does it actually merge. The next PR goes through the same thing, except now the main it’s tested against already includes the previous PR.

This guards against a specific failure: two PRs that pass on their own but break main once they’re combined. The queue catches that PR, sends it back to the author, and keeps main working at all times.

After merge: feature flags, staged releases and fast rollback

Once code is in main, it still has to reach users safely. Three things handle that.

Feature flags. New behavior usually ships behind a flag that’s turned on for Anthropic employees first. They use Claude Code heavily every day, so they often hit regressions before regular users do.

Staged release channels. Claude Code has two channels: latest and stable. New versions go to latest first, for people who like to be early. The stable channel trails behind.

Monitoring and rollback. Some mistakes will still slip through, so the last layer is about noticing fast and undoing fast. Flags can be turned off without a deploy, which is the quickest fix. When a flag can’t solve it, the team reverts or ships a fixed build. Claude Code also has a weekly on-call rotation, and incident reviews ask which layer should have caught the problem.

The post is candid about what’s still missing. Spotting a bad merge still depends on the author, on-call, and the revert and incident dashboards. There are no circuit breakers yet that automatically tighten approvals when those numbers move, and engineers want them before more code moves to zero-human merges.

One colleague put it in a way I agree with: slowing down does lower your error rate, but mostly because you’re doing less of everything. The team would rather get faster at noticing and fixing problems.

How many gates does a bug have to get through?

Put the four stages side by side:

• Before the PR: the agent runs tests and proves the product works, then a fresh agent checks code quality.
• During the PR: CI runs dozens of checks; AI review catches what CI misses; security review catches what AI review misses; and if the code is important, a human has to approve it.
• At merge: everything is re-tested on the latest main, which catches bugs that only appear when your change meets someone else’s.
• After merge: heavy internal users see it first, then the latest channel, then stable. Even if a bug reaches users, the flag can be switched off or the change rolled back right away.

Any single layer can miss a problem. Stacked together, they make it very hard for a bug to slip all the way through. And apart from approvals on important code, almost every gate is run by machines and AI.

To me, the whole design serves one goal: keep quality high while using as little human time as possible. In the post’s own words, the aim is for most PRs to merge with at most one human in the loop (who can be the author), with no increase in reverts or incidents. Revert and incident rates are the guardrail. If they climb, you haven’t saved human time; you’ve just moved it into firefighting.

Where human time should go

If human time and attention are the scarcest resource, where should they be spent? The post lists five jobs that stay with people:

1. Deciding whether to build it. Direction, taste and scope are calls machines can’t make. One team that declared its review bottleneck solved still kept human review for changes coming from outside the team, so someone would ask, “Should we even do this?”
2. Reviewing risky code such as billing, the auto-updater and CI workflows. When these break, the damage is big, so a person needs to look.
3. Reviewing architecture that sets a pattern others will copy. Once a pattern is in place, people and agents building similar features will follow it. If the pattern is wrong, the mistake gets copied again and again.
4. Reading the evidence. Reviewers used to read every line. Now they mostly read evidence: test output, the command that ran and what it returned, screenshots, the reviewer’s findings. The post offers a useful rule here: if you can’t say what the checks would miss, ask for a real review instead of a quick approval.
5. Owning the outcome. Whoever typed the code, a person is accountable for every change that ships. An AI can’t take the blame.

How to start using this on your own team

The post ends with an adoption checklist, and most of the pieces exist today. If your team writes a lot of code with AI, pick from this list:

• Give your agent checks it can run, listed in a short CLAUDE.md, plus hooks that run formatters and linters.
• Add “Testing,” “Risk” and “How to revert” sections to your PR template.
• Add an AI reviewer to one repo first (Code Review for Claude Code or the Claude Code GitHub Action), iterate on REVIEW.md for a few weeks, then roll it out to more repos.
• Add an automated security review.
• Require every review thread to be resolved before merging.
• Cap review rounds, and after the first few, re-review only the new diff.
• Turn incidents and reverts into an eval set, and rescore the reviewer whenever its prompts, tools or model change.
• Use a merge queue, feature flags, internal use first, staged releases and one-step rollback.

If your team is small and the volume is still manageable by hand, you don’t need all of this at once. I’d start with the PR template and the rule that every review thread must be resolved before merging. They cost almost nothing and pay off right away.

Final thoughts

A year ago, people were still arguing about whether AI-written code could be trusted at all. Plenty of developers thought it was mostly garbage and real code still had to come from humans. You hear that far less now, because AI coding keeps getting better. Developers who refuse to use it will struggle to keep pace with those who do.

Writing code got easier. The hard problem moved: how do you review what AI writes, and how do you make sure the product still meets the bar? Anthropic’s post gives a grounded answer, and with merged PRs more than doubling while the revert share dropped by over 40%, the results back it up.

The post covers a lot of detail, but the core idea, as I see it, is a new division of labor between people and AI. AI does the bulk of the execution: writing code, running checks, finding problems. People make the decisions that matter most: whether to build something, which architecture to use, and who answers for it when things go wrong.

It reminds me of a line from OpenAI’s writing on harness engineering: “Humans steer. Agents execute.” Anthropic and OpenAI have ended up heading in the same direction.

So back to the opening question: how do you review AI-generated code? Dig one level deeper and the real question is how to spend limited human attention where it matters most.

Anthropic’s process probably isn’t the final answer. Models will keep getting stronger, and the process will keep changing. The direction, though, seems unlikely to change: hand AI everything it can handle, and let people spend their time on the decisions that matter most. That may be where software development as a whole is heading.