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

AI pull request review checks a code change before it merges and posts findings on the pull request. A useful AI reviewer reads the diff with relevant repository context, explains a concrete failure, and points to the code that needs attention. It can give a human reviewer an earlier first pass on bugs, security issues and team conventions.

To set up AI code review on GitHub, connect a reviewer to one repository, open a PR, add your team's review rules, and check whether its comments lead to useful fixes. Keep tests and your existing approval requirements in place while you evaluate it.

We build cubic. The walkthrough below uses cubic; the evaluation checklist applies to any AI pull request reviewer. Our AI code review guide explains the broader category.

What should an AI pull request reviewer catch?

Look for findings tied to behavior, with enough evidence for someone to check them. "This could be cleaner" is less useful than an explanation of which request fails, why it fails and where the fix belongs.

Use examples like these when evaluating a reviewer on your own code. They illustrate the kinds of problems to test for, rather than a promise that a tool will catch every one.

Keep formatters, type checks, tests and static analysis in CI. AI review can miss a real issue or invent one. A clean review does not establish that the code is correct, and an accepted suggestion does not establish that every part of the suggestion was necessary.

Choose how automated pull request review runs

Start with how the reviewer fits your GitHub workflow. Then evaluate its findings, configuration and cost on the repositories you intend to use.

A subscription price alone does not tell you the cost of reviewing your team's code. Include usage allowances, reruns, larger changes and the time engineers spend checking comments. Compare the bill over the same set of PRs rather than assuming each vendor counts a review the same way.

How to set up AI pull request review on GitHub

Use one active repository for the pilot. Pick a team willing to explain wrong findings and enough ordinary PRs to see how the reviewer behaves beyond a demonstration.

1. Connect the cubic GitHub App

Sign up for cubic with GitHub and choose the organization that owns the repository. Select Only select repositories for the pilot and review the requested permissions. If you cannot install the app yourself, your organization's policy may require an owner to approve the request; GitHub's installation guide explains those permissions and roles.

The cubic quickstart walks through the connection and first review. The trial lasts seven days and requires no credit card.

2. Trigger the first review

Open a new pull request in the connected repository. cubic starts reviewing new PRs automatically. To review an existing PR, post:

@cubic-dev-ai review this PR

@cubic-dev-ai review this PR

@cubic-dev-ai review this PR

Read the inline findings and check the explanation against the actual code path. Confirm the failure before applying a suggested fix. Draft PRs are skipped unless draft review is enabled in your repository's AI review settings.

3. Give the reviewer a specific team rule

Tell the reviewer what your team wants it to flag. Broad instructions such as "follow best practices" leave too much room for interpretation. A useful rule names the code it applies to, the failure to prevent and the preferred pattern.

For example, a multi-tenant application might use this rule:

In API handlers that load tenant-owned records, flag queries that use only the record ID without checking the authenticated tenant. Use the shared tenant-scoped query helper. Public catalog endpoints are exempt.

In cubic, create that check as a custom agent and limit it to the relevant paths. Use the agents library for other starting points. Turn repeated review comments from your senior engineers into explicit rules; our code review standards page covers how to define them.

4. Version review settings with the repository

Once the pilot settings are useful, commit a cubic.yaml configuration at the repository root. This example keeps incremental reviews on, skips drafts and generated output, and leaves auto-approval disabled:

version: 1
reviews:
  enabled: true
  sensitivity: medium
  incremental_commits: true
  check_drafts: false
  resolve_threads_when_addressed: true
  auto_approve_behavior: disabled
  auto_approve: disabled
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'
    pr_labels:
      - 'skip-review'

version: 1
reviews:
  enabled: true
  sensitivity: medium
  incremental_commits: true
  check_drafts: false
  resolve_threads_when_addressed: true
  auto_approve_behavior: disabled
  auto_approve: disabled
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'
    pr_labels:
      - 'skip-review'

version: 1
reviews:
  enabled: true
  sensitivity: medium
  incremental_commits: true
  check_drafts: false
  resolve_threads_when_addressed: true
  auto_approve_behavior: disabled
  auto_approve: disabled
  ignore:
    files:
      - 'dist/**'
      - 'generated/**'
    pr_labels:
      - 'skip-review'

cubic reads this configuration from the default branch, so merge it before checking its effect on later reviews. Repository settings override organization defaults field by field. If you need shared defaults across repositories, use a cubic-config repository.

5. Respond to findings and check the next push

