Claude Code Review is GA: what a base-branch REVIEW.md teaches us about agent standards

TL;DR

• On October 15, 2026, Anthropic moved Code Review for Claude Code out of research preview and made it generally available for Claude Team and Enterprise plans.
• The detail devs keep quoting: Claude Code Review reads REVIEW.md from the pull request's base branch or the default branch, never from the PR's own changes. A PR can't loosen the rules it's judged by.
• The bigger lesson: an AI reviewer is only as good as the standard you write down, and that standard should be protected, owned, and reviewed like code.
• Review time is the last place to apply a standard. Qodo moves the standard upstream: it mines rules from your team's PR history and hands them to the coding agent before it writes a line.

The one line in the docs everyone is quoting

Anthropic's GA post is mostly about speed and tuning. Most reviews now finish in about 6-10 minutes, down from roughly 20 during the preview, and admins pick a Quick, Standard, or Deep review level per repository.

The part developers latched onto is quieter. Here's how Donovan (@shipsatnight) put it on X the day after launch:

"REVIEW.md is read from the base branch, never from the PR. So a PR can't loosen the rules it's being judged by. Want new rules? Merge them first."

That's a small product decision with a big idea inside it. Your review rules are policy, and policy shouldn't be editable by the thing it's checking.

What REVIEW.md controls, and what each instruction needs

REVIEW.md is a freeform Markdown file at your repo root (plus optional subdirectory files) that tells Claude Code Review what to flag, at what severity, and what to skip. Per Anthropic's docs (checked October 16, 2026), some instructions only take effect when the root file sits on a protected default branch.

Instruction in REVIEW.md	Example	What it changes	Needs a protected default branch?
Redefine "Important"	"Important = breaks behavior, leaks data, blocks rollback"	Lowers or raises severity	Yes, for lowering severity
Cap nits	"Report at most five Nits"	Fewer low-value comments	Yes
Skip paths	"Ignore src/gen/ and *.lock"	Excludes files or issue classes	Yes
Always check	"New API routes have an integration test"	Adds a team rule to every PR	Not listed as required
Demand evidence	"Behavior claims need a file:line citation"	Cuts false positives	Not listed as required

Every instruction that makes the reviewer quieter depends on branch protection, while instructions that add scrutiny aren't listed with that requirement.

7 lessons a base-branch REVIEW.md teaches about agent standards

1. A rule the PR can edit is only a suggestion

If a reviewer read its rules from the PR branch, any change could ship a friendlier REVIEW.md alongside the code it wants waved through. Reading from the base branch closes that gap: new rules go through their own PR, get reviewed, merge, and only then apply.

This lines up with how the security world now talks about agents. The OWASP Top 10 for Agentic Applications (December 2025) lists agent goal hijack and memory and context poisoning among its top risks. An instructions file that untrusted changes can rewrite fits both descriptions.

Try this: treat every file an agent reads as instructions (REVIEW.md, CLAUDE.md, AGENTS.md, rules files) as config that needs its own review, separate from feature work.

2. Loosening is the risky direction, so it needs the most protection

The diagram shows the flow. Claude Code Review reads REVIEW.md from main, where it can't be pushed to directly. The PR's edited copy, which drops the tenant check and the nit cap, has no effect on that PR's review. For your repo, that means protecting the branch first and writing the rules second.

Anthropic's docs spell out the fallback cases too. With no protection on either the default or the base branch, the review reads only the root file. If Code Review can't confirm the protection settings at all, it reads no REVIEW.md. In both cases the check run carries a message about it, so read it once after setup.

3. AI review quality tracks the standard you actually wrote down

Out of the box, Claude Code Review focuses on correctness: bugs that would break production. Everything team-specific (your tenancy model, your logging rules, which folders are generated) has to come from you.

Liz Fong-Jones made the same point on Qodo's The Agentic Review podcast (episode "Is AI Making You an Average Engineer?", September 30, 2026): "you have to deliberately defend your codebase," and "I think making your standards written down is a positive side effect of this."

Most teams aren't there yet. In Qodo's State of AI Code Quality 2026 survey, 41.7% of 300 U.S. engineering leaders reported centralized AI coding standards, and 37.0% could enforce policy across teams and repositories. Among 500 U.S. developers, 34.6% said agents always follow organizational standards.

The chart puts the gap in one picture. The same 300 leaders who report 87% confidence that standards are consistent across AI tools mostly lack the centralized standards and cross-repo enforcement behind that confidence. The developer bar comes from a separate sample, so read it on its own. Both groups work at U.S. organizations already using AI meaningfully in the software development lifecycle (SDLC), so this isn't a picture of every company.

4. Be specific, because the bot will follow the letter of the rule

Liz has a great line about this from the same episode: "the bot will happily, you know, work to rule and do exactly what you told it rather than what you meant." A rule like "review for quality" gives a reviewer nothing to check. A rule like "queries must be scoped to the caller's tenant" does.

Here's a starter REVIEW.md for a backend service, adapted from the structure in Anthropic's docs:

# Review instructions

## What Important means here
Reserve Important for findings that break behavior, leak data,
or block a rollback: wrong logic, unscoped database queries,
PII in logs, migrations that aren't backward compatible.
Naming and refactoring ideas are Nit at most.

## Cap the nits
Report at most five Nits per review.

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file

## Always check
- New API routes have an integration test
- Log lines never include email addresses or request bodies
- Database queries are scoped to the caller's tenant

## Evidence
Behavior claims need a `file:line` citation, not a guess from a name.

Each section maps to one decision. "What Important means here" calibrates severity, "Do not report" cuts noise that CI already handles, "Always check" encodes the rules a senior reviewer would otherwise repeat by hand, and "Evidence" pushes back on confident-sounding false positives.

