Code Review goes generally available: AI review becomes an organization setting, not a personal trial

On October 15, 2026, Anthropic moved Code Review for Claude Code out of research preview and into general availability for Claude Team and Enterprise organizations. The headline numbers are easy to quote: most reviews now finish in 6 to 10 minutes, down from about 20 minutes during the preview, and administrators can now pick a Quick, Standard, or Deep review level for each repository. But the numbers are the least interesting part of this release. What actually changed is the status of AI code review inside a team: it stopped being a preview feature that an individual developer tries, and became an organization-level setting that an administrator turns on, budgets for, and is accountable for.

That shift is worth pausing on, because it changes how you should evaluate the tool. In preview, the right question was "does it find real bugs?" In general availability, the right questions are different: which repositories get which depth, what does a review cost at your pull request volume, what happens when the reviewer disagrees with your team, and who owns the rules it enforces. This article answers those questions from Anthropic's October 15 announcement and its Code Review documentation, and marks clearly where a figure is Anthropic's own claim rather than an independently verified result.

What the service actually does

Code Review is a managed service, not a plugin you install in your editor. An administrator enables it in Claude Code settings, installs the Claude GitHub App, and selects repositories. From then on, reviews run automatically on new pull requests, with no per-developer setup. Each review runs in four stages: several agents examine the diff and surrounding code in parallel to look for issues; a verification step checks candidate findings against the code and filters out false positives; the remaining findings are deduplicated and ranked by severity; and the results land on the pull request as inline comments, plus a summary and a check run named Claude Code Review.

Two properties of that check run matter more than they first appear. First, the check run never concludes as a failure, and a review never approves or blocks a pull request. The merge decision stays entirely with the team. That is a deliberate design choice: the service is positioned as a second reader, not a gate. Second, when a review finds nothing, it says so explicitly. A clean review is a statement you can read, not silence you have to interpret. Both properties protect the same thing: the team's ability to keep its own judgment in charge of merging, while still getting a systematic second look at every change.

What it reviews, and what it deliberately does not

By default, Code Review focuses on correctness: bugs that would break production, rather than formatting preferences or missing test coverage. That default is a judgment call worth understanding, because it determines whether your team will experience the tool as helpful or noisy. A reviewer that flags style nits on every pull request trains developers to ignore it; a reviewer that only speaks up about production-breaking correctness issues earns the right to be read. Teams can tune what gets flagged with REVIEW.md and CLAUDE.md guidance files, but the default already encodes Anthropic's bet about where an automated reviewer earns trust.

Reviews can run once when a pull request opens, after every push, or only on request, and anyone with write access can start one by commenting "@claude review". Draft pull requests and forks are excluded from automatic reviews. Those exclusions are practical, not philosophical: a draft is by definition unfinished, and a fork's automatic review would hand an external contributor's code a free review pipeline. If your workflow relies on draft pull requests as the main review surface, you will need to trigger reviews explicitly rather than expecting them to appear.

The REVIEW.md detail that deserves its own paragraph

Code Review reads REVIEW.md from the pull request's base branch or the repository's default branch, never from the pull request's own changes. That single rule is the most consequential design decision in the whole release, and it is worth stating plainly why: if the reviewer read its rules from the branch under review, any pull request could ship a friendlier REVIEW.md alongside its code and loosen the standard it is judged by. By forcing rules to come from the protected base branch, Anthropic makes new rules go through the same merge-and-review process as code before they apply. A rule the thing being checked can edit is a suggestion; a rule it cannot edit is policy. If you take one operational action from this article, make it this: write your REVIEW.md, protect the branch it lives on, and review changes to it as carefully as you review changes to code.

Depth levels, cost, and the credits offer

Administrators choose Quick, Standard (the default), or Deep for each repository. Routine codebases get a quick pass; the most critical ones get a deep review. A more thorough review level costs more, because reviews are billed on token usage, separate from the plan. During the preview, Anthropic's documentation and reporting put the typical review at roughly $15 to $25, scaling with pull request size and complexity; treat that as a preview-period reported figure, not a GA price list, because Anthropic has not published a per-review price for general availability. The only reliable cost number for your team is your own average after a pilot week, which is why the sensible rollout is Standard on a few representative repositories, with a spend limit set, before deciding levels per repository.

Eligible Claude Enterprise organizations can claim at least $10,000 in Code Review credits, with the claim window closing at 23:59 UTC on January 15, 2027, and credits expiring 30 days after they are claimed. The details matter: the claim is made once, it cannot be undone or repeated, and the 30 days run from the claim whether or not reviews are running. Set up Code Review on your repositories before claiming, or you will burn part of the window on setup. The credits do not cover the self-hosted GitHub Action, Code Review on GitHub Enterprise Server, or the /code-review commands, and several categories of organization are excluded, including trials, reseller-billed organizations, and organizations with zero data retention. Read the offer terms before claiming; a credit that expires while you are still configuring is worse than no credit at all.

Who cannot use it, and what it does not do

The service requires a Team or Enterprise plan and repositories hosted on GitHub, including GitHub Enterprise Server and GitHub Enterprise Cloud with data residency. It is unavailable to organizations with Zero Data Retention enabled or the HIPAA configuration applied, it is not covered under Anthropic's Business Associate Agreement, and it is not yet available to organizations using customer-managed encryption keys. A Claude organization is required even when developers use Claude Code through Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. Reviews run in a managed environment with read-only repository access: they read the diff and surrounding code without building or running it, and they do not run in self-hosted environments.

Anthropic's documentation also states the limitation that every team should internalize before turning this on: Code Review uses AI and may miss bugs, security vulnerabilities, or other issues, and a review with no findings does not mean code is error-free or secure. That sentence is not boilerplate. A clean AI review on a pull request that touches authentication or payments should change nothing about how carefully a human reads that diff. The service is a second reader with a budget, not a proof of correctness, and teams that treat a clean review as a safety certificate will eventually be surprised by exactly the class of bug the documentation warns about.

How this differs from Anthropic's own engineering post

Readers of this site may remember a separate October 15 post from the Claude Code team describing how Anthropic reviews its own code, in which Claude writes about 90% of Claude Code's code and merged pull requests more than doubled from June to September while the revert share fell by over 40%. That post is an internal engineering story: a seven-layer process built for one team, one product, and one workflow, counted by the people who built it. This article is about something else: the externally available product, its availability, its depth levels, its billing, and its limits. The internal figures are interesting, but they are not evidence about what Code Review will do on your repository, and no external audit of them has been published. Judge the product by a pilot on your own pull requests, not by another team's internal metrics.

The practical takeaway is therefore modest and concrete. If you are on a Team or Enterprise plan and your code lives on GitHub, pilot Code Review at Standard on a handful of repositories, write a REVIEW.md that states what your team actually cares about, set a spend limit, and read the average cost and the false-positive rate after a week. If the findings are quiet, specific, and actionable, widen the rollout repository by repository. If they are noisy, tune REVIEW.md before you tune the depth level: most noisy reviewers are noisy because the standard was never written down, not because the model is wrong. General availability does not make AI review trustworthy by itself. It makes it configurable, billable, and accountable, and those three properties are what let a team decide for itself whether to trust it.