Blog

AI pull request review on GitHub: how to set it up

AI pull request review on GitHub: what it catches and misses, what 7 options cost as of October 2026, and a setup your team won't tune out.

Alex Mercer

AI pull request review is a bot reviewer on your GitHub pull requests: it reads the diff and the code around it, then leaves inline comments before a human gets there. Turning one on takes minutes, and the first two weeks decide whether your team still reads those comments a month later.

The reason to bother is volume. At the March 2026 launch of Anthropic's managed reviewer, Boris Cherny said code output per Anthropic engineer had climbed and review had become the bottleneck.

This blog belongs to cubic (cubic.dev), an AI code review tool, so weigh what we say about it accordingly.

Does AI pull request review work?

Yes, as a first pass. On Martian's Code Review Bench, developers acted on 67% to 79% of the comments from the tools in this guide, and none caught more than 60% of the fixes developers went on to make. Expect useful comments and plenty of misses, so treat the bot as the first reviewer, not the only one.

The numbers are from Martian's online tracker of real open-source PRs (last-month view, checked October 4, 2026). Martian calls the share of comments acted on precision and the share of fixes caught recall; F1 balances the two. On F1, cubic is #1 at 65.3%, and the other tools here score from 57.1% (Cursor) to 61.9% (Greptile, which has the board's highest precision, 79.0%).

The board moves daily, and several vendors have each reported #1 at different dates and in different modes. On Martian's offline benchmark (50 hard bugs, as labeled Sep 8, 2026), Qodo's Deep configuration leads cubic by 0.2 F2 points. Use the board for a shortlist, then test on your own PRs. Our AI code review tools page compares more of them; automated code review covers what to keep human.

AI code review on GitHub: the options and what they cost

Code review on GitHub with AI comes in three forms:

  • Copilot code review, built into GitHub's paid Copilot plans.

  • A review app on your organization, run by the vendor: CodeRabbit, Greptile, cubic, Cursor Bugbot or Anthropic's managed Claude Code Review.

  • An AI code review GitHub Action on your own runners, such as the Claude Code GitHub Action.

Prices are as of October 2026; each name links to its pricing or billing page.

Option

How a review starts

How it's billed

Code hosts

Copilot code review

Add Copilot under Reviewers, or run gh pr edit --add-reviewer @copilot. Automatic reviews come from a personal setting or a ruleset

Included in paid plans, from Pro at $10 a month. Each review uses AI credits ($0.25 to $5 at the default effort, per GitHub) plus Actions minutes on private repos

GitHub; Azure DevOps in preview

CodeRabbit

Automatically when a PR opens, then on new commits. Comment @coderabbitai review or @coderabbitai full review

Per developer who opens PRs: $24, $48 or $72 a month billed yearly ($30, $60, $90 monthly). Free for public repos

GitHub, GitLab, Bitbucket, Azure DevOps

Greptile

Automatically on PRs, skipping drafts by default. Comment @greptileai

$30 per seat a month with 50 credits each, then $1 a credit (a Base review is 1 credit). Free Starter: 50 credits a month, 1 developer

GitHub, GitLab, Bitbucket and others

cubic

Automatically on new PRs in the repos you pick, then on each push. Comment @cubic-dev-ai review this PR

Per developer: Team $40, Pro $99, Max $200 a month ($30, $79, $160 billed yearly), each seat adding to a pooled line allowance. Free plan: 20 reviews a month. Public repos free (fair use)

GitHub only

Cursor Bugbot

Automatically on every PR update by default. Comment cursor review or bugbot run

Usage-based since May 2026 (was $40 per seat a month). Cursor puts the average run at $1.00 to $1.50

GitHub, GitLab, Bitbucket, Azure DevOps (some in beta)

Claude Code Review (managed)

Per repo: once after the PR opens, after every push, or manual. Comment @claude review

Claude Team and Enterprise only, in research preview. Usage credits, averaging $15 to $25 a review

GitHub only

Claude Code GitHub Action

Whatever your workflow file sets, such as PR opened or updated. Also answers @claude mentions

Your Actions minutes plus API tokens or Claude subscription usage

GitHub only

For costs on a 10- or 50-developer team, see AI code review pricing. If you're working from a 2025 list, two entries are out of date: Google shut down the free Gemini Code Assist app for GitHub on July 17, 2026 (the enterprise version, in preview, continues), and Boost Security acquired Korbit in May 2026.

