Anthropic's Claude Code Review Reaches GA, but Never Blocks a Merge on Its Own

Code Review leaves preview

On October 15, Anthropic took Code Review for Claude Code out of research preview and made it generally available to Claude Team and Enterprise organizations. According to the announcement, administrators now choose one of three review depths per repository — Quick, Standard (the default), or Deep — and most reviews finish roughly three times faster than during the preview, down from about 20 minutes to 6–10 minutes.

The documentation describes a pipeline in which several agents read a pull request's diff and the surrounding code in parallel, followed by a verification pass that discards suspected false positives before anything is posted. Findings land as inline comments plus a check run named Claude Code Review, each tagged Important, Nit, or Pre-existing. Reviews run on Anthropic's infrastructure with read-only access and never build or execute repository code. The product works only with GitHub and is unavailable to organizations using Zero Data Retention, the HIPAA configuration, or customer-managed encryption keys. A local /code-review command remains available inside Claude Code sessions on any plan.

A reviewer that cannot fail a build

The defining constraint is that the product never enforces anything. Per the docs, a review never approves or blocks a pull request, and the check run never concludes as a failure. The Claude Code team, in a same-day post about how it reviews its own code, framed this as deliberate: approving is "still a human call; the product posts findings, not approvals."

Internally, Anthropic goes further than the product it sells. In the Claude Code repositories, the team wrote, a PR cannot merge while any finding from the bug review or the security review remains open.

The numbers Anthropic reports

The team post says Claude writes about 90 percent of Claude Code's own code, and that between June and September merged pull requests to that codebase more than doubled while the share that had to be reverted fell by more than 40 percent. These are Anthropic's figures about Anthropic's repos, given without base counts; The Next Web notes the performance claims have not been independently tested.

The stated goal is that most PRs merge with at most one human in the loop, who can be the author. A classifier assigns each change a risk tier: low-risk work such as documentation or additive changes behind a flag needs no human approval once automated checks pass, medium-risk changes need one, and the highest-risk code needs two. The change sets the tier, not the author; whoever prompted the change is accountable; an approval covers one specific commit; and sensitive paths and CI workflow files always require a person. The post also concedes a gap: there are no circuit breakers yet that tighten approvals when revert or incident numbers move, and engineers want them before more code shifts to zero-human merges.

Anthropic also runs a layer before a PR exists — Claude executes tests, build and linter, and a subagent reviews the diff in a fresh context. Boris Cherny, who created Claude Code, estimates this verification makes the final result two to three times better.

Making findings block a merge

Because the product will not stop a merge, repositories that want enforcement must build it, as a dev.to write-up by Gabriel Anhaia details. One option is GitHub's branch-protection rule requiring all PR comments to be resolved before merging; findings arrive as inline threads, so an open one blocks the merge. The trade-offs: the rule also catches nit-level threads and human comments, and findings GitHub will not accept as inline comments appear only as annotations.

The second option gates on Important findings only. The check run's details text ends with a machine-readable line that the GitHub CLI can parse for a count of open Important findings, letting a pre-merge job fail when the count is nonzero. The docs advise treating a missing line as no verdict rather than zero findings, and the gate should run only after the check completes, since a review takes minutes. Customization lives in a REVIEW.md file read from the PR's base branch or the default branch, never the PR's own changes — so a PR cannot loosen its own review — though severity-lowering rules are honored only when the default branch is protected.

Pricing and cost controls

There is no flat per-review price. Reviews are billed on token usage through usage credits, separately from a plan's included usage, and The Next Web reported preview-era reviews cost $15 to $25 each. New repositories default to reviewing after every push, which multiplies spend; the docs recommend piloting on once-after-PR-creation or manual triggers, watching the average-cost column, and setting a monthly limit, after which reviews are skipped with an explanatory comment. Eligible Enterprise organizations can claim at least $10,000 in Code Review credits by January 15, 2027.

Why it matters

The release turns AI code review into a purchasable CI component, but Anthropic deliberately splits detection from enforcement: the model surfaces findings while approvals and merge gates stay human-owned. The gap between the neutral-by-design product and Anthropic's own blocking, risk-tiered internal policy is itself a template for teams that want automated review without handing over the merge button. The internal statistics point toward near-zero-human merges, and the team's admission that circuit breakers are still missing is a candid reminder of what must exist before that is safe. Token-based pricing and push-triggered defaults mean cost governance will matter as much as review quality.