AI Code Review Tools Compared, and a Checklist for Using Them

AI code review tools read a pull request, or a diff on your machine, and leave comments about likely bugs, security problems and style. The main ones differ less in what they find than in where they run and what they are allowed to do: GitHub Copilot code review lives inside GitHub and your editor; Claude Code reviews in the terminal, in your own GitHub Actions, or as a managed service; CodeRabbit and Cursor Bugbot are hosted apps that work across several code hosts; Graphite’s reviewer sits inside its own pull request workflow; and PR-Agent is open source and runs with the model you choose. Pick by fit with where your code lives and who may see it, and keep a person as the approval.

How to wire an AI reviewer into a pull request and keep a human as the gate is covered in AI agents for PR review, including branch protection settings. This piece compares the tools and ends with what the human reviewer should check.

What an AI reviewer is good at, and what it is not

An AI reviewer reads every line, never gets tired on the fortieth file, and is good at local mistakes: an off-by-one, a missing null check, an unescaped query, a changed function whose callers were not updated. It is weaker at what needs knowledge outside the diff: whether this feature should exist, whether the design fits next year’s plans, whether the behaviour matches what the customer asked for. Every vendor below says, in one form or another, that its reviewer can be wrong and does not replace a person. Treat the comments as a first pass that makes the human review shorter.

The tools, as their makers document them

GitHub Copilot code review

• Where it runs: on pull requests on GitHub, and according to GitHub’s code review overview↗ (opens in a new tab) also in the GitHub CLI and Mobile, VS Code, Visual Studio, Xcode and JetBrains IDEs, with Azure DevOps in public preview.
• What it comments on: code in any language, looking for bugs, security vulnerabilities and style inconsistencies, often with a suggested change you can commit. It skips some files, such as dependency manifests and lock files, logs and SVGs.
• Configuration: it reads the repository’s custom instructions, agent instructions and skills from the head branch. Automatic review on every push is a repository setting. An optional Copilot approvals setting, in public preview, lets it submit an approving review.
• Open source: no. It is a feature of GitHub Copilot.

Claude Code

• In the terminal: /code-review (alias /review) reviews your branch and uncommitted work for correctness bugs, takes an effort level, and can apply fixes with --fix or post to a pull request with --comment. /security-review checks the diff against the default branch for security risks such as injection, authorisation problems and data exposure.
• As a managed service: Anthropic’s Code Review↗ (opens in a new tab), in research preview for Team and Enterprise, runs several agents on Anthropic’s infrastructure, verifies candidate findings, and posts inline comments tagged Important, Nit or Pre-existing. Its check run always finishes neutral, so it never blocks a merge on its own. You tune it with REVIEW.md and CLAUDE.md.
• In your own CI: the Claude Code GitHub Action runs on your runners with a review workflow you control, and a separate security review action scans pull request diffs. Both actions are open source under the MIT licence; the security one warns that it is not hardened against prompt injection and should review trusted pull requests only.

CodeRabbit

• Where it runs: as an app on GitHub, GitLab, Azure DevOps and Bitbucket, with editor extensions for VS Code, Cursor and Windsurf and a command-line tool for reviews before you commit.
• What it comments on: a summary and walkthrough at the top of the pull request, then line comments with a category and a severity. Its documentation says it also runs a large set of third-party linters and security analysers in sandboxes and folds their results into the review.
• Configuration: a .coderabbit.yaml at the repository root, read from the branch under review, which CodeRabbit’s configuration guide↗ (opens in a new tab) says takes precedence over other settings sources. Review profiles control how talkative it is.
• Open source: the service is not. It is hosted by the vendor.

Cursor Bugbot

• Where it runs: on pull requests in GitHub, GitLab, Bitbucket and Azure DevOps, including self-hosted GitHub Enterprise Server and GitLab, according to the Bugbot documentation↗ (opens in a new tab).
• What it comments on: bugs, security issues and code quality, as inline comments with explanations and suggested fixes. Reviews run automatically on each update, or when someone comments bugbot run or cursor review.
• Configuration: .cursor/BUGBOT.md files. The root file always applies, plus any found above the changed files. An optional Autofix hands a finding to a Cursor cloud agent, which pushes a fix.
• Open source: not stated in its documentation; treat it as a hosted service.

Graphite