Which one is best for your team

  • Some of your code lives outside GitHub. cubic is GitHub only, so it's out. CodeRabbit and Bugbot also cover GitLab, Bitbucket and Azure DevOps (Bugbot partly in beta); Greptile covers GitLab and Bitbucket.

  • You already pay for Copilot. Try GitHub Copilot code review first, since there's nothing to install. Its reviews don't count toward required approvals unless an admin turns on Copilot approvals (in preview, off by default).

  • You want to own the prompt, the model and the runner. Use the Claude Code GitHub Action, and plan to maintain the workflow yourself.

  • You're on Claude Team or Enterprise and want a deep pass on the occasional big PR. Managed Code Review runs several agents plus a verification step and averages about 20 minutes, but at $15-25 a review it's the most expensive option here, so keep it in Manual mode for the few PRs that need it. It never approves or blocks a PR. More in Claude Code review.

  • You want team-specific rules, learning from feedback and a per-seat price. Pick a dedicated app: cubic, CodeRabbit or Greptile. For cubic against Copilot, see cubic vs GitHub Copilot.

How to set up AI pull request review, step by step

Install a review app on one or two busy repositories and open a pull request. Then teach the bot: reply to wrong comments, add one plain-English rule and ignore generated files. We use cubic below, with every label and command from cubic's docs; other review apps have similar settings under different names.

1. Install the cubic GitHub App

Sign up at cubic.dev with your GitHub account, and cubic walks you through installing its GitHub App. If you can't install apps on your organization, GitHub sends the request to an organization owner (GitHub's docs).

The 7-day trial needs no credit card and enables everyone on your team. After it, the free plan gives your organization 20 AI reviews a month, reset on the 1st.

2. Pick one or two repositories

GitHub asks whether the app gets All repositories or Only select repositories. Choose Only select repositories and pick one or two busy repos: enough PRs in a week to judge the reviews, without a flood of comments to answer.

3. Open a pull request

cubic reviews new pull requests in those repositories automatically. For a PR opened before the install, comment:

@cubic-dev-ai review this PR
@cubic-dev-ai review this PR
@cubic-dev-ai review this PR

GitHub doesn't list apps in its @-mention autocomplete, so type the handle in full. cubic skips draft PRs unless you turn on Review draft pull requests in its AI review settings.

4. Read the review

The review arrives as inline comments with explanations and suggested fixes, each labeled with a priority from P0 (most urgent) to P3. cubic can also write the PR description, a summary of what changed and why; if your team writes its own, turn on Skip when authors write descriptions in the Descriptions tab.

On Pro and Max, Fix with cubic (or the comment @cubic-dev-ai Please fix this) pushes a fix to your PR branch, and @cubic-dev-ai open a fix PR opens a separate PR instead.

5. Reply or react to teach it

This step makes the reviewer yours. Reply to any cubic comment, with no @-mention needed, and say what it got wrong and why:

This is a false positive. Next.js handles this automatically
This is a false positive. Next.js handles this automatically
This is a false positive. Next.js handles this automatically

A reply that states a rule for future PRs, such as "require pagination for endpoints that return lists", can become a learning; a note about this PR only, or a "thanks", doesn't. Thumbs up and down tell it what's useful and what's noise. A reply without @cubic-dev-ai never changes code; edits need the tag or the Fix with cubic button.

Learnings stay within your team. You can edit or delete them under AI review → Learnings, and a weekly cleanup merges duplicates and archives stale ones.

6. Add one custom rule in plain English

