Opens in a new tab
AIOps SRE
Search

Code review

CodeRabbit

Official website

A code review becomes useful when a comment helps you see something you missed. CodeRabbit adds that kind of feedback to pull requests, where your team can discuss it beside the changed code. It also offers editor and terminal tools, but this guide begins with the pull request, or PR, you already need reviewed. A small change to retry behavior gives us an illustrative question to follow: could another attempt create a second ticket after the first response is lost? From there, you can examine whether a finding leads to a meaningful fix.

Ready guideDocumentation checked
In this guide 7 sections

01Fit

Is it for you?

When it helps

  • Adding another review pass to a pull request without moving the discussion away from the code
  • Giving reviewers specific guidance for areas such as API clients or database migrations

When to choose something else

  • Replacing tests, branch protections or the person responsible for deciding whether a change can merge
  • Private repositories your organization has not approved for the service to process

02Requirements

Before you start

  • An account on a supported Git platform with permission to install the repository integration
  • A repository whose data may be processed under your organization’s policy
  • Someone able to investigate the comments, with working checks to help determine whether a suspected problem is real

Cost and access

Paid plans are priced per developer and have feature and review limits. CodeRabbit also offers a trial and free reviews for qualifying public repositories; other products may have separate usage billing. Before connecting the team, check which reviews count toward the allowance and what the current plan includes.

Check current access and pricing

03Setup

Set it up

  1. Connect the repository’s Git platform

    The quickstart covers GitHub, GitLab, Azure DevOps and supported Bitbucket deployments. Follow the instructions for your provider using an account that can authorize the integration for the intended repository.

    Official instructions

  2. Choose a repository for the first reviews

    Read the integration’s permissions and data policy before selecting a repository. Keep the existing branch protections and human-review requirements. You will then be able to see what CodeRabbit contributes to the review process the team already uses.

    Official instructions

  3. Explain the change in the pull request

    Open a small PR with a description of the behavior you intend and the test results you have. This gives the review a concrete point of comparison. The PR integration handles this workflow; you do not need to install a local command-line tool for it.

    Official instructions

04Using CodeRabbit

Could this retry create a second ticket?

This synthetic PR introduces the unsafe retry wrapper from the starter. Its happy-path test passes because the failure only appears when the service creates the ticket but loses the response. Ask CodeRabbit to explain that execution path, then decide whether its finding is supported by a test.

Included example files

A small support-service project

Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.

  • retry.mjs
  • retry.test.mjs
  • checks/retry-contract.test.mjs
Download starter ZIP
  1. Use a disposable repository that you are authorized to connect to CodeRabbit. Establish a base commit containing the single-send comparison implementation below and the happy-path test. On a separate branch, replace that function with the starter’s unsafe retry.mjs, then open a small PR explaining the change. The PR now contains the defect rather than hiding it in unchanged base code.
  2. Keep the supplied contract test out of the proposed implementation changes until you have read the initial review. Post the request as a PR comment if you need a focused discussion. No finding is guaranteed: CodeRabbit may miss the issue or discuss something else. Bring the suspected execution path back to the source and run the contract locally.
  3. Replace the unsafe retry with the single-send behavior or another design whose safety you can justify. Preserve the public function name, add the regression test, and run baseline plus contract checks. Re-read the review against the updated revision and retain normal human approval and branch protections.
Baseline and ambiguous-write contract
node --test retry.test.mjs checks/retry-contract.test.mjs
What to ask
@coderabbitai This PR adds a retry around a ticket-creation request. The service can perform the write and then lose the response. In retry.mjs, could the second send create another ticket? Show a concrete execution path and suggest a test that observes the side effect. Do not assume an idempotency guarantee that is not present in this repository.

The artifact you are working toward

A PR with a reproduced finding and a checked revision

The review record should link the comment, reproducing test and fix. Use this single-send version as the base before proposing the intentionally unsafe retry; it is an illustrative reference implementation, not CodeRabbit output.

Illustrative result to compare
export async function submitWithRetry(send) {
  return send();
}

What the example should show

  • The PR diff actually introduces the retry under review. Reviewing an unchanged file is a different question.
  • The fixture records the first side effect before throwing; the test exposes a duplicate write without contacting a real service.
  • After the fix, the original rejection reaches the caller and only one write is attempted.
No automatic review appears

Check the repository integration, review configuration and current allowance. The official command reference documents @coderabbitai review; do not repeatedly request reviews without checking the cause.

A comment sounds serious but has no reachable example

Ask for the input and branch that produce the issue. If the repository’s actual guarantees rule it out, explain those guarantees in the review rather than applying a speculative fix.

What you can take from this example

The useful outcome is a defect you can demonstrate or a concern you can confidently dismiss. Count time spent investigating incorrect suggestions alongside the findings that help; more comments alone do not make the review better.

The included baseline tests and evaluation script were checked locally. The deliberately failing contract tests demonstrate the defects in the starter. No AI product was installed or run for these examples; model responses and reviews will vary.

05Next steps

Go deeper

Tell the reviewer what matters in different files

A database migration raises different questions from an API client. Path-specific instructions let you explain those concerns for the relevant files. Path filters do something else: they exclude files from review. The full guide includes a configuration example so you can add useful context without accidentally hiding code you wanted examined.

Read the guidance

Reviewing the fix as well as the original change

After you push follow-up commits, an incremental review looks at the new changes. A full review makes another pass over the entire change. The command reference explains how to request each; both consume review allowance when they run. Choose according to what is still unclear, such as whether the fix interacts with code from an earlier commit.

Read the guidance

More from AIOpsSRE

Walkthroughs that use CodeRabbit

Take an unsafe retry through a complete PR review5 steps

06Alternatives

Other options to consider

Codex
Its local review workflow is useful to consider when you want feedback before opening the PR
Your existing human review and CI
Use the team’s existing review and continuous-integration checks as the comparison, including what they catch and how much time they take

07Evidence and scope

Sources and review

Product behavior is based on the linked official documentation. This walkthrough uses an authored synthetic starter project. Its baseline tests and local checker were checked; no installation, model response or product performance was independently tested for this guide.

Documentation checked

Back to all tool guides