• Where it runs: on GitHub pull requests, as part of Graphite’s review tool. Its AI reviews documentation↗ (opens in a new tab) calls the reviewer Graphite Agent.
• What it comments on: logic errors, edge cases and performance problems, with the stated aim of real bugs rather than style.
• Configuration: custom rules written as prompts or pointing at files in your repository, comment exclusions, and files marked as generated in .gitattributes.
• Open source: no.

PR-Agent (open source)

• Where it runs: wherever you host it, as a GitHub Action, a self-hosted webhook service, a Docker container or from the command line, against GitHub, GitLab, Bitbucket, Azure DevOps and Gitea.
• What it comments on: /review for a review, /describe for a pull request description, /improve for suggested code changes, and /ask for questions about the diff.
• Configuration: a .pr_agent.toml in the repository, and any model you can reach through LiteLLM, including Claude, GPT, Gemini and models on Bedrock or Azure.
• Open source: yes, MIT. Qodo, which built it, has handed it to a community-maintained project↗ (opens in a new tab).

Tool                   Runs on                         Config in repo            Source
Copilot code review    GitHub, IDEs, CLI               custom instructions       closed
Claude Code            terminal, your CI, managed      CLAUDE.md, REVIEW.md      actions MIT
CodeRabbit             GitHub, GitLab, Azure, Bitbucket .coderabbit.yaml         closed
Cursor Bugbot          GitHub, GitLab, Bitbucket, Azure .cursor/BUGBOT.md        not stated
Graphite Agent         GitHub                          custom rules              closed
PR-Agent               anywhere you host it            .pr_agent.toml            MIT

How to choose

There is no best AI tool for code review in general, only the best fit for a team. Work through these in order and most teams are left with one or two candidates.

1. Where does your code live? A GitLab or Bitbucket team rules out the GitHub-only options at once.
2. Where may your code go? A hosted reviewer sends your diff, and often surrounding files, to the vendor. If that needs approval, prefer something that runs on your own runners with a model account you already have, such as the Claude Code GitHub Action or PR-Agent.
3. Can the rules live in the repository? A file such as REVIEW.md, .coderabbit.yaml or BUGBOT.md is reviewed like code and travels with the branch. Settings kept only in a web console drift.
4. How is noise controlled? Look for severity levels, a way to skip generated files and lock files, and a way to say “do not report what CI already catches”.
5. What can it do beyond commenting? Suggested changes are fine. Pushing fixes or approving are bigger grants. Know which switches turn those on, and who owns them.
6. Local as well as on the pull request? A review before you push costs nobody else’s attention. Claude Code, Copilot in the editor and CodeRabbit’s CLI all offer one.

Many teams end up with two layers: a security-focused pass and a general correctness pass, plus the ordinary linters and tests in CI. Several reviewers on one pull request is where noise starts, so add the second only when the first is tuned.

A checklist for reviewing an AI-reviewed pull request

The risk with a good AI reviewer is that people stop reading. These are the checks that remain the human’s job, whatever the bot said.

INTENT
[ ] I know which task this change is for, and the diff does that and no more
[ ] Behaviour matches what was asked, not just what the code says it does

THE AI COMMENTS
[ ] Every AI comment is resolved with a reason: fixed, or why it is not a bug
[ ] Suggested changes that were committed have been read, not just accepted
[ ] "No issues found" treated as no evidence either way

WHAT AI REVIEW TENDS TO MISS
[ ] Authorisation: each new route or query checks who is asking
[ ] Data: no secrets, personal data or tokens in code, logs or tests
[ ] New dependencies exist, are intended, and are pinned in the lockfile
[ ] Migrations are reversible, or the rollback plan is written down
[ ] Tests exercise the change; they were not just edited until green

THE GATE
[ ] CI passed on the latest commit
[ ] If an agent wrote this and an agent reviewed it, a person has now read it
[ ] I am the approval; the bot's comment is not

The security lines follow the failure classes in vibe coding security issues, which is where AI-written code most often goes wrong. For other kinds of output an assistant hands back, see verifying AI-generated work.

Where the findings go after the pull request

Comments fixed in the pull request need nothing more. The ones that are real but out of scope, such as a pre-existing bug the reviewer flagged in code you did not change, are the ones that get lost once the pull request merges. On a fenbs board each becomes a bug in To Do with the file and line in its note and a link to the comment, prioritised 1 to 10 like everything else. When someone fixes it, the task’s test status and notes record how it was checked, and a false alarm is closed as Won’t fix or Cannot reproduce with the reason. fenbs does not review code; it keeps the record of what the review found after the pull request has closed.