The Claude Code Review Playbook, Across Every AI Tool
What the Claude Code team's code review post recommends, and how to turn incidents and repeated review comments into checks that run across Claude Code, Cursor, Codex, and Copilot.
On October 15, 2026, the Claude Code team published How the Claude Code team does code review. It is a detailed public account of how one team reviews code as agents write more of it. Between June and September, they write, “merged pull requests to Claude Code’s codebase more than doubled while the share that had to be reverted fell by more than 40 percent.”
This post is about one part of that playbook: the loop that turns repeated mistakes into permanent checks. It also covers what changes when your team works across more than one AI coding tool. EvalGate is not affiliated with Anthropic, and this is our reading of a public post, not theirs.
Human time is the budget; reverts are the guardrail
The post’s organizing idea is that review now exists to protect the scarcest resource: “To measure human time, we track human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, we haven’t saved human time, we’ve only moved it.”
Everything else follows from that. Machines do most of the reading, a classifier sets how many people must approve, and “An agent’s approval never counts as a person’s, either.”
The part that compounds: fix it at the source
Two lines in the post describe a loop that gets stronger every week:
- “When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files.”
- “Any incidents are now an eval.”
Their adoption checklist makes the second one concrete: “Turn incidents and reverts into an eval set, and rescore the reviewer whenever its prompts, tools or model change.” A correction made once should not have to be made again, and when something does escape, it becomes a test that runs from then on.
Where it gets harder: more than one tool
The post describes one team’s setup, built around Claude Code. Its fixes live in CLAUDE.md, REVIEW.md, skills, and lint rules. Those are the right places for them.
Many teams split work across Claude Code, Cursor, Codex, and Copilot. Each tool reads its own instruction files, so the same correction ends up written several times, in several formats. The harder question is not where to write the correction. It is how you know it held across every tool that touches the repo.
That is the gap a gate fills. An instruction asks an agent to behave. A check that runs in CI shows whether it did, regardless of which tool wrote the change.
The checklist, mapped
Here is each relevant item from the post’s “How you can adopt this process” section, quoted, with where EvalGate fits. Where it doesn’t, we say so.
| The post recommends | With EvalGate |
|---|---|
| “a REVIEW.md where repeated comments go” | Keep the REVIEW.md. When a repeated comment is about behavior you can test, also save it as a check, so CI verifies it instead of relying on a reviewer to remember it. |
| “Turn incidents and reverts into an eval set” | Write the incident as an executable regression case and prove the known-bad version fails before the fix passes. Then record your review of the run with npx @evalgate/sdk label. Labeling adds feedback, not an assertion. See turning agent failures into regression tests. |
| “rescore the reviewer whenever its prompts, tools or model change” | If your reviewer is an agent you run, treat it as an AI system under test: record a baseline, then run npx @evalgate/sdk gate when its prompt, tools, or model change. |
| “Require CI” | Run the same checks on every pull request with npx @evalgate/sdk ci --format github in GitHub Actions, or the GitLab CI recipe. |
| “Never let a bot’s approval replace a required human’s” | EvalGate reports results; it does not approve pull requests. Approving a new standard or publishing a change needs a person. |
| “Measure human time, with revert and incident rates as the guardrail” | EvalGate does not measure review time. It keeps the gate result for each commit, which you can line up with your own revert and incident data. |
What EvalGate doesn’t do
Most of the post’s stack is outside our scope, and you should use the tools built for it: AI code review on pull requests, security review, CODEOWNERS and branch protection, merge queues, feature flags, staged releases, and rollback. EvalGate covers one layer: turning the mistakes you’ve already seen into checks that run on every change, across the tools your team uses.
Start with one incident
You don’t need the whole stack to begin. Pick the last revert or incident that involved AI-written code. In the checkout that owns the behavior, install the SDK, preview local setup, and apply it after reviewing the proposed files:
npm install --save-dev @evalgate/sdk
npx @evalgate/sdk init --local --preview --format json
npx @evalgate/sdk init --local --apply --format jsonSetup creates a placeholder, not an incident regression. Replace it with a real evaluator that calls your application or reviewer and checks the behavior behind the incident. Remove customer data from the fixture, review the expected outcome with the owner, and prove that the known-bad version fails and the fixed version passes. The coding-agent authoring guide covers preparing those cases. Register the finished specs, then save a run before labeling it:
npx @evalgate/sdk discover --manifest
npx @evalgate/sdk run --write-results
npx @evalgate/sdk label --run .evalgate/last-run.jsonLabeling records human feedback; it does not add an assertion to the gate. Keep the reviewed incident assertion in the executable suite. Review the non-empty passing run and commit the application and eval source before accepting a baseline. Acceptance is a separate human decision, not a step to run against known-bad behavior:
npx @evalgate/sdk baseline update
npx @evalgate/sdk gate --format jsonThe unchanged suite should pass. Reintroduce the incident in a disposable checkout and verify that the same gate blocks it, then discard that intentional break. Re-run discovery whenever specs change. These commands use deterministic offline checks by default; a model-backed reviewer needs explicit provider configuration and network permission. Check the installed package’s command inventory with npx @evalgate/sdk capabilities --format json.
Your first 10,000 test-case results each month are free, then $1 per 1,000. Model costs stay on your own provider bill. Start with the quickstart, or read the original post first; it is worth it.