5. Standards rot unless a named person owns them

A rules file has no tests, so nothing fails when it drifts out of date.

Emilie Schario described this on The Agentic Review (episode "What Engineering Organizations Get Wrong About AI Adoption", September 2026). An engineering leader told her a team's CLAUDE.md had its last commit 12 months earlier. Her take: "you wouldn't think that, like, you buy silverware once and it's gonna be good forever. Right? You have to wash it every time you use it."

Try this: add REVIEW.md and your agent instruction files to CODEOWNERS, so a tech lead signs off on every change. Put a recurring reminder on the calendar to prune rules nobody has triggered in a quarter.

6. One standard copied into five places turns into five standards

Qodo's report describes the drift problem well: "A security requirement may be documented in a wiki, summarized in a repository file, partially encoded in CI, inferred from review history, and paraphrased again inside a prompt. Each version may express a slightly different interpretation of the same standard."

The same survey asked how standards reach the agent: 43.8% of respondents named repository-level instruction files, 41.4% code review history, and 26.0% rules manually added to prompts. The shares add up to well over 100%, so plenty of teams run several channels at once.

Anthropic's own split helps here. CLAUDE.md holds project context that Claude Code reads for every task, reviews included. REVIEW.md holds review-only rules. Agent instruction files are also converging: the Linux Foundation's Agentic AI Foundation took on AGENTS.md in December 2025 as a shared format for project guidance. Pick one source of truth per rule, and link to it from everywhere else.

7. Review time is the latest point to apply a standard, so teach the agent first

The diagram splits the loop into "teach" and "check." REVIEW.md lives on the right side: it judges code that already exists. Every violation it catches is work an agent already did and someone now has to redo. The left side is where the same rule is cheaper, inside the agent's context before the first line gets written.

This is the part we work on at Qodo, and the short version is "teach the agent the standard, don't just catch it after." Qodo's Rule Miner (beta on GitHub, GitLab, and Azure DevOps) reads review comments your team accepted and acted on, turns recurring ones into rules, and links each rule back to the PRs it came from. The Get Rules skill (research preview) lets Claude Code, Codex, or any MCP client load the rules that apply to a task before implementation starts. Qodo's review reads your REVIEW.md (research preview) too, so one file drives both the agent writing the code and the reviewer checking it.

You don't need any tool to start, though. Take the five review comments you typed most often last month and write them into REVIEW.md this week. For more habits that hold up with agents in the loop, see these code review best practices.

Where each kind of standard should live

Kind of standard	Best home	Who can change it	Applied when
Formatting, lint, types	Linters and CI	Anyone, through a reviewed PR	Every commit
Project context (stack, conventions, goals)	CLAUDE.md or AGENTS.md	Code owners	While the agent writes code, and as review context
Review severity, nit caps, skip lists	REVIEW.md on a protected default branch	Code owners, merged before it applies	At PR review
Patterns your reviewers keep repeating	Rules mined from PR history, each linked to source PRs	Team admins approve or dismiss	Before generation and at review
Security and data rules	CI checks plus an "Always check" section in REVIEW.md	Security and code owners	Every PR, with human sign-off

The table works as a quick audit. If a rule only exists in someone's head or in a single prompt, it has no owner and no protection yet.

Wrap-up

The base-branch rule is a nice reminder that the boring parts of review (who can change the rules, and when) matter as much as the model. Protect the file, give it an owner, keep it specific, and get the same standard in front of the agent before it writes the code you'll later review.

What's rule one in your REVIEW.md? Drop it in the comments.

FAQ

What is Claude Code Review?

Claude Code Review is Anthropic's managed pull request reviewer for GitHub, generally available since October 15, 2026, for Claude Team and Enterprise plans. Several agents read each change, a verification step filters false positives, and findings land as inline comments. It never approves or blocks a PR. For teams whose code spans GitLab, Bitbucket, Azure DevOps, or Gerrit, Qodo runs one consistent review across every provider.

Why does Claude Code Review read REVIEW.md from the base branch?

Claude Code Review reads REVIEW.md from the base or default branch so a pull request can't change the rules used to judge it. To change review behavior, you merge the REVIEW.md change first. Qodo's docs recommend the same discipline for its REVIEW.md support: add the file in its own PR so the rule change gets reviewed on its own.

What is the difference between REVIEW.md and CLAUDE.md?

CLAUDE.md holds project instructions Claude Code reads for every task, reviews included. REVIEW.md holds review-only rules: severity, nit caps, paths to skip, and checks to always run. The local /code-review command reads CLAUDE.md, not REVIEW.md. Qodo can import rules from existing guideline files and apply them in both coding agents and review.

What should go in a REVIEW.md file?

A REVIEW.md file should define what counts as Important, cap nits, list paths and checks CI already covers, add the team rules a senior reviewer repeats, and require evidence for behavior claims. Keep it short and specific. Qodo's Rule Miner can suggest rules from comments your reviewers already accepted.

How do you keep AI code review standards consistent across coding agents?

Keeping AI code review standards consistent across coding agents starts with one source of truth per rule, a named owner, and branch protection on instruction files. Then feed the same rules to the agent while it writes code and to the reviewer at the PR. Qodo's Get Rules skill (research preview) loads team rules into Claude Code, Codex, or MCP clients before implementation.

Does REVIEW.md replace human code review?

REVIEW.md does not replace human code review. Claude Code Review never approves or blocks a pull request, so the merge decision stays with your team. REVIEW.md just makes the AI pass quieter and more relevant. Qodo keeps people in charge and learns from them: humans accept or dismiss findings, and when reviewers keep dismissing what a mined rule flags, Qodo lowers that rule's weight over time.