How Claude Code Review Works: Inside Anthropic’s AI-Powered Code Review System

Imagine opening a pull request after spending hours building a feature with an AI coding assistant. The code compiles, the tests pass, and the implementation looks reasonable. You ask another developer to review it, and they find a subtle bug in a caching path that your tests never exercised.

Now imagine your team generates dozens or hundreds of similar changes every day. Asking humans to inspect every line becomes increasingly difficult, even when everyone is experienced.

This is the problem Anthropic is tackling with its approach to code review on the Claude Code team.

In its engineering article, How the Claude Code team does code review, Anthropic describes a review process in which AI agents handle much of the routine inspection, automated checks catch predictable failures, and human reviewers concentrate on architectural decisions and changes that carry greater risk.

The interesting part is how the system is designed. Multiple agents inspect changes, other agents verify their findings, security checks run independently, and the team measures whether its reviewers catch real bugs without flooding developers with false alarms.

For developers using Claude Code, GitHub, or other AI coding tools, this approach offers practical lessons for building a review process that scales with AI-generated code.

Traditional code review assumes that producing code is relatively expensive. A developer implements a feature, opens a pull request, and waits for another engineer to inspect the diff.

AI coding agents change that equation. They can generate implementations, modify multiple files, write tests, and create pull requests at a pace that puts pressure on the review process.

Anthropic describes the resulting challenge in terms of two responsibilities:

These responsibilities overlap, but they are different. An engineer reviewing a small documentation change might learn very little about the system, while a review of a new authentication flow could reveal important architectural decisions.

Anthropic’s approach is to automate more of the defect detection while preserving human attention for decisions that require engineering judgment.

The team also measures success against an important constraint: reducing human review effort must not increase reverts or production incidents. Otherwise, the team has simply moved the cost of finding bugs from code review to incident response.

Anthropic’s process uses multiple layers of checks. Each layer looks for a different kind of failure, and the amount of human involvement depends on the risk of the change.

This diagram summarizes the team’s broader internal workflow. The publicly available Claude Code Review product does not automatically perform every step in this diagram.

Anthropic encourages developers to give Claude a way to verify its own work.

For example, when Claude implements a React component, it might run the test suite, start the application, or capture a screenshot to compare against the intended design.

The engineer can then ask a separate agent to review the diff with fresh context. The reviewer is less likely to inherit the implementation agent’s assumptions when it starts with a distinct review task.

Anthropic also uses project-specific instructions:

A good REVIEW.md describes observable failure conditions. For example, a caching module's instructions might identify stale data or incorrect cache invalidation as issues worth investigating.

The team also moves recurring feedback into the appropriate place. If an agent repeatedly misses a rule, the answer may be to improve its instructions or add a deterministic lint rule rather than keep leaving the same review comment.

The hosted Code Review product examines a pull request’s diff in the context of the surrounding repository.

That context matters because many bugs cannot be identified by reading an isolated line. A changed function might violate an assumption made by its callers, break a state transition, or mishandle an edge case elsewhere in the application.

Multiple specialized agents examine changes in parallel, looking for different classes of defects. The review focuses on questions such as:

The reviewer also considers the pull request’s stated intent. A patch can be syntactically correct and still fail to solve the problem it claims to address.

According to Anthropic’s Code Review documentation, the hosted review process is designed to identify correctness issues rather than act as another formatting or linting tool.

An AI reviewer can produce plausible explanations for bugs that do not exist. At scale, those false positives waste developer time and can lead to unnecessary code changes.

Anthropic addresses this with a verification stage.

In the team’s internal workflow, several agents investigate potential bugs, and another group evaluates the findings. A finding is posted only when sufficient agreement supports it. The system removes duplicate findings and filters out comments that amount to stylistic preferences or routine cleanup.

The remaining findings are ranked by severity and attached to specific lines in the pull request.

This distinction is important: generating a list of possible problems is relatively easy for a language model. Establishing that a particular change genuinely causes a defect is much harder.

Verification reduces noise, although it cannot guarantee that every finding is correct or every bug will be detected.

Security problems deserve separate attention because a change can pass functional tests while introducing a serious vulnerability.

