Claude Code review, explained: how Anthropic's Claude Code team reviews AI-written code, and the /code-review, ultrareview and Code Review tools you can use

On October 15, 2026, Anthropic published "How the Claude Code team does code review," a post on its claude.dev blog explaining how the team behind Claude Code reviews pull requests when, by its own account, Claude writes about 90% of the code. The short answer: machines do most of the reading, humans approve according to risk, and the team invests in making mistakes cheap to undo. By October 18, the Hacker News thread, posted October 16, had drawn 460 points and more than 460 comments, many of them skeptical. This explainer covers what Anthropic describes, what commenters pushed back on, and how Claude Code review works if you want it for your own repositories.

This story is based on Anthropic's post, the Claude Code documentation for /code-review, ultrareview and the Code Review service, Anthropic's Code Review general-availability announcement and support article on security reviews, and the Hacker News discussion, checked October 18, 2026.

The short version

• Anthropic's goal: "the minimum amount of human review time that doesn't raise reverts or incidents." Revert and incident rates are the guardrail.
• Every pull request gets parallel AI bug hunters, a voting step that keeps only findings with enough agreement, a separate automated security review and required CI.
• Humans approve by risk tier: none for low-risk changes once checks are green, one person for medium, two for high. "An agent's approval never counts as a person's."
• Anthropic-reported results: merged pull requests more than doubled from June to September while the share needing a revert fell by more than 40%.
• What you can use: /code-review (any plan, runs locally), /code-review ultra (cloud, paid after three free runs) and the Code Review service for GitHub (Team and Enterprise).

How does the Claude Code team do code review?

The post is by Addy Osmani, Morgan Westlee Lunt and Qing Wang. Its argument is that "did a human read the code?" is an "imprecise proxy" for the real question: what could go wrong with a change, and which check, automated or human, should catch it. In the post's words, "We didn't remove review. But we did move most of the reading to machines."

Before a pull request is opened, Claude runs the tests, build and linter and shows the output. A subagent reviews the diff in a fresh context. The team uses internal skills that hunt bugs, simplify the diff and check behavior end to end. When the reviewer keeps flagging the same kind of problem, the team fixes it at the source: in a skill, a lint rule or an instruction file.

On every pull request:

1. AI review. Claude reviews the diff against the whole repository and the pull request's stated intent. For bug fixes, it looks for the root cause.
2. Verification voting. Several agents hunt for bugs in parallel. A separate group votes on each finding, and only findings with enough agreement are posted. Style, diagnostic and cleanup-only findings are dropped. The post says these filters were A/B tested on internal pull requests.
3. Severity tags. Findings are labeled Important, Nit or Pre-existing, so an old bug isn't pinned on the author.
4. Every finding needs an answer: a fix, or a resolved thread with a reason.
5. Security review. A separate automated pass can block the merge.
6. Required CI covers lint, types, tests across platforms, build and packaging.
7. Risk-based human approval (see the table below).
8. A merge queue re-runs checks against the latest main branch.
9. Gradual release. Features go to Anthropic employees first, then to a latest channel before stable. Flags can be turned off without a deploy, and broken builds get reverted.

"The change sets the tier, not the author": a classifier reads the change and picks its risk tier, and a second classifier can require a person anyway. Some paths, including any CI workflow file, always need a human. The person who prompted an agent-written change counts as a required reviewer. An approval covers one specific commit, so new commits need fresh approval.

Humans keep the decisions the post says machines shouldn't make: whether to build something at all, risky code such as billing and the auto-updater, architecture that sets patterns, reading the evidence, and owning the outcome. "Whoever prompted the change is on the hook for it."

What numbers does Anthropic report?

All of these come from Anthropic's post. They haven't been independently checked, and the post doesn't publish the underlying data.

Two caveats matter. The monorepo figure covers all of Anthropic, not Claude Code, which lives in a separate repository. And "fell by more than 40%" is a relative drop in the revert share; the post doesn't give the absolute revert rate. The monorepo is the one that moved to Anthropic's in-house Scion source control system, which we covered in our story on Scion.

What went wrong along the way?

The post is candid about failures. The team originally ran several review rounds on every pull request, which it later judged worthwhile only for risky changes. Agent authors and agent reviewers could loop: one CLI pull request went through "more than fifty" review rounds overnight before its author stopped it. When the team checked what the reviewer kept flagging, about 59% was code that had been there since the first pass. "The reviewer was rarely finding new bugs, it was finding a few more old ones each round."

The fixes were a cap (after three rounds, the reviewer asks the author to reconsider the approach), diff-only re-reviews after the first few passes, flagging a whole class of bug at once, and never repeating a finding. The team also turned past incidents and reverts into a daily evaluation for the reviewer, and keeps a change to its prompts, tools or model only if the score rises.

The post lists open problems too. Nothing automatically tightens approvals when revert or incident numbers rise; engineers want such "circuit breakers" before more code merges with no human. Noticing a bad merge still depends on people. "Some mistakes will still get through."

What did Hacker News push back on?

These are community comments (Tier 3), not verified claims. No Anthropic staff reply was visible in the thread as of October 18.

• The scale argument. One commenter noted that "the 30k figure is for the entire Anthropic monorepo," not Claude Code. Others questioned why a CLI needs that volume of change; a reply pointed to the desktop, web, mobile and cloud products.
• Token budgets. "Anthropic can afford to do this because they have virtually unlimited tokens," one user wrote. Anthropic's own Scion post made a similar point, saying its internal token spend "far exceeds what any other business would realistically want to spend."
• Marketing. Several users read the post as a sales pitch for Anthropic's review products, one calling it "petty marketing."
• Reliability. Commenters cited Claude Code outages and past quality complaints as evidence against the approach. These are user claims.
• Rollbacks. One user argued that at this volume a "revert" usually becomes a new fix-forward commit, and that feature flags can preserve wrong behavior.
• Understanding. Commenters worried that nobody holds a full picture of the system. The post concedes that "nobody on the team keeps a complete mental model of Claude Code in their head."

