What Anthropic published
On 15 October 2026, Anthropic published How the Claude Code team does code review, by Addy Osmani, Morgan Westlee Lunt and Qing Wang. Claude writes most of Claude Code's own code, and the team moved most of the reading to machines. The goal is the minimum amount of human review time that does not raise reverts or incidents.
The system has layers: required continuous integration (CI), an AI bug review and a security review on every pull request (PR), whose open findings block the merge, human approval scaled by risk, a merge queue that re-runs every check against main, and a gradual release behind feature flags. That is the team's internal process. Anthropic's separate Code Review product, for Team and Enterprise plans, posts findings on GitHub pull requests and, per its docs, never approves or blocks one. Any blocking described here belongs to the internal process.
The authors report that from June to September, merged PRs to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent. The post gives these as before-and-after figures, not a controlled comparison, so read them as evidence that the workflow changed, not proof of what caused the change.
The post is also honest about failure: one PR went through more than fifty review and fix rounds overnight, and the team now asks the author to reconsider the approach after three rounds. We covered review volume in AI code review does not scale linearly, and why review cannot keep pace with AI output. This article is about a different detail: what a review is allowed to trust.
The most important decision is not about AI
Two rules in this system matter more than the agents. The first is in the Code Review product documentation: the service reads REVIEW.md, the file of review instructions, "from the pull request's base branch or from the default branch, never from the pull request's own changes." To change review behavior, you merge the REVIEW.md change first.
Reading from the base branch only helps if that branch is protected. If anyone, or any agent, with push access can commit straight to main, they can change REVIEW.md there without review, and the next PR is judged by the edited copy. Instructions that weaken a review, such as lowering a finding's severity or excluding paths, are honored only when the file sits on a protected default branch. If Code Review cannot confirm the branch protection settings, it reads no REVIEW.md at all.
The second rule is from the post, about the internal process: "An approval covers one specific commit." New commits the system cannot vouch for, such as an agent's push, need a fresh approval. Some paths always need a person, including any CI workflow file.
Both rules limit what a verdict may depend on. If the change being judged can also edit the rules that judge it, a passing verdict tells you little about whether the change follows the rules the team agreed.
The docs also show that the product is not blind to architecture. CLAUDE.md is the instructions file that Claude Code reads for every task in a repository. Code Review reads the root CLAUDE.md and the one in each changed file's parent directories, and flags changes that violate them. So the reviewer knows the rules. The open question is who controls them.
When a pull request can rewrite its own rules
Here is a hypothetical, for illustration only. It is not an incident Anthropic or anyone else reported.
A team records a decision: controllers do not call the database directly. A rule for it lives in a policy file in the repository, and a CI job reads that file and fails the build on a violation. An agent working on a ticket adds a direct database call to a controller. The check fails. On its next attempt, the agent also edits the policy file and removes the prohibition, because the change "needs" it. CI checks out the PR branch, reads the edited file, and passes.
Keeping policy files in the repository is usually right, because rules should be versioned like code. The problem is which copy the gate reads. The evaluator applied the rules it was given, correctly. The change under evaluation supplied those rules. A reviewer skimming a large diff may miss three deleted lines in the policy file. An agent told to get the check green may treat the policy file as one more file it is allowed to edit, unless something stops it.
Four trust boundaries
A gate that blocks merges is only trustworthy if four boundaries hold. Switching a check from advisory to blocking does not create any of them.
- Trusted policy origin. Rules are read from a protected, versioned state, not from the change.
- Evaluator integrity. The change cannot swap the checker, its version or its configuration. A PR that edits the CI workflow file can replace the gate.
- Revision identity. The verdict names the exact commit it judged.
- Independent approval authority. Whoever approves a rule change is not whoever, or whatever, wrote the change.
Anthropic's mechanisms map onto these boundaries one by one. Reading REVIEW.md from a protected base branch covers trusted policy origin. Commit-specific approvals, and a merge queue that re-runs every check against main, cover revision identity. Human approval scaled by the risk of the change covers independent approval authority. Evaluator integrity is covered only in part: a person must approve any change to a CI workflow file, so a PR cannot rewrite its own pipeline unseen, but the post does not describe how the review agents' own versions and prompts are pinned.
In place of the self-governing PR above, a trustworthy check runs in this order:
- Read the approved decisions from a trusted, protected state.
- Run an evaluator that the change cannot modify.
- Evaluate the proposed change.
- Record a verdict bound to that exact revision.
- Let merge control that sits outside the change act on the verdict.
This is the core of engineering decision governance: knowing which decisions govern a change, and being able to prove it. A system cannot claim a change complied with engineering decisions unless it can show which decisions were authoritative when the change was evaluated.
Resolving a comment is not granting an exception
In the team's internal process, a PR cannot merge while a bug or security finding is open. You fix it, or close the thread with a short reason, which is how the team clears a false positive. That is the right design for a reviewer that is sometimes wrong.
It is the wrong design for an exception to a decision. A false positive means the reviewer misread the code. An exception means the code does break the decision, and someone with the authority to waive it has agreed it may. Those need different records. A waiver should say which decision it covers, who approved it, where it applies, why, and when it expires. A closed thread records none of that, so a year later nobody can tell an accepted exception from a dismissed mistake.
Deterministic rules cannot judge every architecture decision. Some choices need a person, and the post keeps people on architecture that sets a pattern others will copy. The trust boundary is about who decides, not about automating every judgment.
The same decisions must govern generation, review and merge
A coding agent, a reviewer and CI each read rules at a different moment. If they read three separate copies, those copies can drift apart, and the agent ends up held to rules it never saw. Approve decisions once, in one place, and have every stage read the same version. A change to a decision then becomes a reviewed change with its own history, as the path from decision records to decision governance sets out.
Where Mneme fits
Mneme, an open-source decision and control layer for agentic software development, works on the enforcement side of this flow. It keeps a team's decision corpus, the set of architectural decisions the team has recorded, in one file in the repository. A decision is enforced only when it has an active typed rule: a machine-checkable condition, such as an exact text string that must not appear in code, attached to the decision's current version.
Mneme checks a write before it lands when a supported agent uses its built-in file tools, such as Claude Code's Edit, Write and MultiEdit. Most shell writes land on disk first: Claude Code and Codex CLI check them when the agent finishes its turn, and in other agents only CI catches them. In CI, mneme check applies the same corpus and returns PASS, WARN or FAIL.
The Decision Index is the versioned record of each decision, with its lifecycle and source, and every stage reads it from the same file. It is a version history, not an approval record: it does not store who approved a decision, so teams that need that keep it where identities are verified, such as reviews of the pull requests that change the decision files.
Mneme has the gap this article describes, too. Its documented CI recipe reads the decision corpus from the PR's own checkout, so a PR that edits the corpus is checked against its own edit. Resolving decisions from a protected state, independent of the change, is not shipped. Neither are governed waivers, meaning recorded exceptions that name the approver, scope and expiry. Until it is, teams can use their Git host's code-owner rules to require an owner's approval for any change to the .mneme/ directory.
Five questions before you trust an AI review gate
- Where do the rules come from? If the answer is "the branch under review", the PR can rewrite them.
- Can the change modify the evaluator? Check whether a PR can edit the workflow file, the checker version or its configuration.
- Does the verdict name a commit? An approval or pass should not survive a new push it never saw.
- Who can change a rule? Someone other than the change's author.
- How is an exception recorded? Separate "the reviewer was wrong" from "we accept this violation", and give the second an owner and an expiry.