Overview

CodeRabbit is designed to review code based on the standards and instructions defined in your repository. However, we see cases where users report that “CodeRabbit missed code that violates our standards.”

In most of these situations, the root cause is not a limitation of CodeRabbit — it is ambiguous, conflicting, or loosely written review instructions.

Many guideline documents were originally written for humans, long before AI-powered reviewers became part of the workflow. Human reviewers can infer intent, resolve ambiguity, and apply contextual judgment. Large language models, however, rely heavily on clarity, specificity, and internal consistency.

Why This Happens

Common issues in guidelines:

• Vague wording (“clean”, “simple”, “proper”)

• No measurable criteria

• Conflicting rules

• Undefined scope (no path or context specified)

• Implicit assumptions about architecture

When rules are subjective or unclear, CodeRabbit must infer intent — which leads to inconsistent enforcement.

How to Write Effective Guidelines/Instructions

Follow these principles when writing review instructions.

1. Be Specific and Measurable

Avoid:

Keep functions small.

Prefer:

Functions must not exceed 40 lines of executable code (excluding comments).

2. Define Scope Clearly

Always specify where a rule applies.

Avoid:

Use dependency injection.

Prefer:

Files under /src/services/** must receive dependencies via constructor injection. Direct instantiation using new is not allowed.

3. Avoid Subjective Language

Replace words such as:

• clean,

• simple,

• maintainable, or

• proper

with observable, enforceable conditions.

4. Remove Conflicts

Ensure no rule contradicts another. If two rules compete, CodeRabbit cannot reliably determine priority.

Examples: Bad versus Good Review Instructions

Bad

Ensure code is clean and maintainable.

Avoid large functions.

Follow best practices for error handling.

Use meaningful variable names.

Problems

• “Clean” and “maintainable” are undefined

• “Large” is subjective

• “Best practices” are unspecified

• “Meaningful” has no measurable criteria

 Good

Function Size

Functions must not exceed 40 lines of executable code.

Error Handling

All async external API calls must be wrapped in try/catch.

Errors must be logged using logger.error() before rethrowing.

Naming

Variable names must be at least 3 characters long.

Single-letter variables are only allowed in short loops (≤5 lines).

Quick Test for Effective CodeRabbit Guidelines

• Would two engineers interpret this rule the same way?
  If not, it’s too subjective.

• Is every rule measurable or observable?
  If you can’t clearly detect a violation, neither can CodeRabbit.

• Is the scope explicitly defined (path, layer, file type)?
  If it doesn’t say where it applies, it’s incomplete.

• Do any two rules contradict or weaken each other?
  If yes, resolve priority or remove one.

• Does the rule avoid vague words like “clean”, “simple”, “proper”?
  If not, rewrite using concrete criteria.

If a rule fails even one of these checks, it likely needs refinement.