AI Code Review Playbook: Copying the Claude Code Team's Risk Tiers

On October 15, 2026, Anthropic published how the Claude Code team reviews its own code. Claude writes about 90% of that code, so humans can't read every line. The team's answer is a stack of automated checks plus human approval scaled to risk: low-risk changes need no human approval once checks pass, ordinary changes need one person, and the riskiest paths need two. The measure of success is spending as little human review time as possible without more reverts or incidents. Most of the process can be copied by any team using AI coding agents, with or without Anthropic's paid product.

This guide covers what the team actually does, what the commercial Code Review product costs, and the order in which to roll the setup out in your own repos.

What Anthropic reported, and how far to trust it

The claude.dev post by Addy Osmani, Morgan Westlee Lunt and Qing Wang starts from a scale problem. Anthropic's monorepo went from about 2,500 changes a day in May to more than 30,000 in September. The team says merged PRs to Claude Code more than doubled between June and September, while the share of PRs that were reverted fell by more than 40%.

Their review-convergence work produced these numbers:

At the product's general availability, Unite.AI reported more Anthropic figures. On PRs over 1,000 lines, 84% got findings, averaging 7.5 issues each. On PRs under 50 lines, 31% got findings. Engineers marked under 1% of findings as incorrect.

All of these numbers come from Anthropic about its own engineers, codebase and product. Nobody has audited them independently. The structure of the process is the useful part, because you can test it against your own revert rate.

The seven layers, in order

The team calls review continuous, "closer to spellcheck than a final gate." This is the pipeline as the post describes it:

1. Before the PR. The agent runs tests, builds, linters and screenshot comparisons, and shows the output instead of just saying it passed. A subagent with fresh context reviews the diff. Boris Cherny estimates that giving Claude a way to check its own work makes results two to three times better.
2. Required CI on every PR. Lint, type checks, tests on every platform, build and packaging. A red check blocks the merge. The PR template asks how the change was tested and how to undo it.
3. AI review on every PR. Several agents hunt for bugs in parallel. Separate verifier agents vote on each finding, and only findings with enough votes get posted. Style and cleanup findings are dropped. Comments are tagged Important, Nit or Pre-existing, and each one must be fixed or resolved with a reason.
4. Automated security review. A separate pass. Open findings from either review block the merge.
5. Risk-based human approval (details below).
6. Merge queue and gradual release. Checks rerun against main with the change applied. Features ship behind flags to employees first, and public builds go to a latest channel before stable.
7. Fast detection and rollback. Flags can be turned off without a deploy, a weekly on-call rotation watches for problems, and incident reviews ask which layer should have caught the issue.

The risk tiers

Four rules make the tiers hard to game:

• A classifier sets the tier from the change itself, not from who wrote it.
• Only trusted authors get the lighter paths.
• An agent's approval never counts as a human's.
• The person who prompted an agent-written change counts as a required reviewer. Approvals apply to one specific commit and must be renewed when new commits land.

The failure mode to plan for: review loops

The most useful warning in the post: one CLI PR went through more than 50 review rounds overnight before its author stopped it. When agents write code and agents review it, they can keep going forever. A git-blame analysis showed that about 59% of what the reviewer flagged was code from the PR's first version. Each round wasn't finding new problems the fixes had caused. It was digging up more old ones.

The team's controls:

• Cap rounds at three. After that, the reviewer asks the author to rethink the approach.
• Re-review only the new diff after the first few passes.
• Flag the whole class of a bug, not one instance at a time.
• Never re-post a finding that was already raised.
• Run nightly review agents over existing code, so old bugs don't surface one at a time in unrelated PRs.

If you connect an AI coding agent to an AI reviewer in CI, set up these limits before you turn on auto-fix. Without them, you'll burn tokens and get a PR history nobody can follow.

What Claude Code Review costs and how it's configured

You don't need Anthropic's product to use this process, but it's the reference implementation. The official docs cover these points:

• Plans: Team and Enterprise, for repos on GitHub (including GitHub Enterprise Server). It isn't available to organizations with Zero Data Retention, the HIPAA configuration or customer-managed encryption keys.
• Behavior: reviews run on Anthropic's infrastructure with read-only repo access. They don't build or run your code, and they never approve or block a PR. They post inline findings and a check run named "Claude Code Review" that never concludes as a failure.
• Review levels: Quick, Standard (the default) or Deep. Owners set one for the organization and can override it per repo.
• Triggers: once after a PR is created, after every push, or manually with @claude review. Drafts and PRs from forks are skipped automatically.

