How to write an AI code review policy for a team using Claude Code

An AI code review policy is a short document that says how changes written with Claude Code get checked before they reach your live site: who reviews what, which checks must pass, which changes need extra eyes, and what gets recorded. It exists because AI-written code arrives fast and looks finished, and "looks finished" is not a test. A good policy fits on two pages, is enforced by repository settings rather than goodwill, and treats Claude's output the way you would treat a capable new developer's: welcome, but reviewed.

Anthropic's own terms put the responsibility on the customer. The Commercial Terms say "It is Customer's responsibility to evaluate whether Outputs are appropriate for Customer's use case, including where human review is appropriate," and Anthropic's security page says "You're responsible for reviewing proposed code and commands for safety before approval." This guide gives you a policy structure, a risk-tier table you can adapt, and the GitHub and Claude Code settings that back it up, as of October 2026.

What the policy should cover

Keep the data rules short and link to the detail; our guide to managed settings and admin controls covers the settings that enforce them.

Risk tiers for website changes

The tier decides the review, not the author. A sample, to adapt to your site:

Bulk edits deserve their own rule because they fail quietly. The house rule on eseospace.com is to run every bulk edit on a copy first, then twice on the real files, where the second run must change nothing. During our own accuracy audit in September 2026, more than 4,400 corrections across about 750 pages went in as scripted edits, each tested on a copy first. The failures we hit along the way, such as a script that worked on the first page and broke the second, are described in common Claude Code mistakes on websites.

What a reviewer actually checks

A policy that says "review the code" without saying what to look for produces rubber stamps. Give reviewers a checklist:

1. Does the diff match the request? Nothing extra, nothing missing. Unrelated changes are a red flag.
2. Does it work? The build passes and the reviewer has seen the result on staging, not just the code. Anthropic's best-practices page: "If you can't verify it, don't ship it."
3. Is anything new loaded or sent? New scripts, packages, external URLs, form endpoints or tracking calls.
4. Are facts right? Prices, phone numbers, addresses, legal and medical claims. AI output can be confidently wrong; Anthropic's Commercial Terms say "factual assertions in Outputs should not be relied upon without independently checking their accuracy."
5. Is SEO intact? Titles, canonicals, robots rules, redirects and structured data on affected pages.
6. Is anything secret exposed? Keys in code, verbose error output, debug pages.

Reviewers who aren't developers can still do most of this. Our guide to reviewing a diff when you aren't a developer walks through it. For content, the same principle applies to text as to code; see AI-generated vs human-edited content.

Enforce it in GitHub, not just in the document

Write the policy, then make the repository enforce it. On GitHub's protected branches for your main branch:

• Require pull request reviews before merging. With this on, collaborators "can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions."
• Require status checks before merging, so the build and checks must pass.
• Apply the rules to administrators too if your policy covers everyone, since by default they "don't apply to people with admin permissions" unless you configure them to.
• Force pushes are disabled and branch deletion is prevented by default on protected branches.

Protected branches are available on public repositories with GitHub Free and on private repositories with GitHub Pro, Team or Enterprise plans. Then add the Claude Code side: ask rules so Claude prompts before git push and pull request creation, bypass mode disabled in managed settings, and an approved list of tools. Phasing these settings in during a pilot is covered in our rollout plan for teams.

Automated checks: useful, not sufficient

Automation catches a lot and costs little reviewer time, so require it for medium and high tiers:

The policy should say plainly that a passing automated review is not an approval. Anthropic designed Code Review so its findings "don't approve or block your PR." A person still decides.

Review with fresh eyes, including Claude's

The session that wrote a change is the worst reviewer of it. Anthropic's best practices suggest a "Writer/Reviewer pattern," with a second session reviewing the first, because "A fresh context improves code review since Claude won't be biased toward code it just wrote." They also suggest having "a subagent review the diff in a fresh context and report gaps." That is a good pre-review step, and our guide to subagents shows how to set one up. Write into the policy that it supports the human review and doesn't replace it.

Disclosure, records and exceptions

By default, Claude Code adds a git trailer such as Co-Authored-By to commits and a line to pull request descriptions. The attribution setting can change or hide that text. Decide which you want: many teams keep it, because it makes AI-assisted changes searchable in history, which helps when you audit an incident. Records worth keeping: the pull request with reviewer approval, the checks that ran, and for high-tier changes a note of what was tested on staging.

For exceptions, name who can grant them and require them in writing. For incidents, the policy should say what happens when an AI-assisted change breaks something: revert first, then find which review step should have caught it and fix that step, not the person.

Conclusion

A workable AI code review policy is short and specific: work happens on branches, changes are tiered by risk, reviewers have a checklist, automated checks are required but never final, and GitHub and Claude Code settings enforce the rules so nobody has to remember them. Review the policy every few months, because Claude Code changes quickly. If you want help writing a policy and setting up the review process and settings behind it, that is part of our Claude Code consulting. More guides are in our Claude Code Guide.

Frequently asked questions