Fix a valid issue, explain a false positive, or record why the finding is out of scope. Make the reason concrete. "This route is intentionally public; authentication is required only for writes" is useful feedback.

cubic can turn feedback that states a reusable rule into a team learning. One-off requests and replies such as "thanks" do not become rules. Review the resulting guidance under AI review → Learnings; the memory and learning documentation explains how to edit it.

If your team uses Fix with cubic, inspect the resulting change and run the relevant checks before merging. An AI-generated fix needs review too.

Make the human review easier in cubic

Finding bugs is one part of review. A person still needs to understand what the PR changes and whether that behavior is right.

Open the same PR in cubic by replacing github.com with cubic.dev in its URL, or find it in your pull request inbox. The cubic review page groups related files, explains each group and places the core change first.

• Follow the change across files. Read an endpoint, its caller and its tests together.

• Ask for a walkthrough. Enter tour this PR in AI chat, then ask questions about the code that needs your judgment.

• Review the next push. Use Since your last review to focus on changes made after your earlier pass.

• Submit the review. Comments, approvals and requests for changes sync back to GitHub.

Keep large work in reviewable pieces. If one change depends on another, our stacked pull requests guide explains how to split the work while keeping the branch dependencies clear.

Keep AI PR review useful instead of noisy

Treat configuration as part of the pilot. When engineers dismiss a finding, find out whether the problem was missing context, a bad rule or an incorrect conclusion.

• Leave drafts out of the first rollout. Review work when the author is ready for feedback.

• Exclude generated output deliberately. Keep source files and the generator under review. Avoid blanket exclusions for tests, migrations or security-sensitive files.

• Keep incremental reviews enabled. cubic checks new commits and posts new issues rather than repeating earlier findings. Auto-resolve can close threads when it detects a fix; inspect important fixes yourself.

• Tighten rules that produce weak findings. Add a path, an exception or a concrete failure condition before adding more rules.

• Evaluate one reviewer at a time. This makes it easier to attribute useful findings and avoid duplicate comments during the pilot.

For a migration, authorization change or payment flow, request a deeper pass with @cubic-dev-ai ultrareview. Ultrareview performs multi-pass analysis and is available on paid and trial plans. It uses the reviewed-lines allowance at three times the standard rate, so include that in the pilot's usage budget.

Measure useful fixes, missed issues and review time

Set a baseline before installation and keep the pilot's repository, period and PR mix visible. Count comments only as a workload measure. The outcomes matter more.

In cubic's AI review analytics, Issues fixed tracks findings that a later commit appears to resolve. That automated check can be wrong: open the issue and inspect its fix commit to confirm. Time to merge is a median from PR opening to merge, including drafts and weekends. A faster median alone does not prove that AI review caused the improvement.

A fix rate is an adoption signal, not a complete accuracy score. It does not tell you how many real bugs were missed. Use the sampling above alongside our pull request metrics guide to decide whether to expand the rollout.

Keep approval policy separate from review comments

Start with AI comments and your existing human approvals. Keep CI, required reviewers and code-owner requirements configured through GitHub branch protection or your organization's rulesets.

If you later want automatic approval for narrowly defined changes, test cubic's auto-approval in Shadow mode first. It shows which PRs would be approved without submitting real approvals. Choose Low-risk only or a specific custom policy, exclude sensitive paths, and compare the results with your reviewers' decisions before enabling Live.

FAQ

What is AI pull request review?

It is an automated review of a proposed code change, usually delivered as findings on the pull request. Its usefulness depends on repository context, specific review rules and whether the findings identify problems engineers need to fix.

Can I use AI to review a GitHub pull request?

Yes. Connect a review app such as cubic to the repository, evaluate GitHub's Copilot code review, or maintain your own review workflow. With cubic connected, open a new PR or comment @cubic-dev-ai review this PR on an existing one.

How much does AI pull request review cost?

Billing can depend on seats, credits, reviewed lines or model usage. Estimate the cost using your PR volume and change sizes, including reruns. Check cubic's current pricing for its free allowance, paid plans and usage limits.

Does AI review replace tests or security scanning?

No. Tests check specified behavior, static tools enforce defined checks, and AI review can investigate contextual problems. Keep those checks together and have a person evaluate findings and important changes.

Can AI review code written by another AI?

Yes, but the review still needs independent verification. Check the failure the reviewer describes, inspect any generated fix, and run tests. Using an AI author and an AI reviewer does not establish that the change is correct.

Start a cubic trial on one repository. Use the next set of real pull requests to decide which findings help, which rules need work and whether your team wants to expand it.