On cost, the costs page says there is no flat per-review price. Reviews are billed on token usage through usage credits, separately from plan usage. Cost grows with the review level, PR size, surrounding code complexity and the number of candidate issues to verify. During the preview, reviews "generally averaged $15–25," per Unite.AI. Unite.AI also reports that reviews now take 6–10 minutes, down from about 20, and that Enterprise organizations can claim $10,000–$50,000 in promotional credits until January 15, 2027.

Watch the default trigger. A repo added from the admin page starts at After every push, which multiplies cost by the number of pushes per PR. A rough example: 10 PRs a day × 22 working days × $20 is about $4,400 a month, before any extra pushes. Anthropic's recommended pilot:

1. Set a monthly spend limit for the Code Review service.
2. Turn it on for a few representative repos, set to Once after PR creation or Manual.
3. Read the Average cost column in Admin settings after several reviews.
4. Multiply by PRs per month, and again by pushes per PR if you plan to review every push.

When a budget runs out, reviews are skipped and a comment on the PR says why. Reviews don't fail silently. For the rest of your model spend, the LLM API Cost Calculator helps you model token budgets in the same way.

How to set this up in your own repo

This is the rollout order, adapted from the post's own recommendations. Steps 1–4 don't need a paid plan.

1. Give the agent checks it can run

List the test, lint and build commands in a short CLAUDE.md, and add hooks for formatters. Before opening a PR, run /code-review locally (available on any plan) or a review subagent with fresh context.

2. Lock down GitHub

These branch protection settings put the human-approval rules into practice:

Use CODEOWNERS for auth, billing, CI workflows, release pipelines and installers. Those are the paths the team always keeps under human review.

3. Add an automated security pass

Anthropic's open-source claude-code-security-review Action (MIT license) scans PR diffs and posts line-level findings. Two cautions from its README. First, it is not hardened against prompt injection, so only run it on trusted PRs and turn on GitHub's "Require approval for all external contributors." Second, check the claude-model input. The repo's listed default was an older Opus model when we checked, so set it explicitly.

4. Write a REVIEW.md, then tune it for a few weeks

The customization docs give a good template: define what "Important" means in your repo, cap nits ("at most five per review"), list paths to skip (generated code, lockfiles, anything CI already enforces), and require file:line evidence for claims about behavior. Three details are easy to miss:

• REVIEW.md is read from the base or default branch, never from the PR itself, so merge changes to it first.
• Lowering a finding's severity, excluding paths and capping nits are only honored if the default branch is protected.
• Local /code-review reads CLAUDE.md but not REVIEW.md. Put rules you want in both places in CLAUDE.md.

5. Define risk tiers, starting strict

Begin with every PR needing one human approval. Only move docs and flag-gated, additive changes to "no human approval" once your revert rate shows it's safe. The post's advice is to "start strict and loosen with evidence."

6. Turn incidents into an eval set

Collect past bad PRs and the reverts that fixed them, and run them against your reviewer every time you change its prompt, tools or model. Also run it on known-clean PRs to measure noise. Sort reviewer comments by how authors responded: fixed, wrong, intentional or didn't matter.

What stays human

The post is explicit that some decisions stay with people. Humans decide whether something should be built at all, review risky code (billing, the auto-updater, CI), and own architecture that others will copy. A named person is accountable for every shipped change. The reviewer's job also changes: you read the evidence (test output, screenshots, findings) rather than every line. As the authors put it, if you can't say what the checks would miss, ask for a real review.

The guardrail metric matters most. Anthropic tracks human approvals per PR, time spent waiting on people, and revert and incident rates together. If reverts go up while review time goes down, the work hasn't been saved. It has moved to on-call.

What to do now

• This week: turn on the branch protection settings above, add "Testing," "Risk" and "How to revert" sections to your PR template, and start running /code-review before opening PRs.
• Next month: pilot an AI reviewer on one repo with manual triggers and a spend cap, tune REVIEW.md, and track the share of findings authors mark as wrong.
• Watch for: independent measurements of AI reviewer precision outside Anthropic, pricing changes now that the product is generally available, and whether Anthropic adds the "circuit breakers" it says it hasn't built yet: automatic approval tightening when quality metrics get worse.

If you're comparing reviewers from other vendors, the AI coding assistants directory lists current options. Before trusting any of them, test them against your own revert history.