The debate echoes others we've covered: open-source projects that ban AI-assisted contributions, and PostgreSQL 19's delay, where a committer says LLM-assisted review found defects faster than developers could fix them.

How do I get Claude Code to review my code?

Anthropic's docs list five ways, and the right one depends on your plan and code host.

Last verified: October 18, 2026

What does /code-review do?

/code-review is a bundled skill, so its instructions are built into Claude Code, with no SKILL.md on disk. It runs as a background subagent with its own context window and reports correctness bugs on your branch. Pass a pull request number, branch range, commit or path to review something else. --fix applies the findings and --comment posts them on a GitHub pull request or GitLab merge request. You can also pass an effort level: at low, the docs say, it reports only the findings it's most confident in. Before v2.1.223, /review was a separate single-pass pull request review; it's now an alias.

What is ultrareview, and what does it cost?

Ultrareview is a research preview that runs "a fleet of reviewer agents in a cloud sandbox," and the docs say every reported finding is "independently reproduced and verified." A review typically takes 15 to 25 minutes. Pro and Max accounts get three free runs, a one-time allotment. After that, a review typically costs $5 to $25 in usage credits depending on the size of the change, and Claude Code shows an estimate before launching. By default, a branch review is limited to 500 changed files and 8,000 changed lines. For scripts and CI, the claude ultrareview subcommand waits for the findings and prints them.

How do Code Review's levels and costs work?

The managed Code Review service became generally available on October 15, 2026, for Team and Enterprise organizations. Anthropic says most reviews now finish in about 6 to 10 minutes, down from roughly 20. An Owner picks one of three review levels, Quick, Standard (the default) or Deep, for the organization or per repository. These match the depths the Claude Code team describes in its post.

The costs page says there's "no flat per-review price." Cost scales with the review level, the size of the change, the surrounding code and how many candidate issues need verifying, and it's billed to the organization through usage credits, separate from plan usage. A repository added from the admin page starts at After every push, which runs the most reviews. Admins can set a monthly spend limit, and reviews are skipped when it runs out. Anthropic is offering eligible Enterprise organizations at least $10,000 in Code Review credits if claimed by January 15, 2027; the credits expire 30 days after they're claimed.

A review never approves or blocks a pull request, and it doesn't build or run your code. Anthropic's docs add that "a review with no findings doesn't mean your code is error-free or secure."

What about skills, plugins, prompts and security reviews?

• Prompts and rules. Anthropic doesn't publish the review prompt. You steer Code Review with a REVIEW.md at your repository root, plus your CLAUDE.md files. The docs' example caps nits ("Report at most five Nits per review") and lists paths to skip. REVIEW.md is read from the base or default branch, never from the pull request itself. The local /code-review reads CLAUDE.md but not REVIEW.md. Our CLAUDE.md guide covers writing instruction files.
• Skills and agents. To replace the built-in command, create a project or personal skill named code-review; /review keeps running the bundled one. You can also write a reviewer subagent. Claude Code's newer mods are a separate extension layer.
• Plugins. /code-review isn't a plugin. Anthropic's docs list a security-guidance plugin, which has Claude review its own changes for vulnerabilities, and a Claude Security plugin that scans a codebase.
• Security. /security-review checks your branch's diff for issues such as injection and auth flaws. Anthropic also publishes a GitHub Action, anthropics/claude-code-security-review, that reviews each pull request for vulnerabilities. Anthropic says these "should complement, not replace" existing security practices.
• GitHub. /install-github-app sets up the Claude GitHub App and, optionally, GitHub Actions workflows.

For how Claude Code's review features compare with Codex's @codex review and Cursor's Bugbot, see Claude Code vs Codex vs Cursor. GitHub's own AI Scan for pull requests is another option.

Should you copy Anthropic's process?

The post's own caveats are the best guide. Anthropic pairs AI review with things many teams don't have: risk classifiers, owner-listed sensitive paths, a merge queue, feature flags, staged release channels and dashboards for reverts and incidents. Its claim isn't that AI review is enough. It's that AI review plus fast detection and cheap reverts lets humans spend less time reading routine diffs. The post itself flags the cost of AI-authored noise: every non-bug comment triggers another agent commit and another round.

Two things carry over regardless of scale: make human approval depend on the change's risk rather than its author, and never let an agent's approval count as a person's. For an example of a maintainer directing Claude Code and reviewing its output by hand, see Linus Torvalds' kernel patch. Review tools also don't protect the credentials your agents use; see the OpenCode breach.

What's confirmed, reported and uncertain

• Confirmed (Anthropic's post and docs):
  • the process, risk tiers and convergence controls described in the October 15 post
  • /code-review as a bundled skill on any plan, with /review as an alias
  • ultrareview's free runs, typical $5 to $25 cost and 15-to-25-minute duration
  • Code Review's general availability on October 15, its Team and Enterprise availability, its Quick, Standard and Deep levels and its usage-credit billing
• Anthropic-reported, not independently verified: the 90% figure, the doubling of merged pull requests, the 40%-plus drop in reverts, the 16%-to-54% figure and the convergence statistics.
• Community reports (Hacker News): skepticism about scale, cost, marketing intent and reliability.
• Uncertain:
  • absolute revert and incident rates, which the post doesn't publish
  • whether the results hold for teams without Anthropic's token budget and release tooling
  • a typical per-review cost for the Code Review service, which Anthropic says depends on each repository