Anthropic describes a dedicated security review that looks for security-related issues. Its internal workflow requires outstanding bug-review and security-review findings to be resolved before merging.

The hosted Code Review product and the team’s internal process have different enforcement behavior. The public product posts findings and does not itself approve or block a pull request. Teams can enforce additional requirements through their own CI and repository protections.

For developers, the practical lesson is straightforward: keep security checks separate from general code quality checks, and decide explicitly which findings must block a merge.

AI review does not replace the usual automated checks.

Anthropic runs linting, type checks, tests across supported platforms, and builds. Larger changes may require many separate checks.

These tools catch different problems:

These checks overlap, but that is useful. A test suite can reliably verify a known behavior, while an AI reviewer may notice a missing edge case that the tests never cover.

Neither is a substitute for the other.

One of the more interesting decisions in Anthropic’s internal workflow is that every change does not need the same number of human reviewers.

The team describes three broad levels:

A change classifier determines the risk tier, and additional rules can require human approval regardless of the initial classification. Certain sensitive paths always need a person.

The author remains accountable even when an AI agent wrote the code. A bot’s approval cannot substitute for a required human approval.

This is a useful model for teams adopting AI coding agents: set review requirements according to the potential impact of a failure, and retain stricter controls around sensitive systems.

Passing CI does not guarantee that a change will work when combined with other changes.

Anthropic’s merge queue reruns checks against the current main branch with the proposed change applied. This helps catch integration failures that individual pull requests might not reveal.

The team also uses feature flags and staged releases. New behavior can reach internal users first, allowing regressions to surface before a wider rollout. If something goes wrong, a flag or revert can help restore the previous behavior quickly.

These safeguards acknowledge an unavoidable fact about software engineering: even a sophisticated review system will miss some defects.

Developers should distinguish the hosted GitHub product from the review command available in Claude Code.

Runs reviews through the Claude GitHub integration. Organizations can configure reviews when a PR opens, after every push, or manually. Findings appear as inline comments.

Runs a lighter review workflow from Claude Code before or during the PR process. It is useful for catching problems before asking teammates to review the change.

For the hosted product, Anthropic’s documentation lists Team and Enterprise availability, with usage billed separately through usage credits. It also notes that Code Review is in research preview and is unavailable to organizations using zero data retention. Check the official setup guide for current eligibility and configuration details.

An automated reviewer that reports hundreds of issues is not necessarily better than one that reports ten useful ones.

Anthropic evaluates its reviewer using historical pull requests that caused incidents or required reverts. Engineers familiar with the affected code confirm the bugs and use them to build a recurring evaluation set.

The team also tracks how developers respond to findings. Did they fix the issue? Reject the finding as incorrect? Decide the behavior was intentional? Or consider the issue too minor to matter?

Those responses help reveal where the reviewer produces noise.

Another concern is review convergence. If an AI author and an AI reviewer repeatedly make changes and request more fixes, they can consume many rounds without meaningfully improving the code.

Anthropic describes a case in which a pull request went through more than 50 rounds of review and fixes overnight. The team responded by limiting review rounds, focusing subsequent reviews on changed lines, and avoiding repeated findings.

This is a particularly useful lesson for agentic development: a review process needs a stopping condition, not just the ability to find one more possible improvement.

You do not need Anthropic’s entire internal infrastructure to apply its principles.

Start with a few practical changes:

For more details, consult Anthropic’s code review workflow and hosted setup guide.

Claude Code review offers a useful example of how software teams can adapt when AI agents produce code faster than humans can inspect it.

The approach combines automated review, independent verification, deterministic CI checks, security controls, risk-based approvals, and fast rollback. Each layer handles a different class of failure, while humans retain responsibility for decisions that need engineering judgment.

The part worth borrowing is the feedback loop. When a reviewer misses a bug, improve the instructions, checks, or evaluation data. When it produces too much noise, measure which findings developers reject. When reviews never converge, limit the number of rounds.

As AI-generated code becomes more common, teams will need to judge their review process by the defects it catches and the effort it saves, while keeping production reliability intact.

That is a much more useful standard than simply asking whether someone has read every line.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.