Getting Code Rabbit Up and Running

AI coding tools have made building software ridiculously fast. One engineer is using Cursor, another is using Claude Code, somebody else is using GitHub Copilot, and suddenly your team is shipping way more code than before. But that creates a new bottleneck. Writing code is easy now. Reviewing it isn't.

When all this AI-generated code starts landing in pull requests, somebody still needs to verify that it actually works, doesn’t break anything, and follows your team standards. That’s where things start slowing down. That’s where Code Rabbit comes in.

Code Rabbit is an AI code reviewer that analyzes your pull requests, catches potential issues, and even suggests fixes before code gets merged into production. Instead of asking a human reviewer to manually inspect hundreds of lines of AI-generated code, it performs that first pass automatically and lets the team focus on the comments that actually matter.

Getting Code Rabbit Up and Running

Setting up Code Rabbit on a repository takes almost no time. I’m using a demo project here that already has a few pull requests and some intentionally questionable code so we can actually see what Code Rabbit does. To get started, head over to the Code Rabbit website and sign in with your Git provider. It works with GitHub, GitLab, Bitbucket, and Azure DevOps. For this demo, I’m using GitHub.

Once you’ve signed in, installing it is pretty straightforward. Click add repositories, select the ones you want Code Rabbit to access, and approve the permissions. That’s basically it. There isn’t some huge onboarding process or a bunch of configuration you have to do before getting value out of it.

The interesting thing here is that Code Rabbit doesn’t replace your existing workflow. Your developers can still use Cursor, Claude Code, or whatever coding tools they prefer. Code Rabbit simply sits in the review stage and acts as another set of eyes before code gets merged.

What an AI Review Looks Like in Practice

Let’s see what that looks like in practice. I already have a pull request open. This PR adds a new user registration flow and on the surface everything actually looks fine. The code compiles, tests pass, and if you’re moving quickly, it’s probably the kind of PR that gets approved pretty fast.

But the reality with AI-generated code is that a lot of issues aren’t syntax errors. There are edge cases, security problems, missing validations, or architectural issues that are easy to miss during review. As soon as I open this pull request, Code Rabbit starts analyzing the changes automatically. You’ll notice that it doesn’t just leave a generic summary. It actually goes through the code and starts leaving comments on specific lines explaining why something could become a problem.

For example, maybe we’re missing a terminate failed login check here or perhaps we invalidated the user session incorrectly. These are exactly the kinds of issues that often make it through code review because everybody assumes someone else already looked at it. And this is really the problem Code Rabbit is trying to solve. Instead of asking a human reviewer to manually inspect hundreds of lines of AI-generated code, it performs that first pass automatically and lets the team focus on the comments that actually matter.

One thing I like here is that Code Rabbit isn’t just saying, “Hey, something might be wrong.” It actually explains the potential impact. So maybe a null value could cause a runtime exception or this endpoint could return an unexpected response under certain conditions. That extra context is important because code reviews aren’t really about finding syntax errors. They’re about understanding what could break once this code reaches production.

In some cases, Code Rabbit will also generate a suggested fix for you. You can see the autofix dropdown right in the comment. Check the first option and with one click, you can apply the change directly to the pull request. So instead of copying code from a comment, making the edit manually, and pushing another commit, the fix is already prepared for you.

Atlas: A Better Way to Navigate Large Reviews

I also want to point out Atlas, which is Code Rabbit’s new review interface. When a review is made, you can access it by clicking “review change stack.” It organizes related changes into one overview. So you can review the change layer by layer instead of jumping between files. As you go through the review, you can inspect the affected code, understand why a suggestion was made, and navigate the changes without constantly losing context. It makes larger pull requests much easier to follow, especially when AI has generated code across multiple parts of the project. This becomes surprisingly useful when you’re dealing with lots of small issues across a large pull request because those little review cycles can add up pretty quickly.

Another thing you’ll notice is that Code Rabbit remembers your interactions over time. If your team consistently accepts certain types of suggestions or ignores others, it starts building learnings around your codebase and adapts its reviews accordingly. That’s actually pretty important because every engineering team has different standards. Some teams care a lot about naming conventions, some care about security, and others are very strict about architecture boundaries. But where things get more interesting is when you start customizing how Code Rabbit reviews your code.

Enforcing Team Standards with Custom Rules

Let’s customize Code Rabbit a little bit. Inside the root of the repository, I’m going to create a .rabbit.ai file. This is where you configure how Code Rabbit reviews your code. I already have one prepared, so let me paste it in here. I’ve enabled automatic reviews and some premerge checks. But the interesting part is the section that lets us create custom rules for our team.