Rules are what you tell cubic up front, and its docs call them custom agents. Open the Rules library, click Add rule, and give it a name, a plain-English description and, if you want, path filters. For example:

  • Name: Queue analytics events

  • Description: In API handlers, flag direct calls to analytics.track(). Send events through queueAnalyticsEvent() instead, so a slow analytics service can't time out the request.

  • Include: src/api/**

Put the reason in the rule, and spend rules on what linters can't check, such as business logic and team conventions. The standard limit is 5 active rules per repository, with more on Pro and Max. To version rules with your code, define them in cubic.yaml at the repository root:

version: 1
reviews:
  custom_rules:
    - name: Queue analytics events
      description: In API handlers, flag direct calls to analytics.track(). Send events through queueAnalyticsEvent() so a slow analytics service can't time out the request.
      include:
        - src/api/*

version: 1
reviews:
  custom_rules:
    - name: Queue analytics events
      description: In API handlers, flag direct calls to analytics.track(). Send events through queueAnalyticsEvent() so a slow analytics service can't time out the request.
      include:
        - src/api/*

version: 1
reviews:
  custom_rules:
    - name: Queue analytics events
      description: In API handlers, flag direct calls to analytics.track(). Send events through queueAnalyticsEvent() so a slow analytics service can't time out the request.
      include:
        - src/api/*

Other tools take review instructions from files too: .github/copilot-instructions.md for Copilot, .cursor/BUGBOT.md for Bugbot, REVIEW.md for Claude's managed Code Review and .greptile/ for Greptile.

7. Ignore generated files

Generated code and build output don't need review, and comments on them are noise. Mark generated files in .gitattributes; GitHub collapses them in the PR view, and cubic skips them:

*.pb.go linguist-generated=true
generated/* linguist-generated=true
*.pb.go linguist-generated=true
generated/* linguist-generated=true
*.pb.go linguist-generated=true
generated/* linguist-generated=true

Or add file globs under Ignore patterns in AI review settings, or in cubic.yaml:

version: 1
reviews:
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'
version: 1
reviews:
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'
version: 1
reviews:
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'

cubic reads cubic.yaml from the default branch only, so a change takes effect once you merge it.

How to keep AI PR review from getting noisy

Automated pull request review fails in a predictable way: too many comments that don't matter, until people scroll past the bot and miss the one that did. Five habits prevent most of it:

  • Lower the sensitivity where it's too picky. reviews.sensitivity in cubic.yaml takes low, medium or high.

  • Review each change once. Keep incremental reviews and auto-resolve on, so each push gets comments on new issues only, and fixed threads close.

  • Skip work in progress. Leave draft reviews off, and skip PRs by label, branch or title: a skip-review or wip label, or coding-agent branches such as agent/** under reviews.ignore.head_branches. Comment @cubic-dev-ai review when one is ready.

  • Prune rules that don't land. cubic's analytics show how many issues each custom rule flagged and how many got fixed. Rewrite or delete the ones nobody fixes.

  • Run one AI reviewer per repo. Two bots on one PR double the comments, and you can't tell which one is earning its place.

Check what your tool does with replies. GitHub's docs say Copilot can't see them and may repeat comments you dismissed when it re-reviews, and Anthropic's managed Code Review doesn't respond to them. Bugbot learns rules from reactions and replies, Greptile learns from thumbs reactions over two to three weeks, and CodeRabbit has a Learnings feature. If your team pushes back in threads, pick a tool that reads them.

How to roll out an AI reviewer to your team

Pull request review automation sticks when the team knows what the bot is for and how to talk back to it. The order we'd follow:

  1. Start with one team that wants it, and widen one repo at a time once that team fixes more comments than it dismisses (organization Settings → GitHub Apps → Configure).

  2. Set the ground rules. AI comments get a teammate's treatment: fix, reply or dismiss with a reason (how to review a pull request on GitHub covers the mechanics). They don't replace the human approval.

  3. Give it context before you judge it. cubic reads files such as README.md, AGENTS.md, CLAUDE.md and .cursorrules on its own, so keep them current. Pick your most experienced reviewers during onboarding, or list up to five under reviews.senior_reviewers, and cubic learns from their past PR comments. Then turn your last few incidents into rules; each is a mistake your team already paid for.

  4. Move settings into code. Export them as cubic.yaml from the AI review settings page and commit the file, so setting changes get a code review; a cubic-config repository holds organization-wide defaults.

  5. Sort out seats before the trial ends. Everyone is enabled during the trial, so before you upgrade, turn off the Seat switch in Settings → Members for anyone who doesn't need one. Pro and Max require a seat for every developer with at least 15 PRs in the last 30 days.

  6. Turn on auto-approval last, if at all. Set Behavior to Shadow first: cubic keeps commenting and shows which PRs it would have approved. Use the Low-risk only policy, block paths such as migrations, infrastructure and auth, and switch to Live when the shadow results match your reviewers' calls. GitHub branch protection still applies, and auto-approval is available on Team, Pro and Max.

How to measure whether AI review is working

Comment count is the wrong number. Track these instead, and compare trends over at least 30 days:

Metric

What it tells you

Where to find it in cubic

Share of comments acted on

Whether the comments are worth fixing

Issues fixed after comment, AI Review tab

Downvote rate

How much of it reads as noise (lower is better)

Downvote rate, AI Review tab

Review cycles until merge

Whether problems get caught in the first round

Average review cycles until merge, Delivery and effectiveness tab

Time to merge

Whether PRs move faster

Average time to merge against your pre-cubic baseline, AI Review tab

Bugs that reach production

What the reviewer missed

Your incident and revert history

Cost per merged PR

What each review costs on usage-billed tools

Your vendor's bill

The first row is what Martian's benchmark calls precision, and you can measure it for any tool: take last week's bot comments and mark each one fixed, discussed or ignored. Treat time-to-merge changes as directional, since PR size and team load move it too. In cubic, review analytics come with Team, Pro and Max, and Pro and Max add an Analytics API.

Install a reviewer on one repo this week, and answer every comment it gets wrong.

If you want to try that with cubic, start the 7-day trial. It needs no credit card. After it ends, the free plan covers 20 reviews a month, and public repositories are free.

Table of contents