AI Code Review: Agents, Add-ons, Prompts

For code review, run an AI reviewer as a first pass on every pull request, then let a person review what it flags and what it cannot judge. Pick the tool by where your code lives: Copilot for GitHub pull requests, Claude Code or Codex for terminal and CI, or a read-only subagent with your own checklist. A review costs cents. Checked 31 October 2026.

The job in one table

What the job is

Code review is where a second pair of eyes catches mistakes before they ship. It is also a bottleneck: reviewers are busy, diffs are long and the same comments appear again and again, such as "add a test" or "this can be null." AI is good at the repeated comments and the careful reading of tedious diffs. It is weaker at knowing why the change exists, how the system should look in a year or what the team agreed last week.

The best use is a first pass. The AI reads the diff, posts a short list of issues with file and line references, and the human reviewer starts from that list. Devin's own page makes the matching point about agents in general: more pull requests means more reading, and a cloud agent moves the bottleneck to the reviewer. If the review step is the bottleneck, a first-pass tool is where AI helps the most.

Which agent fits

Claude Code's own docs give the pipe pattern: feed a diff into a one-shot prompt, for example git diff main --name-only | claude -p "review these changed files for security issues". The docs also list a bundled /code-review skill and mention /review-pr as an example of a team skill. For a longer walkthrough of building your own reviewer, see build a code review agent.

Add-ons and kit items that help

The reason to use a subagent for review is that it can be read-only: give it Read, Grep and Glob and nothing else, so it cannot edit your branch. Claude Code's docs show a sample code-improver subagent with exactly those tools. See how to write a subagent. Prompts for review sit in the prompt library.

A safe workflow, step by step

1. Write your standards down. A short list in CLAUDE.md or AGENTS.md: naming, error handling, test rules, security must-haves.
2. Run the AI on every pull request. Locally, in CI or through the host.
3. Keep its tools read-only. It posts comments; it does not push commits.
4. Ask for a fixed format. File, line, severity, one-sentence reason, suggested fix.
5. Limit the comment count. Ask for the top five issues, not forty. Long lists get ignored.
6. Require a human approval. The AI review is advice; the merge needs a person.
7. Track what happens to its comments. Resolved, dismissed or ignored.
8. Tune monthly. Remove rules that produce noise; add rules for what slipped through.

What it costs

There are two ways to pay: per seat or per token.

See GitHub Copilot pricing, Claude Code pricing and Codex pricing.

Worked example (the token counts are our assumptions). A diff and surrounding files of 20,000 input tokens, with a 2,000-token review back:

The model cost is trivial. A larger diff, more context files and retries move it up, though rarely past a few dollars per pull request. The real cost is reviewer time spent reading false positives. If a tool leaves ten comments and eight are noise, it costs more than it saves.

Risks and how to review them

Treat the AI reviewer like a new teammate with no context. Claude Code's docs also note that instruction files are context, not enforced configuration, so for must-never rules use a check that fails the build. For private code, read AI coding agent security and see private AI for teams.

How to judge a reviewer

Run any candidate on ten closed pull requests where you know the outcome: five that had real bugs found in review and five that were clean.

A tool that catches three of five and adds two useful comments with little noise is good. One that catches four but adds twelve false comments will be switched off within a month. Our benchmark guide explains why public scores are a poor substitute for this test.

An output format that people read

A reviewer's value depends on how its comments look. A format that works is one line per finding, sorted by severity.

Asking for confidence matters. It lets a human reviewer start with the high-severity, high-confidence items and skim the rest. Ask the model to say "no issues found" plainly when that is true, instead of inventing nits to look useful.

Rules worth writing into the reviewer's instructions

• Review only the changed lines and what they call; do not rewrite the whole file.
• Report at most five findings, highest severity first.
• Never suggest style changes the formatter already enforces.
• Flag any new dependency, any change to authentication or permissions and any new network call.
• Flag a changed public function with no changed test.
• Do not say a change is safe. Say what you checked and what you did not.

The last rule is the most important. A reviewer that says "looks good" teaches people to stop looking. A reviewer that says "I checked null handling and the SQL; I did not check concurrency" tells a human where to look next.

Handling big diffs

Models read a limited amount at once; see context window. A 3,000-line diff is a poor review target for anyone. Three habits help:

1. Review by file group. Run the reviewer per directory and merge the findings.
2. Skip generated files. Lockfiles and build output waste tokens and produce noise.
3. Push back on size. A policy such as "pull requests over 800 changed lines get split" improves human review as well.

A subagent also helps: it can read the surrounding code in its own window and return a short summary, so the main review keeps its space.

Wiring it into CI

Several of these tools can run in CI. Claude Code's docs list GitHub Actions and GitLab CI/CD for pull request review and issue triage, and the claude -p mode runs a single prompt non-interactively, so you can pass a diff in and print a review out. A sensible CI job:

• Runs on pull request open and on new commits, not on every comment.
• Uses a token that can comment but cannot push or merge.
• Posts one summary comment and updates it instead of adding new ones each run.
• Skips drafts and bot-authored pull requests.
• Has a spend cap and a timeout.

For Claude Code, the official route is /install-github-app, which installs the Claude GitHub App and stores an ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN repository secret. The docs list the app's permissions as read and write on contents, issues and pull requests, so it can push as well as comment. Tighten that with branch protection rather than trusting the default. Never give the job a token that can write to your main branch, a point the Codex page makes too.

A team policy you can copy

Who should do what

For related jobs, see AI testing agent for the tests that back a review and AI documentation for the docs that change with code.

Our take

AI review is a good first pass and a poor last word. Use it to clear routine comments, keep it read-only, cap its output and make a person approve. We built this page from vendor docs and our pricing pages and have not run these reviewers on a real repository ourselves, so test on your own closed pull requests before you trust any of them.