AI code review with judge agents runs several model reviewers over a pull request, each looking for one class of problem, then passes their findings to a verifier that checks each against the actual code and drops what it cannot confirm. What survives is ranked by severity and posted with file and line evidence. The agents flag. A person still decides whether to merge.
How does a judge-agent review work?
Split the review into roles.
- Finders. Several agents read the diff and the code around it, each with one focus: logic errors, security, data integrity, API compatibility, migration safety.
- Verifier. A separate pass checks every candidate finding against the code's actual behavior and discards what it cannot confirm. It keeps false positives down.
- Reporter. Duplicates are merged, findings are ranked by severity, and each is posted on the line it concerns, with a summary at the top.
Anthropic's managed Code Review for Claude Code works this way. As of September 2026 it is a research preview for Team and Enterprise plans. Findings are tagged Important, Nit or Pre-existing. It never approves or blocks a pull request, so any merge gate is one you build.
What severity rubric should an AI reviewer use?
A short one the humans already agree with, written down. Without it, review becomes a stream of preferences.
| Level | Means | Examples |
|---|---|---|
| Important | Fix before merge | Wrong logic, data loss, a query not scoped to the tenant, secrets or personal data in logs, a migration that cannot roll back |
| Nit | Worth fixing, not blocking | Misleading names, a missed edge case in a helper, a rule from the repo's instructions broken |
| Pre-existing | A real bug this PR did not introduce | Report once, route to the backlog, do not hold the PR |
| Do not report | Anything CI already enforces | Formatting, lint, type errors, generated files, lockfiles |
Require evidence for every Important finding: the file and line, what happens, and how to reproduce or check it. A finding inferred from a function's name, rather than its code, is the usual false positive.
How do you tune what the reviewer flags?
Keep review rules in the repository. Claude's Code Review reads CLAUDE.md as general context and a root REVIEW.md as review-only instructions. The same text works as the system prompt for a reviewer in your own CI.
# Review instructions
## Important means
Incorrect logic, unscoped database queries, personal data in logs,
and migrations that are not backward compatible. Style is Nit at most.
## Limits
Report at most five Nits. Mention the rest as a count in the summary.
After the first review, post new Important findings only.
## Do not report
Lint, formatting, type errors. Anything under src/gen/ or any *.lock file.
## Always check
New API routes have an integration test.
Behavior claims cite file:line in the source, not a guess from a name.Keep it short. A long review file dilutes the rules that matter.
What does AI code review cost, and how do you run it?
- Managed. Claude's Code Review is billed on token use, separately from plan allowances, and Anthropic's docs put the average at $15 to $25 per review as of September 2026, rising with the size of the change. Reviewing on every push multiplies it, so many teams review once per PR or on request with
@claude review. - In your own CI. Run Claude in GitHub Actions or GitLab CI/CD with your own rubric and pay only for the API use.
- Before pushing. In Claude Code, the
/code-reviewcommand reviews your local diff in the terminal.
How do you know the reviewer is worth keeping?
Measure it for a month like any other reviewer.
- Acceptance rate: findings that led to a code change, out of findings posted.
- False positives: findings dismissed as wrong. Thumbs-down reactions on comments are a cheap way to count them.
- Escaped defects: bugs found after merge in code the reviewer saw. This is the number that justifies the cost.
- Noise: comments per PR, and how many were Nits. Rising nits with flat acceptance means tighten the rubric.
If acceptance stays low, narrow the reviewer to the one class of bug it catches reliably, or turn it off.
Where does AI review go wrong?
- Nit floods that train the team to ignore every comment, including the real one.
- Reviewing code nobody wrote: generated clients, vendored code, lockfiles.
- Untrusted pull requests. A PR from outside can carry text aimed at the reviewer. Review a fork's PR only when a maintainer asks.
- Treating silence as approval. "No issues found" means none the reviewer could verify, not that the change is safe.
Common questions
Can an AI agent approve a pull request?
It can be wired to, but it should not be the approver. Anthropic's managed Code Review never approves or blocks a PR. Use AI findings as input, gate merges on your own tests and rules, and keep a person as the approver.
What is a judge agent?
A judge agent is a language model given a specific job of evaluating something, such as a code change, against a written rubric and returning a verdict with evidence. In code review, several judges usually look for different problems, and a separate verifier checks their findings before anything is posted.
Does AI code review replace human reviewers?
No. It catches specific classes of bug early and reads every line consistently. It does not know the product intent or what the customer needs, so human review moves toward design and intent.