First I’ll add a rules folder, then make a new file containing the rules. For example, let’s say nobody on the team is allowed to run raw database queries directly. We only want developers using our ORM or repository layer. I’m going to create a rule that looks for raw database query calls. Now I’ll commit this configuration and open another pull request. Inside this PR, I have a file that intentionally uses db.query directly. A few moments later, you can see Code Rabbit leaves a comment immediately explaining that this has an error on the code. Plus, it violates our team’s database policy.

The nice thing here is that we’re not relying on a human reviewer to remember every engineering rule anymore. The policy just becomes part of the review process. You can do the same thing for all kinds of things. For example, you can add a premerge check that blocks a PR if a breaking API change isn’t documented or create a rule that warns developers if they accidentally log secrets or API keys. As your team gets bigger and more people start using AI coding tools, these kinds of checks become really useful.

Review Locally Before You Push

One thing I don’t like about traditional code reviews is finding out about issues only after I’ve already pushed my code and opened a pull request. Code Rabbit actually has a CLI for this. So let’s take a look. For now, Code Rabbit works best on macOS, Linux, and Windows WSL. I’m using WSL, so I’ll copy the install code and paste it in. Once that’s done, Code Rabbit CLI will ask you to sign in. Simply proceed by pressing Y. After that, you’re already signed in. You can check the status with code-rabbit status to see if you’re logged in or not.

Now that I’m connected, I’ll go to the Git directory where the project is sitting. Let’s say I’m working on a feature and I haven’t even committed anything yet. I can run cr review. Code Rabbit will review my local changes and give me feedback before I ever push the code to GitHub. You can see here it’s pointing out a couple of potential issues in my changes. Code Rabbit points out even a major error like this: I forgot to put the JSON with an argument and an error handling for an empty result. I can fix those issues right now since Code Rabbit also gives you a proposed fix. Then I rerun the command and keep iterating locally without needing to make a pull request.

This is honestly pretty nice because it shifts review much earlier in the development process. I can catch a lot of these issues before anyone else even sees the code. And if you’re using coding agents like Claude Code or Cursor, you can actually run those agents to generate code, run Code Rabbit locally, fix the issues it finds, and repeat the process until the review comes back clean. So instead of just using AI to write code, you’re also using AI to verify that code before it gets merged into your repository.

Cross-Repository Checks and the Full Workflow

Let’s look at one more feature because this is something that’s really useful if you’re working with multiple services. In this example, I have a front-end repository and a backend API repository. I’m going to add a linked repository section to my .code-rabbit.yaml file and point it to the backend repository. Now, let’s open a pull request in the front end. I’ve intentionally changed the API contract here. The front end expects one field, but the backend now returns something different.

Normally, this kind of issue is pretty easy to miss because the changes live in completely different repositories. A reviewer looking only at this pull request may have no idea that another service depends on this endpoint. But once Code Rabbit finishes its analysis, it can actually flag these cross-repository inconsistencies and tell us that this change may break another part of the system. This becomes incredibly useful once your architecture starts growing because most production issues don’t happen inside a single file. They happen at the boundaries between services.

So the workflow I like ends up looking something like this. I use my coding agent of choice (I’m using Cursor here) to generate the initial implementation. Then I run Code Rabbit locally to catch issues before I commit anything. I open a pull request, let Code Rabbit perform a full review, apply any one-click fixes that make sense, and finally let my team review the code with all of that extra context already available. The result is that developers can still move quickly with AI-generated code, but the review process doesn’t become the bottleneck.

Key Takeaways

  • AI coding tools speed up code generation, but they shift the bottleneck to code review. Code Rabbit automates that first review pass.
  • It catches edge cases, security flaws, and missing validations that are easy to overlook when reviewing AI-generated code.
  • The autofix feature lets you apply suggested fixes directly to the PR with one click, saving manual editing time.
  • Atlas provides a layered review interface that makes navigating large, multi-file changes much easier.
  • Custom rules in the .rabbit.ai file let you enforce team-specific policies like banning raw database queries or flagging leaked secrets.
  • The CLI enables local reviews before you even commit, shifting feedback to the earliest possible moment.
  • Cross-repository checks catch breaking API changes between services, which are a common source of production issues.
  • The ideal workflow: generate code with your AI tool, review locally with Code Rabbit, fix issues, open a PR, apply one-click fixes, and let the team review with full context.

That’s why I think tools like Code Rabbit are becoming increasingly useful. It gives you an automated first pass on your pull requests, catches potential issues early, and helps your team move faster without lowering the quality bar. If you want to try it out yourself, you can connect it to your repositories and see how it fits into your own development workflow.