DEV Community: Dave Barron

Best AI Code Review Tools by False Positive Rate (2026): What the Benchmarks Actually Show

Dave Barron — Wed, 28 Oct 2026 22:02:12 +0000

I design review pipelines, and every vendor I talk to quotes a false positive number. None of them agree, because each 2026 benchmark defines a false positive its own way. I read six benchmarks and five tools' docs in October 2026 to learn what the numbers mean and which tools act on noise.

TL;DR

Benchmarks disagree because each one defines "wrong" differently. In one 2026 study, developers rejected most of a widely used reviewer's comments, with false positives a main reason (arXiv 2607.03316, July 2026), while CR-Bench counts even correct comments against precision (arXiv 2603.11078, March 2026).
Precision without recall hides missed bugs. In Qodo's own benchmark, Precise mode reached 74.5% precision at 44.2% recall, and Exhaustive mode raised recall to 56.7% for teams that want more bugs caught (Qodo, February 4, 2026).
The honest test is a two-week trial on your own repos. Count acted-on findings, dismissals with reasons and bugs found later, and date every number.
Qodo is my #1 because it lets you pick the precision and recall tradeoff and records a reason with every dismissal. Relevance ranks findings by how your team handled similar ones. Pick Qodo when your team wants to choose its own noise level and prove it with data.

The 5 Best AI Code Review Tools for Low False Positives

Qodo: best for tuning precision and separating noise from intent
CodeRabbit: best for teams that want a quiet review profile and chat learnings
Greptile: best for teams that tune strictness per directory
cubic: best for GitHub teams that calibrate with reactions
GitHub Copilot code review: best for teams that want lighter or deeper review on GitHub.com

Tool	Best for	Main noise control	Learns from dismissed findings	Git platforms
Qodo	Tuning precision and separating noise from intent	Precision preset, severity thresholds, Relevance (GitHub and GitLab)	Dismiss reasons; Relevance from past PR outcomes on GitHub and GitLab; deactivation of rarely fixed rules	GitHub, GitLab, Bitbucket, Azure DevOps, Gerrit
CodeRabbit	A quiet review profile and chat learnings	Review profile: quiet, chill or assertive	Learnings from chat preferences	GitHub, GitLab, Azure DevOps, Bitbucket
Greptile	Tuning strictness per directory	Strictness 1 to 3, comment types, ignore patterns	Learns from reactions and addressed comments	GitHub, GitLab, Bitbucket, Cursor Origin
cubic	GitHub teams that calibrate with reactions	Thumbs up or down, merge confidence score	Learns from reactions and replies	GitHub
GitHub Copilot code review	Lighter or deeper review on GitHub.com	Review effort levels: Lite, Balanced, Max	Instruction files and Copilot Memory	GitHub.com, Azure DevOps

Why AI Code Review Benchmarks Disagree on False Positives

A false positive rate in code review is the share of comments that flag a problem that isn't there. Benchmarks agree on that and disagree on how to decide "isn't there". Six 2026 benchmarks show the spread, using four kinds of judge, which are one known bug, human comments, golden comments and developer fixes.

CR-Bench Counts One Known Bug Per PR

CR-Bench, from Nutanix researchers in March 2026, builds each test from a single known bug. Any other comment counts against precision, even a correct one about a different issue (arXiv 2603.11078, March 2026). The one-known-bug judge understates precision by design, so a low CR-Bench score says little about noise on your repos.

SWE-PRBench Uses Human Comments as Truth

SWE-PRBench uses the second kind of judge, the comments human reviewers left. Each AI comment is labeled confirmed, plausible or fabricated, and models caught only a minority of the issues humans flagged (arXiv 2603.26130, March 2026). A human-comment judge ignores real issues the humans missed, so it can count a correct comment as noise.

Martian Code Review Bench Uses Golden Comments and Developer Fixes

Martian, a model-routing lab that says it doesn't sell coding tools, uses two judges at once, curated golden comments offline and developer fixes online. Curated answer keys miss real issues, so "every tool's precision is being understated", and rankings shift with the judge model (Martian, February 2026).

Developer Reactions Count What Gets Rejected

The developer-fix judge also drives a Melbourne and Monash study of one widely used commercial reviewer across thousands of PRs. Most of the bot's comments were rejected, mainly as false positives (arXiv 2607.03316, July 2026). Developer responses are the judge closest to your own team, though busy developers reject some correct comments too.

CRJudgeBench Tests the Judges

CRJudgeBench turns golden comments on the graders, with expert-verified labels for correct and plausible-but-wrong review comments. The best models missed most of the wrong comments, so any benchmark scored by an LLM judge carries the judge's blind spots (arXiv 2609.37216, September 2026).

GitHub's ReviewBench Is Vendor-Run

GitHub's ReviewBench, published in October 2026, also uses golden comments, built from human reviews, follow-up commits, static analysis and several LLMs, then graded by an LLM judge (GitHub, October 2026). Qodo and GitHub both publish their methods next to their numbers, so read every vendor-run benchmark, Qodo's included, as a statement of method.

Each judge moves the false positive rate in a predictable direction. The one-known-bug and golden-comment judges understate precision, the human-comment judge ignores issues people missed, and LLM judges miss most plausible-but-wrong comments. One false positive number says more about the benchmark than the tool, as the four judges below show.

How Accurate Are AI Code Review Tools at Detecting Real Issues?

Accuracy needs two numbers, not one. Precision is the share of a reviewer's comments that point at a real problem. Recall is the share of real problems the reviewer finds. F1 combines both into one score, and it hides which of the two moved.

Precision without recall is a trap. A reviewer that leaves one correct comment per PR and misses every other bug scores perfect precision and catches almost nothing. A reviewer that flags every line scores high recall and buries the real bug in noise.

Picture a PR with three real bugs. Reviewer A leaves two comments, both correct, and misses one bug, for perfect precision and two-thirds recall. Reviewer B leaves twelve comments, catches all three bugs and adds nine nits. Reviewer B finds more, but nine nits per PR teach developers to skip its comments.

Good bug detection sits between the two, and the right point depends on the repo. A payments service can afford more comments to catch more defects, and a docs repo can't. The useful question for a vendor is whether you can move that point yourself.

What Makes an AI Reviewer Raise Fewer False Positives

Five checks separate reviewers that stay quiet for good reasons from reviewers that stay quiet because they miss things. Teams that compare AI code review benchmarks without checking method, recall and learning end up choosing the vendor with the most flattering method, so I apply these in order.

You choose the precision and recall tradeoff. The reviewer exposes settings that trade comment volume for coverage, per repo or per team.
The reviewer learns from dismissed findings. A dismissal changes future reviews, ideally with a reason attached.
The reviewer reads context beyond the diff. Repository context and team history cut the comments that are wrong only because the reviewer couldn't see the rest of the code.
You can verify the numbers. The vendor publishes its method, and outcomes per finding are exportable, so you can check any benchmark on your own repos.
The reviewer is independent of the tool that wrote the code. A reviewer that shares the writer's model shares its blind spots.

How to Run a Two-Week Noise Trial on Your Own Repos

A two-week trial on three to five active repos beats any public benchmark, because the ground truth is your own team. Run it the way you'd shift left any other quality check, on real PRs before merge.

Track Four Numbers From Day One

Findings acted on. Count how many findings got an outcome at all, accepted, not accepted or dismissed.
Findings accepted. Count the findings that led to a code change.
Dismissals by reason. Split false positives from "intentional" and "fix later", because only the first is noise.
Bugs found later. Log every bug that reached staging or production from a reviewed PR and check whether the reviewer flagged it.

Change One Setting at a Time

Run the first week on default settings and the second on the vendor's highest-precision setting. Compare acceptance and missed bugs between the weeks, and write the dates next to every number in the report.

Every number goes stale, and the judges move too. Models change every few months, and a benchmark run in February describes a product that may not exist by October, so I rerun my own trial after each major model change.

In a monorepo, run the trial per directory, and our roundup of AI code review tools for GitHub monorepos covers per-directory setup.

Keep the reviewer advisory during the trial. Developers should feel free to ignore findings, because forced replies inflate acted-on counts and hide the real noise level. Ask two senior reviewers to label a random sample of fifty findings at the end, so you have a human check on the dismiss reasons.

The academy guide to AI code review comparison has a scoring sheet you can adapt for the trial.

How I Evaluated the Tools

I read each vendor's docs on noise controls, learning and analytics on October 27 and 28, 2026, and scored the five tools against the five checks. I didn't rank tools against each other's benchmark numbers, because the methods don't compare.

Check	Qodo	CodeRabbit	Greptile	cubic	Copilot code review
Choose the tradeoff	Presets, severity thresholds	Review profile	Strictness, comment types	Not documented as a setting	Effort levels
Learns from dismissals	Dismiss reasons, rule deactivation	Chat learnings	Reactions, addressed comments	Reactions, replies	Instructions, Memory
Context beyond the diff	Repository and PR history context	Linked repositories, learnings	Codebase index	Senior reviewer learnings	Repository facts in Memory
Numbers you can verify	Published benchmark method, analytics, CSV export	Not documented	Not documented	Analytics on issues fixed	Not documented
Independent of the writing tool	Yes, reviews code from any agent	Yes	Yes	Yes	Same vendor as Copilot

The Tools Ranked

1. Qodo: Best for Tuning Precision and Separating Noise From Intent

Tool Overview

Qodo is a code review platform that runs on GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit. Qodo's findings are advisory, so reviewers decide what to act on, and the outcomes show up in Qodo's analytics. Qodo is the reviewer I'd pick for teams that want noise under their own control.

Main Features

Review presets that pick the tradeoff. Recall catches what other reviewers miss, and Precision cuts the noise, showing only comments worth acting on.
Dismissals with a reason. Dismissing a finding asks for a reason, False positive, Intentional, Fix later or Not specified, so noise is separated from deliberate choices.
Relevance from PR history. On GitHub and GitLab, Relevance marks each finding High, Medium or Low by how the team handled similar findings in past PRs.
Automatic rule deactivation. Qodo 3.1 deactivates rules whose findings are rarely fixed, and locking a rule keeps it in every review.
Code review analytics. Admins see acted-on and accepted findings by repository, author, severity and category.

On GitHub and GitLab, Relevance marks low-relevance findings as the kind your team usually ignores, which makes it the first noise control I'd turn to. Qodo's roundup of tools for GitLab AI code review covers GitHub as well.

Qodo publishes its numbers with the method attached. Qodo-reported precision was 74.5% with 44.2% recall in Precise mode and 63.8% with 56.7% recall in Exhaustive mode (Qodo, February 4, 2026). The run covered 100 PRs with 580 injected issues and an LLM judge.

The write-up on Qodo's real-world benchmark explains the injected-issue method.

Hands-On: Switching to the Precision Preset and Reading Dismissals

Presets live on the Configurations page in the Qodo portal. Under Review preset, pick the Precision card, read the confirmation dialog that names which finding types turn on or off, and select Switch preset. The switch applies at the level you're viewing, workspace, Git organization or repository, and leaves findings already posted as they are.

After a week, export findings.csv from the code review analytics menu. Each row is one finding, and the attribution status column records whether the author implemented, didn't implement or dismissed it. A few lines of Python give you the trial numbers per repo.

import csv
from collections import Counter

rows = list(csv.DictReader(open("findings.csv")))
by_status = Counter(r["Attribution status"] for r in rows)
acted = sum(by_status[s] for s in ("implemented", "not_implemented", "dismissed"))
print(by_status)
print("accepted share:", round(by_status["implemented"] / max(acted, 1), 2))

The export holds up to 10,000 findings and can include outdated findings and findings detected after merge, which the dashboard excludes, so CSV totals may differ from the dashboard.

Best For

Qodo is best for teams that want to choose their own precision point and see which findings their developers act on. Pick Qodo when reviewers have started ignoring bot comments and you need the noise back under control.

How It Ranked

Qodo passed all five checks. The preset switch covers the tradeoff, dismiss reasons, Relevance and rule deactivation cover learning, and the CSV export lets you measure noise on your own repos. Qodo is my first pick for any team tuning review noise.

2. CodeRabbit: Best for Teams That Want a Quiet Review Profile and Chat Learnings

Tool Overview

CodeRabbit is an AI PR reviewer on GitHub, GitLab, Azure DevOps and Bitbucket. CodeRabbit builds review behavior from its config file, guideline files, preferences stated in chat and learnings inferred during review.

Main Features

Review profiles. The reviews.profile setting takes quiet, chill or assertive, and quiet posts only the most important comments inline and groups the rest in the summary.
Learnings. Preferences stated in chat become learnings that apply per repository or across the organization.
Path instructions. .coderabbit.yaml holds path-specific instructions and guideline files.

Best For

CodeRabbit is best for teams that want to turn volume down with one setting and teach the bot in chat.

How It Ranked

CodeRabbit covers the tradeoff and learning checks. I didn't find a published benchmark method or a per-finding outcome export in the docs I read.

3. Greptile: Best for Teams That Tune Strictness per Directory

Tool Overview

Greptile is an AI PR reviewer on GitHub, GitLab, Bitbucket and Cursor Origin that indexes your codebase. Greptile learns from team comments, reactions and whether comments get addressed between commits.

Main Features

Strictness from 1 to 3. Greptile's docs describe 1 as verbose, 2 as balanced and 3 as critical issues only, and a subdirectory config can override the root in a monorepo.
Comment types and ignore patterns. Teams can limit feedback to categories such as logic and skip paths such as generated code.
Suppression of ignored comment types. Comment types the team keeps ignoring get suppressed.

Best For

Greptile is best for monorepo teams that want stricter review in one directory and lighter review in another.

How It Ranked

Greptile covers the tradeoff check with three strictness levels and per-directory overrides, and learns from team behavior. I didn't find a per-finding outcome export in the docs I read.

4. cubic: Best for GitHub Teams That Calibrate With Reactions

Tool Overview

cubic is an AI PR reviewer on GitHub. cubic learns from direct feedback on its comments and from the historical PR comments of senior reviewers a lead picks during onboarding.

Main Features

Reactions as calibration. Thumbs up and down help cubic calibrate what's useful versus noise for your codebase.
Merge confidence summary. An optional 1 to 5 score summarizes merge risk and updates as issues are addressed.
Analytics on issues fixed. The analytics pages report issues flagged, issues fixed and issue types.

Best For

cubic is best for GitHub-only teams that want reactions and senior reviewers' history to shape what the bot flags.

How It Ranked

cubic learns from feedback and measures fixes, but it runs on GitHub only, and I didn't find a setting that picks the precision and recall point directly.

5. GitHub Copilot Code Review: Best for Teams That Want Lighter or Deeper Review on GitHub.com

Tool Overview

Copilot code review is Copilot's PR reviewer on GitHub.com and in Azure DevOps. Copilot is not guaranteed to spot all problems (GitHub docs), and by default its reviews don't count toward required approvals.

Main Features

Review effort levels. Lite, Balanced and Max control how much effort a review spends, with Balanced as the default and Max in preview.
Instruction files and skills. .github/copilot-instructions.md, path-specific instruction files and AGENTS.md tell the review what to check.
Copilot Memory. Stored repository facts can inform later reviews.

Best For

Copilot code review is best for teams on GitHub.com that want to dial review depth up or down per repo.

How It Ranked

Effort levels cover the tradeoff, and instruction files cover learning. Copilot reviewing Copilot's code shares the writer's blind spots, and you shouldn't review code with the same tool that wrote it.

Conclusion

The lowest false positive rate isn't a number you can look up, because every 2026 benchmark counts "wrong" its own way. Read the method before the result, insist on recall next to precision and date every figure. Then run two weeks on your own repos.

Qodo ranked first because it lets you choose the tradeoff, records why each finding was dismissed and shows the outcomes, as a reviewer independent of the agent that wrote the code.

FAQ

What is a good false positive rate for AI code review?

A good false positive rate for AI code review is one that falls on your own repos as you tune the reviewer, because no single number travels between benchmarks. Qodo's dismiss reasons separate real false positives from "intentional" and "fix later", so you track the right share.

Precision or recall: which matters more?

Recall matters more on high-risk code such as payments or auth, and precision matters more on low-risk repos where noise costs attention. Qodo's Precision and Recall presets switch per repository.

How do AI reviewers learn from dismissed comments?

Each tool records feedback differently. Qodo asks for a dismiss reason and deactivates rules whose findings are rarely fixed, Greptile and cubic read reactions, and CodeRabbit turns chat preferences into learnings.

Why do code review benchmarks disagree?

Code review benchmarks disagree because each one defines a false positive differently, uses a different judge and tests different PRs. LLM judges also miss many plausible-but-wrong comments, and Qodo publishes the method behind its own benchmark so you can see which choices it made.

Which AI code review tool is the best?

The best AI code review tool keeps noise low without missing bugs. Qodo ranks first because you pick the tradeoff with a preset, every dismissal carries a reason and the export lets you measure noise yourself. For teams using an agent's built-in reviewer such as Cline code review, Qodo adds an independent pass.

How do I measure noise during a trial?

To measure noise during a trial, export per-finding outcomes, count accepted findings, split dismissals by reason and log bugs found later, with a date on every number. Qodo's findings.csv holds per-finding outcomes in one file, and your incident log covers bugs found later.

Best AI Code Review Tools for Air-Gapped and Self-Hosted Environments (2026)

Dave Barron — Wed, 28 Oct 2026 22:01:58 +0000

Air-gapped AI code review means the whole review, model calls included, runs with nothing crossing your network boundary. I design review pipelines for teams whose code can't leave the building, and I checked five tools against their own docs on October 27 and 28, 2026, ranking them on what a review sends over the wire.

TL;DR

Self-hosted and air-gapped mean different things. A self-hosted reviewer can still call a hosted model over the internet, and an air-gapped one can't call anything outside your network.
The test is zero egress with your own model endpoint. A tool passes when the review runs, model calls included, with no route out, and still reads more than the diff.
Most regulated teams already find sovereignty hard. Most executives say meeting data residency or sovereignty requirements is challenging (IBM Institute for Business Value, June 2026).
Local models are now good enough to pilot. A 2026 university study found local open-weight models matched an earlier agentic approach that used a hosted frontier model on secure code review (arXiv 2610.27383, October 2026).
Qodo is my #1 because it runs air-gapped on all four self-hosted Git platforms. Qodo installs offline, sends model calls only to your own endpoint, and reviews code from any agent as an independent reviewer. Pick Qodo when your self-hosted Git has to stay fully inside the network.

The 5 Best AI Code Review Tools for Air-Gapped Environments

Qodo: best for air-gapped review on all four self-hosted Git platforms
Greptile: best for self-hosted review on GitHub, GitLab or Perforce
Tabnine: best for air-gapped teams that want review and code completion from one private install
SonarQube Server: best for rules-based static analysis with AI fixes on your own model
A DIY reviewer on open-weight models: best for platform teams that want full control

Tool	Best for	Air-gapped install
Qodo	Air-gapped review on all four self-hosted Git platforms	Supported, with your own OpenAI-compatible endpoint
Greptile	Self-hosted review on GitHub, GitLab or Perforce	Whole service can run air-gapped
Tabnine	Review and code completion from one private install	Private installation can run fully air-gapped
SonarQube Server	Rules-based static analysis with AI fixes on your own model	AI CodeFix runs without outbound internet
DIY on open-weight models	Platform teams that want full control	Whatever you build

Air-Gapped vs Self-Hosted vs Single-Tenant: What Each Means

Vendors use "self-hosted" and "air-gapped" as if they were one word, and procurement teams pay for the confusion later. The difference comes down to what crosses your network boundary during a review. Air-gapped code review means nothing does.

Coding agents moved inside the firewall in 2026 too, and IBM added on-premises, sovereign cloud and fully air-gapped deployment for its Bob coding agent (IBM, October 1, 2026). Reviewers now get held to the same bar.

Deployment mode	Where the reviewer runs	What leaves your network during a review
Multi-tenant SaaS	The vendor's shared cloud	Code context and model calls go to the vendor
Single-tenant	A dedicated instance, often in your cloud account	Code stays in the dedicated instance; model calls go wherever the instance points
On-premises (self-hosted)	Your own cluster	Model calls, license checks and image pulls may still go out
Air-gapped	Your own cluster with no route out	Nothing, so models, images and updates all come in by hand

Teams in regulated sectors often start from compliance rules, and the glossary entry on HIPAA and FedRAMP compliance covers why auditors ask about data paths first. The mode you need follows from the data path your auditors accept.

Most IT decision-makers would pick on-premises, private or hybrid infrastructure for AI on sensitive data, in a survey commissioned by storage vendor Cloudian (Cloudian, March 2026). Switching later is hard, and most executives say changing AI vendor or model would be difficult (IBM Institute for Business Value, June 2026).

What Makes an AI Code Review Tool Work Air-Gapped

Banks, defense contractors and hospital networks I've worked with all apply the same five checks. I use them as a gate, in order, because a tool that fails the first one never reaches the others.

Zero egress from install to review. The reviewer talks only to a model endpoint you run, and images and charts arrive as a bundle you mirror.
Support for your self-hosted Git. The reviewer works with GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center or Gerrit, whichever you run.
Context beyond the diff that stays current offline. Repository and PR history indexes refresh inside the network.
Governance across many repos from one place. Rules, findings and analytics live at the organization level.
Independence from the tool that wrote the code. The reviewer isn't the coding agent grading its own output.

Teams on GitLab Self-Managed usually feel the Git check first, because many reviewers document only cloud Git platforms. Teams on Bitbucket Data Center and Gerrit feel it even sooner, since fewer vendors list either one.

Our roundup of secure code review tools covers the wider category. The air-gapped list here is narrower, because most security reviewers still assume a cloud model.

Can You Run AI Code Review With Self-Hosted LLMs?

You can run AI code review with self-hosted LLMs as long as the reviewer accepts an OpenAI-compatible endpoint and you can serve a model behind one. Most self-hosted reviewers in 2026 speak that API shape, so a model served through vLLM, Ollama or an internal gateway can sit behind the reviewer without code changes.

Local models are good enough to test. A Monash and Melbourne paper ran agentic secure code review on local open-weight models and matched an earlier agentic approach that used a hosted frontier model (arXiv 2610.27383, October 2026). Every approach scored low in absolute terms, so treat the result as parity rather than a solved problem.

The authors frame the motivation in words any security lead will recognize, writing that "source code is confidential and cannot be sent to an externally hosted commercial model" (arXiv 2610.27383, October 2026). Air-gapped teams have said the same for years, and the paper gives them a tested way to act on it.

The model choice stays yours, and so does the evaluation. Before a pilot, I run the reviewer against a few dozen merged PRs with known bugs. I compare findings across two or three candidate models, using the steps in our AI code review POC.

Zero Data Retention vs Zero Egress

Zero data retention is a promise from a vendor that your code won't be stored after processing. Your code still leaves the network to get processed, and you trust a contract for what happens next.

Zero egress means the code never leaves at all. Security teams in air-gapped sites treat retention promises as irrelevant, because the question they ask is about the wire, not the vendor's disk.

The practical setup for zero egress is an internal AI gateway that fronts your models, logs every call and enforces which models each service may use. The reviewer then points at the gateway and never learns a public hostname.

I prove zero egress before I trust it. Apply a deny-all egress policy to the reviewer's namespace, allow only the gateway, Git server and database, and run a week of real reviews. Any blocked connection is a finding for the vendor, and a clean week is evidence for the auditors.

What Goes Stale When the Network Is Cut

Air-gapped systems age in place. Every component that a SaaS reviewer refreshes silently now needs an owner on your side.

Models. New model versions arrive only when someone imports and approves them.
Rules and review standards. Organization rules stay current only if the reviewer stores them inside your cluster.
Repository and PR history indexes. Indexes must rebuild locally as code changes, or the reviewer reads last quarter's codebase.
Container images and charts. Upgrades mean a new bundle, a new mirror and a change window.

Legal and security teams I work with want a written account of what leaves the environment before any pilot, and they ask early who carries upgrades. Put both answers in the pilot plan, with a named owner for models, rules, indexes and images.

How I Evaluated the Tools

I read each vendor's own deployment, networking and model-provider docs on October 27 and 28, 2026, and scored each tool against the five checks. "Not documented" means I couldn't find the answer in public docs, not that the feature is missing.

Check	Qodo	Greptile	Tabnine	SonarQube Server	DIY
Zero egress, install to review	Own OpenAI-compatible endpoint; chart bundle plus full image mirror	Any OpenAI-compatible API; registry credentials from Greptile	Fully air-gapped private installation; offline bundle not documented	Self-hosted gateway; self-managed install	You build and package it
Self-hosted Git covered	All four	GitHub, GitHub Enterprise, GitLab, Perforce	Through a CLI step in CI	GitHub, GitLab, Bitbucket, Azure DevOps	You wire it
Context beyond the diff	Repository indexing and cross-repo context	Codebase indexing with an embedding model	Not documented	Rules over the analyzed code	Diff unless you build more
Governance across repos	Organization rules and findings, with analytics in the portal	Not documented	Not documented	Quality gates per project	You build it
Independent of the writing tool	Yes, reviews code from any agent	Yes	Same vendor as the assistant	Yes	Depends on your model

The Tools Ranked

1. Qodo: Best for Air-Gapped Review on All Four Self-Hosted Git Platforms

Tool Overview

Qodo is a code review platform that runs as multi-tenant SaaS, single-tenant, on-premises or air-gapped. Qodo supports air-gapped installs on GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center and Gerrit, the four self-hosted platforms I see at regulated companies. Qodo is the reviewer I'd pick for teams on self-hosted Git that need review with zero egress.

Main Features

Your own model endpoint, with no call to a public API. The bundled LLM gateway forwards requests to the OpenAI-compatible endpoint you configure and runs no model itself. Once you configure your endpoint, Qodo needs no outbound access to api.openai.com.
An offline install path. Qodo runs on Kubernetes 1.25 or later with Helm 3, and air-gapped installs use the chart bundle plus a complete image mirror, because registry credentials alone don't make images available offline.
Single sign-on from your own identity provider. Prerequisites include an identity provider such as Entra, GCC High, Ping, Okta or Google Workspace, so SAML SSO or OIDC stays inside your directory.
Context beyond the diff. The optional context engine indexes your repositories inside the cluster for codebase-aware review.
Governance across repos. Organization rules and findings apply across repositories, and the portal's code review analytics show acted-on findings with a CSV export.
An independent reviewer. Qodo reviews code written by any agent, as a tool separate from the ones that write it.

Hands-On: Pointing Qodo at Your Own Model Endpoint

The Helm values that matter for egress sit under global.llm. Leave openaiBaseUrl empty and the gateway defaults to api.openai.com, which needs internet access, so the first job is to fill it in.

global:
  llm:
    bundled: true            # the in-cluster gateway stays on
    openaiBaseUrl: https://llm-gateway.internal.example/v1
    # modelMap: replace the built-in model list with the models your endpoint serves; it must include a text-embedding-3 model for indexing and retrieval
  imageProxyPrefix: registry.internal.example/qodo/

Credentials for the endpoint belong in a Kubernetes Secret, never in extraHeaders. The model map also needs an embedding model, because indexing and retrieval depend on one.

Mirror every image listed for your chart version, keeping paths and tags identical, then run Qodo's render check, which greps the rendered chart for any image outside your registry. A partial mirror fails later with ImagePullBackOff, so the check matters.

Size node counts and storage with Qodo's team before you order hardware. Telemetry is off by default, which saves one conversation with your security team.

Best For

Qodo is best for platform and security teams that need one reviewer across several self-hosted Git platforms with nothing leaving the network. Pick Qodo when auditors need every model call to stay on your own endpoint.

How It Ranked

Qodo passed all five checks. Its air-gapped install covers every self-hosted Git platform on my list, organization rules and findings apply across repositories, and the egress story rests on your own endpoint. Qodo is my first pick for regulated teams running GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center or Gerrit.

2. Greptile: Best for Self-Hosted Review on GitHub, GitLab or Perforce

Tool Overview

Greptile is an AI code reviewer that indexes your codebase and comments on PRs. The entire service can be self-hosted in an air-gapped environment, deployed with Docker Compose or Kubernetes and Helm (Greptile self-hosting docs).

Main Features

Two deployment paths. Docker Compose suits smaller teams, and Kubernetes with Helm suits larger ones.
Your choice of model provider. Supported providers include OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, GCP Vertex AI and any OpenAI-compatible API, with separate roles for reasoning, fast and embedding models.
Self-hosted Git coverage. Self-hosted deployments cover GitHub and GitHub Enterprise, GitLab and Perforce.
Licensed images. Registry credentials and a license come from Greptile.

Best For

Greptile is best for teams on GitHub Enterprise, GitLab or Perforce that want a self-hosted reviewer with codebase indexing.

How It Ranked

Greptile passes the egress check on its own docs. Bitbucket Data Center and Gerrit don't appear in the self-hosted SCM table, and I found no documented governance across repos, so Greptile ranks second for organizations that run more than GitHub and GitLab.

3. Tabnine: Best for Air-Gapped Teams That Want Review and Code Completion From One Private Install

Tool Overview

Tabnine is a coding assistant with code review features. An Enterprise private installation runs in a VPC or on-premises and can be deployed in a completely air-gapped environment (Tabnine deployment docs). Tricentis acquired Tabnine on July 30, 2026.

Main Features

A fully air-gapped private installation. The deployment options page documents VPC, on-premises and air-gapped installs.
Review as a script or CI step. The Tabnine CLI code review examples cover a pre-commit script and a GitHub Actions job.

Best For

Tabnine is best for air-gapped teams that want review and code completion from one private install.

How It Ranked

Tabnine's air-gapped story is documented, but the review path runs through a CLI that is in maintenance mode, with only critical updates through December 31, 2026, as users move to the Tabnine plugin for OpenCode.

The reviewer also comes from the same vendor as the assistant writing the code. You shouldn't review code with the same tool that wrote it, because the reviewer shares the writer's blind spots.

4. SonarQube Server: Best for Rules-Based Static Analysis With AI Fixes on Your Own Model

Tool Overview

SonarQube Server is self-managed static analysis that checks code against rules and quality gates. SonarQube Server 2026.5 integrates with GitHub, Bitbucket, GitLab and Azure DevOps.

Main Features

AI CodeFix on your own model. AI CodeFix, in the Enterprise and Data Center editions, can point at a self-hosted OpenAI-compatible gateway such as Ollama, LiteLLM or vLLM.
No outbound internet for fixes. AI CodeFix in a fully self-hosted setup runs without outbound internet access, because prompts and rule descriptions ship with the product.
Quality gates per project. Teams define pass or fail conditions that show on each pull request.

Best For

SonarQube Server is best for teams that want deterministic rules and quality gates inside the network, with AI used for fixes.

How It Ranked

SonarQube Server passes the egress check. Its review is rules-based static analysis, so it pairs with an LLM reviewer rather than replacing one.

5. A DIY Reviewer on Open-Weight Models: Best for Platform Teams That Want Full Control

Tool Overview

The DIY route wires an open-source review CLI to a local model behind an OpenAI-compatible API, triggered by a webhook or a CI job on each PR. The tools in our earlier roundup of open-source code review tools all support that pattern.

Main Features

Full control of every component. You pick the model, the prompts, the trigger and the comment format.
No license to negotiate. Open-source tools and open-weight models keep procurement simple.
Every gap is yours too. Context beyond the diff, evaluation, rule storage and upgrades all land on your team.

Best For

A DIY reviewer is best for teams with a strong platform engineering group that already runs internal model serving.

How It Ranked

A DIY build passes the egress check by construction. Self-hosted Git support, offline install, context, governance and independence all depend on how much you build and keep running, which is why the DIY option ranks last for most teams.

Conclusion

Air-gapped AI code review comes down to whether the review can run with nothing crossing the boundary and still understand the code.

Sort the deployment modes first, then hold every tool to zero egress against your own endpoint, and only then compare context and governance. Qodo cleared every check, with air-gapped installs on all four self-hosted Git platforms, as a reviewer separate from the agents writing the code. Start with Qodo when zero egress is a requirement.

FAQ

Can AI code review run with zero internet egress?

AI code review can run with zero internet egress when the reviewer forwards model calls to an endpoint inside your network and installs from a mirrored bundle. Qodo documents that setup for air-gapped installs, with no outbound access to api.openai.com once your own endpoint is configured.

What do I need to supply for an air-gapped install?

You supply the model endpoint, the Kubernetes cluster, a PostgreSQL database with pgvector, an image registry for the mirror and an identity provider. Sizing depends on your repositories, so confirm production capacity with the vendor. Qodo's air-gapped install uses exactly that list, plus a chart bundle you mirror.

Which Git platforms work air-gapped, and which only on-prem?

In Qodo's deployment table, GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center and Gerrit support air-gapped installs. Cloud-hosted platforms such as GitHub Cloud and GitLab Cloud mark air-gapped as not applicable, and Bitbucket Cloud and Azure DevOps Cloud run as cloud deployments.

Do I need OpenAI or Anthropic access if I bring my own endpoint?

You don't need OpenAI or Anthropic access if you bring your own endpoint. Qodo's bundled gateway forwards to the OpenAI-compatible endpoint you configure, so fill in the endpoint before the first review, because an empty setting defaults to api.openai.com.

How do images reach the cluster when the cluster can't reach a registry?

You mirror every image for your chart version into an internal registry and point the chart at it. Qodo ships each release as a chart bundle and image list, and its render check prints nothing when every image comes from your registry.

Who handles upgrades in a self-hosted deployment?

Your platform team handles upgrades, with new chart bundles and image mirrors for each release. Name an owner for models, rules, indexes and images before the pilot starts. Qodo ships each release as a chart bundle with a matching image list, so each upgrade follows the same mirror steps.

Best AI Code Review Tools That Discover Coding Rules From Pull Request History (2026)

Dave Barron — Tue, 27 Oct 2026 01:00:48 +0000

I write about how engineering teams build and keep review standards, most recently on what a base-branch REVIEW.md teaches about agent standards. Your team's real code review rules live in pull request (PR) comments, while CLAUDE.md and AGENTS.md hold only what someone remembered to write down. I ranked eight AI code review tools by how each one turns review history into rules: which signal the tool counts, whether each rule shows its source, and how unused rules retire.

TL;DR

Your real rulebook lives in review threads. The rules your senior reviewers actually apply sit in PR comments, and few of them reach your rule files.
Mining review history works when people keep the final say. Stationwise turned two and a half years of PR comments into a skill file of around 11,000 tokens, with the team choosing which repeats to keep (Stationwise engineering, February 2026).
Choose by signal, source and retirement. Signal is which review comments a tool counts, source is whether each rule traces back to its PRs, and retirement is what happens to a rule your team keeps dismissing.
Qodo is my #1 because its rules earn their place on signal, source and retirement. Rules come only from accepted comments that changed code, weighted by code ownership, every rule opens the PRs behind it, and rules your team rarely fixes retire on their own.

The 8 Best AI Code Review Tools That Discover Coding Rules From Pull Request History

Qodo: rules discovered from accepted review comments
CodeRabbit: configuration files and chat preferences
Greptile: dashboard rules, team comments and reactions
Cursor Bugbot: Team Rules, BUGBOT.md and remember comments
cubic: replies, reactions and chosen reviewers
Kodus: three months of closed PRs
Bito: negative feedback and guideline files
GitHub Copilot code review: instruction files and skills

Tool	Where its rules come from	Best for	Price as of October 2026
Qodo	Accepted review comments that led to code changes, plus imported rule files and rules you write	Platform and staff engineers who want rules mined from real fixes, traceable to source PRs and retired by fix rate	14-day free trial; Pro Team from $30 a month for 2,500 credits; Enterprise custom, with self-learning listed under Enterprise
CodeRabbit	`.coderabbit.yaml`, path instructions, code guidelines files, preferences stated in chat	Reviewers who state preferences to the bot in chat	Essentials $24 per user a month, billed annually; Team $48
Greptile	Dashboard or `.greptile` rules, team PR comments, replies, reactions, whether comments were addressed in later commits	Teams who want everyday comments and reactions to shape review	$1 per credit
Cursor Bugbot	Team Rules, `BUGBOT.md`, repository rules, rules generated from GitHub activity, `@cursor remember`	Engineering groups who add rules with a remember comment in the PR	Billed through a Cursor plan
cubic	Replies, thread context, reactions, past comments from reviewers picked at onboarding	Leads who pick which reviewers' history shapes the rules	Team $40 per developer a month
Kodus	Kody's past reviews and recurring feedback in the last 3 months of closed PRs	Teams who want weekly rule suggestions from recent PRs	Free Community plan; Teams $10 per developer a month plus model tokens
Bito	Negative feedback on Bito's own comments, dashboard or `.bito.yaml` guidelines, repo guideline files	Teams who correct the bot by reacting to its comments	Guidelines on the Professional plan
GitHub Copilot code review	Instruction files, `AGENTS.md`, organization instructions, `.github/skills`	Teams that already keep instruction files in their GitHub repos	Paid Copilot plans; reviews use AI credits

Most Teams Have Two Rulebooks: Rule Files and Review Threads

One rulebook lives in CLAUDE.md, AGENTS.md or REVIEW.md. The other lives in the comments senior reviewers leave on PR after PR, and nobody writes it down.

The real rulebook keeps changing in review threads, and new hires and coding agents repeat mistakes the team fixed a year ago.

Mining the Second Rulebook Works When People Keep the Final Say

A tool can find the repeats in review history, and the rules that work are short, come from real fixes and stay under human judgment.

What Two and a Half Years of PR Comments Contained

The repeats are findable. One of Stationwise's patterns was to use parseISO from date-fns instead of new Date() for date strings, flagged in 25+ distinct PRs (Stationwise engineering, February 2026).

Stationwise's final file stayed lean, so the diff still has room in context. The machine found the repeats, and people decided which ones were worth keeping.

Rules Mined From History Change What Agents Do

Repository norms measurably improve agent output. Agents that drew on a repo's explicit and implicit norms, consulting its Git history when needed, showed a 31.64% to 45.44% relative improvement in norm compliance over a no-guidance baseline, across 121 tasks and three coding models (RepoNorm, October 2026).

The list that works is short and comes from real fixes. When every accepted review comment became a persistent rule for a coding agent on a 35+ service platform, the list grew to just 18 rules, and the error classes those rules covered didn't come back across 11 recorded sessions, which is early evidence (arXiv, July 2026).

One Review Comment, Repeated: Use parseISO

A reviewer has asked for the same date fix in many PRs (illustrative).

// Flagged in review, again
const due = new Date(invoice.dueDate); // "2026-11-08" parses as midnight UTC (Coordinated Universal Time)

// What the reviewer asks for
import { parseISO } from "date-fns";
const due = parseISO(invoice.dueDate);

What Makes a Mined Code Review Rule Worth Trusting

Trust in a mined rule comes down to three questions.

Signal decides which comments count.
1. The tool counts comments that changed code. Praise, questions and nitpicks aren't standards, and the parseISO request counts because authors applied the fix.
2. The tool weights the reviewer who owns the code.
3. The tool scopes rules to the paths where the feedback happened, so the parseISO rule belongs in web/ and stays out of the Go services.
Source shows where a rule came from.
1. Every rule links back to the PRs it came from, so a developer can judge the rule before dismissing a finding.
2. The tool keeps your existing rule files as a starting point, with mined rules beside them.
Retirement decides what happens when the team stops following a rule.
1. You choose whether rules wait for approval or apply at once.
2. Rules nobody fixes fade out, and rules you need can be locked.

The funnel narrows all review comments to comments accepted with a code change, then to owner-weighted, recurring feedback, and finally to one rule scoped to web/**.

The rule card shows three states: active with a Source link to three PRs, deactivated after the team rarely fixed its findings, and locked so the rule stays active.

Mined rules do the most good when the review that applies them sits outside the agent writing the code, because you shouldn't review code with the same tool that wrote it.

How I Evaluated the Tools

I checked signal, source and retirement for every tool that builds custom review rules, using each vendor's own docs as of October 2026.

The 8 Tools Ranked on the parseISO Comment

1. Qodo Turns Accepted Review Comments Into Rules You Can Trace

Tool Overview

Qodo gives you rules your team already proved in review, because Qodo's Rule Miner learns only from comments that changed code. Qodo builds Qodo Rules from your rule files, rules you write and your PR history, checks each PR against those rules with Rule enforcement.

Main Features

Signal. Four signals decide what becomes a rule: reviewer code ownership, recurring comments, pattern clustering by path, and rejected suggestions, which lower an active rule's signal over time. One comment qualifies when it comes from a reviewer with strong ownership of that code.
Source. Each mined rule carries a Source field that links to the PR it came from. When a pattern came from several PRs, the field shows the count and the rule sidebar lists every contributing PR, so a developer reads the original threads first.
Retirement. The "Auto-approve rule miner suggestions" setting decides whether a new rule is active on the next review or waits in Pending rules for an admin. Since Qodo 3.1 (October 15, 2026), Qodo deactivates rarely fixed rules on its own. Locking keeps a rule active, and the rules analytics page shows a "Deactivated by Qodo" count for the last 30 days.
Your existing files as the starting point. Qodo imports rule files such as AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md and everything in .cursor/rules/. Only new rules in imported files sync, so you edit and retire rules in the Rules tab.
Shared rules before the agent writes. The Get Rules skill in the Agentic Toolbox loads your Qodo Rules into a coding agent before the agent writes, and the PR review still checks every change.
Cadence and providers. The first run reads up to about 1,000 recently merged PRs once PR history indexing finishes and generates up to 10 rules per repository. Rule Miner then runs every two weeks and adds up to 5. Rule Miner runs on GitHub and GitLab, on multi-tenant and single-tenant deployments.
Pricing. A 14-day free trial, then Pro Team from $30 a month for 2,500 credits pooled across the team, with self-learning under custom Enterprise pricing (October 2026).

Best For

Qodo is best for platform and staff engineers who want rules mined from real fixes, traceable to their source PRs and retired by how often the team fixes them.

How It Ranked

Qodo counts only accepted comments that changed code, links each rule to every contributing PR, and retires rules by fix rate unless you lock them. In the parseISO case, Rule Miner proposes a rule scoped to web/**, with the source PRs one click away.

2. CodeRabbit: Configuration Files and Chat Preferences

Tool Overview

CodeRabbit is an AI PR reviewer on GitHub, GitLab, Azure DevOps and Bitbucket. CodeRabbit builds its rules from config, guideline files, preferences stated in chat and learnings CodeRabbit infers during review.

Main Features

Configuration and learnings. .coderabbit.yaml holds path instructions and code guidelines files, and learnings apply per repository or org-wide.
Traceable learnings. Each learning shows who created it and the repository, and pending learnings show the source PR when available.

Best For

CodeRabbit is best for reviewers who state preferences to the bot in chat.

How It Ranked

Chat-sourced learnings apply at once by default, with an optional approval delay of up to 30 days, and inferred learnings apply right away to their source PR. Nothing retires a learning automatically, and the dashboard flags never-used learnings. In the parseISO case, the rule arrives through chat, config or a learning inferred during review.

3. Greptile: Dashboard Rules, Team Comments and Reactions

Tool Overview

Greptile is an AI PR reviewer on GitHub, GitLab, Bitbucket and Cursor Origin, priced at $1 per credit. Greptile learns from team comments and whether they get addressed.

Main Features

Custom rules. Rules written in the dashboard or .greptile config apply as written.
Learning from the team. Greptile learns from team comments on PRs, replies, reactions and commits that show whether comments were addressed between the first and last commit.
Rule discovery and suppression. Greptile infers suggested custom rules from repeated team comments, and comment types the team keeps ignoring are suppressed.

Best For

Greptile is best for teams who want everyday comments and reactions to shape review.

How It Ranked

Greptile counts whether comments were addressed and suppresses ignored comment types. In the parseISO case, the repeated, applied requests are documented inputs, while Greptile's docs don't say whether a learned rule links back to its source PRs (October 2026).

4. Cursor Bugbot: Team Rules, BUGBOT.md and Remember Comments

Tool Overview

Cursor Bugbot is Cursor's PR reviewer, billed through a Cursor plan. Bugbot learns from repository activity and from an explicit @cursor remember comment in the PR.

Main Features

Rule sources. Team Rules, .cursor/BUGBOT.md and repository rules sit next to rules Bugbot generates from GitHub activity or a manual backfill.
Remember comments. A @cursor remember comment turns a point raised in a PR into a rule, with rules capped at 30,000 characters each and 100,000 combined.
Rule analytics. Each rule shows issues found, accepted issues and acceptance rate.

Best For

Cursor Bugbot is best for engineering groups who add rules with a remember comment in the PR.

How It Ranked

Bugbot enables or disables learned rules as it learns more, and per-rule acceptance rates show their value. In the parseISO case, the rule arrives through activity-generated rules or one @cursor remember comment.

5. cubic: Replies, Reactions and Chosen Reviewers

Tool Overview

cubic is an AI PR reviewer on GitHub, with Team at $40 per developer a month. cubic learns from replies and reactions from anyone, and adds the history of up to five reviewers a lead picks, going back up to four years.

Main Features

Feedback on cubic's comments. cubic learns from replies to its comments, thread context and reactions.
Chosen reviewers' history. Past PR comments from senior reviewers picked at onboarding appear under Team patterns.
Traceable learnings. Each learning shows an actionable summary and the original feedback, and when a stored learning drives a comment, cubic references the learning in that comment.

Best For

cubic is best for leads who pick which reviewers' history shapes the rules.

How It Ranked

cubic links comments to the learning behind them, and a weekly cleanup archives learnings that stop helping. In the parseISO case, the requests become an input through replies, or through history if the reviewer asking for the fix was picked at onboarding.

6. Kodus: Three Months of Closed PRs

Tool Overview

Kodus is an AI PR reviewer on GitHub, GitLab, Bitbucket, Azure Repos and Forgejo, with a free Community plan and Teams at $10 per developer a month plus model tokens.

Main Features

A rolling history window. Kodus derives rules from Kody's past reviews and recurring feedback patterns in the last 3 months of closed PRs, and needs 3 months of Kody review history first.
Weekly suggestions. Kodus suggests rules weekly, and suggested rules are active by default, with an approval step available.

Best For

Kodus is best for teams who want weekly rule suggestions from recent PRs.

How It Ranked

Kodus's docs don't describe how rules retire (October 2026). In the parseISO case, the requests may become a candidate rule if they fall inside the 3-month window, though a human reviewer's request may not count.

7. Bito: Negative Feedback and Guideline Files

Tool Overview

Bito is an AI PR reviewer on GitHub, GitLab and Bitbucket, with custom guidelines on the Professional plan. Bito learns from how people react to Bito's own comments.

Main Features

Rules from negative feedback. Negative feedback on Bito's comments becomes a learned rule that filters Bito's own unwanted suggestions rather than recording team standards. On the Learned Rules dashboard, rules start disabled, switch on at 3 negative feedbacks and can be switched on or off by hand.
Guideline files with citations. Guidelines come from the dashboard, .bito.yaml and repo files such as CLAUDE.md, AGENTS.md and .cursor/rules/*.mdc, and guideline comments carry a Citations section linking the guideline.

Best For

Bito is best for teams who correct the bot by reacting to its comments.

How It Ranked

Bito documents no automatic retirement, so rules are switched off by hand. In the parseISO case, a human reviewer's request becomes a rule once someone writes it into a guideline.

8. GitHub Copilot Code Review: Instruction Files and Skills

Tool Overview

Copilot code review is Copilot's PR reviewer on GitHub.com and in Azure DevOps, on paid Copilot plans where reviews use AI credits. Copilot code review follows the instruction files and skills your team writes.

Main Features

Instruction files. .github/copilot-instructions.md, path-specific *.instructions.md, AGENTS.md and organization instructions tell the review what to check.
Skills and memory. .github/skills add reusable instructions, and Copilot Memory can inform reviews.

Best For

Copilot code review is best for teams that already keep instruction files in their GitHub repos.

How It Ranked

Instructions apply as written until someone edits them, and each rule's source is the file you wrote. In the parseISO case, the rule arrives once someone writes it into an instruction file.

Detailed Comparison: Signal, Source and Retirement

Tool	Signal	Source	Retirement	`parseISO` case	Best for
Qodo	Accepted comments that changed code, weighted by ownership, recurrence and path	Source field linked to every contributing PR	Approve first or auto-apply; deactivated by fix rate; locking	Rule scoped to `web/**`, source PRs one click away	Platform and staff engineers who want rules mined from real fixes
CodeRabbit	Config, guidelines files, chat preferences and learnings inferred during review	Each learning shows who created it and the repository; pending learnings show the source PR when available	Apply at once by default; optional approval delay of 0 to 30 days for chat learnings; no automatic retirement, and the dashboard flags never-used learnings	Rule once stated in chat or config, or inferred during review	Reviewers who state preferences to the bot in chat
Greptile	Team comments, replies, reactions and whether comments were addressed in later commits, plus written rules	Docs don't say (October 2026)	Comment types the team keeps ignoring are suppressed; written rules apply as written	Repeated comments are a documented input	Teams who want everyday comments to shape review
Cursor Bugbot	Repository activity, Team Rules, `BUGBOT.md`, remember comments	Docs don't say (October 2026)	Learned rules enabled or disabled as Bugbot learns; per-rule acceptance rates	Activity-generated rule or one remember comment	Engineering groups who add rules with a remember comment
cubic	Replies, reactions and chosen reviewers' comments	Each learning shows the original feedback, and review comments link to the learning behind them	Weekly cleanup archives learnings that stop helping	Input through replies, or history if the reviewer was picked	Leads who pick whose history shapes the rules
Kodus	Kody's past reviews and recurring feedback in the last 3 months of closed PRs	Docs don't say (October 2026)	Docs don't describe retirement (October 2026)	Possible candidate if inside the 3-month window	Teams who want weekly suggestions from recent PRs
Bito	Negative feedback that filters Bito's own comments, guideline files	Guideline comments cite the guideline; docs don't say for feedback rules (October 2026)	No automatic retirement documented; rules can be switched off by hand	Rule once written into a guideline	Teams who correct the bot by reacting
GitHub Copilot code review	Instruction files, skills, Copilot Memory	The file you wrote	Apply as written until edited	Rule once written into an instruction file	Teams that already keep instruction files in their GitHub repos

A Retirement Policy for Mined Rules

Start with approval on for the first two runs of your AI code review rollout, so owners see what the history yields.
Lock the handful of rules tied to compliance or incidents.
Let everything else retire on its own when the team stops fixing it.
Review the deactivated count monthly and re-scope rules that fire in the wrong paths.

Conclusion: Your Code Review Rules Already Exist

Your code review rules already exist in review threads where a senior engineer asked for the same fix again and again. Bugbot, cubic and Greptile retire, archive or suppress learned feedback too, and Qodo retires a rule by how often your team fixes its findings, with every mined rule linked to its source PRs.

In the parseISO case, Qodo ends up with a frontend-scoped rule, traceable to its source PRs and retired if the team stops applying it. Keep AGENTS.md and CLAUDE.md as the starting point, because static rule files fail when nobody updates them (Qodo blog).

FAQ

Are review rules the ones in our AGENTS.md and CLAUDE.md files, or separate ones?

Review rules can come from your AGENTS.md and CLAUDE.md files and from rules Qodo mines or you write. Qodo's Rule enforcement imports rules from those files, takes rules you write, and adds rules Rule Miner finds in PR history.

How does a tool learn coding rules from pull request history?

Qodo's Rule Miner reads about the 1,000 most recently merged PRs and counts only comments that developers accepted and that led to code changes. The first run adds up to 10 rules per repository, and runs every two weeks add up to 5 more.

Can we write our own rules, including from a point raised in review?

You write rules in the Qodo portal with a category, severity and scope, including from a point raised in review, and members' rules wait in Pending rules for an admin. When a finding comes from a rule, the PR thread links to the rule, so you can check the rule or fix the code.

Can rules be layered across the org, teams, repositories and paths?

Qodo rules can be layered: global by default or scoped to Git organizations, repositories and path patterns, and a rule imported from src/payments/AGENTS.md applies only under that folder. One scope can list up to 25 organizations and repositories.

How do I make my coding agent follow my team's coding rules?

Give the agent the rules before it writes, then check the result in review. Qodo's Get Rules skill loads your Qodo Rules into a coding agent, and the PR review checks every change against the same rules.

Which AI code review tools support Copilot instructions files?

Several AI code review tools read them, and Copilot code review reads .github/copilot-instructions.md and path-specific instruction files. Qodo imports copilot-instructions.md as rules next to AGENTS.md, CLAUDE.md and .cursor/rules/, and checks every PR against them whichever agent wrote the code.

Best AI Code Review Tools for Multi-Repo Engineering Organizations: Cross-Repo Dependencies and Blast Radius (2026)

Dave Barron — Tue, 27 Oct 2026 01:00:42 +0000

I write about system-level code review for senior and staff engineers, and the hardest breakage to catch is the one that lands in a repository nobody opened. I checked eight AI code review tools against their own docs and pricing pages in October 2026, using one breaking rename in a shared SDK. The ranking follows what each tool does with the stale call that rename leaves behind.

TL;DR

Multi-repo changes break one repository away. A shared-library change passes every check in its own repo and breaks a consumer nobody opened during review.
Agents make the gap wider. 38% of engineering leaders name keeping architecture consistent as one of their biggest gaps as agents take on more of the lifecycle (AI code quality report, August 2026).
Three criteria separate the tools most: which dependency types a reviewer traces, whether linked repos can sit on different Git providers, and how the reviewer rates each change's risk before anyone opens a file.
Qodo is my #1 because it covers dependency types, Git providers and risk before merge. Qodo traces library exports, API contracts, database schemas, config files and pipeline artifacts in both directions and keeps linked repos linked across Git providers. When you turn on blast radius labels, Qodo labels each PR Small, Medium or Large by scope and sensitivity.

The 8 Best AI Code Review Tools for Multi-Repo Organizations

Qodo: best for platform leads tracing impact across repos and Git providers
CodeRabbit: best for a fixed group of linked repos on one platform
Greptile: best for teams that group repos into clusters
GitHub Copilot code review: best for automatic review of single-repo PRs on GitHub.com
Cursor Bugbot: best for bug-focused single-repo review, billed by usage
Graphite: best for developers shipping stacks of small PRs on GitHub
Augment Code: best for teams that declare key dependencies per repo
Gitar: best for org-wide cross-repo scanning on an Enterprise plan

Tool	Best for	How it sees other repos	Git providers for review	Linked repos on different providers?	Plan note, October 2026
Qodo	Platform leads tracing impact across repos and providers	Relationships discovered automatically or defined by the team; impact traced in both directions	GitHub, GitLab, Bitbucket, Azure DevOps	Yes, documented	14-day free trial; Pro Team from $30 a month for 2,500 pooled credits; Enterprise custom
CodeRabbit	A fixed group of linked repos on one platform	Linked repositories added as review context	GitHub, GitLab, Azure DevOps, Bitbucket	No, same platform as the PR	Linked repos by plan: 1 on Essentials, 5 on Team, 10 on Advanced, 20 on Enterprise
Greptile	Teams that group repos into clusters	Repo Clusters read as read-only context	GitHub, GitLab, Bitbucket, Cursor Origin	No, same Git platform as the primary repo	$1 per credit
GitHub Copilot code review	Automatic review of single-repo PRs on GitHub.com	The PR's own repository	GitHub.com, Azure DevOps	Not documented	Part of Copilot plans
Cursor Bugbot	Bug-focused single-repo review, billed by usage	The PR's own repository	GitHub, GitLab, Bitbucket, Azure DevOps, Cursor Origin	Not documented	Usage-based through a Cursor plan
Graphite	Developers shipping stacks of small PRs on GitHub	The PR's own repository	GitHub	Not documented	Starter $20 per user a month, billed annually; Team $40
Augment Code	Teams that declare key dependencies per repo	External repos declared in `AGENTS.md`	GitHub native; others through a CLI setup	Not documented	Code Review on all plans
Gitar	Org-wide cross-repo scanning on an Enterprise plan	Other repos in the organization scanned automatically	Several Git platforms	Yes, documented	Cross-Repo Analysis on Enterprise

Why Multi-Repo Changes Break Outside the Repo You Reviewed

A change in a shared library can pass every check in its own repository and still break a service that nobody opened during review. Multi-repo code review closes the gap between the repo you reviewed and the repo that breaks.

A Shared SDK Rename

Take a shared SDK rename (illustrative). A team changes an exported function in payments-sdk.

- export function createCharge(amountCents: number, currency: string)
+ export function createCharge(input: ChargeInput)

The SDK's own tests pass. checkout-service, in another repository, still calls createCharge(4999, "USD"), and nothing in the SDK PR shows the stale call.

Two repos are related through five kinds of edge: a shared library export, an API contract, a database schema, a config or infrastructure file, and a pipeline artifact. The createCharge rename travels along the library-export edge, and a reviewer that knows only library exports misses a broken API contract, schema, config file or pipeline artifact.

The dependency diagram maps the five edge types between four repositories, with the library-export edge in red.

Agents Change Shared Code Before Anyone Maps Who Uses It

Missing context is what breaks agents across repos. When 25 engineers at mabl ran agents across 75+ repos, context drift caused about 40% of agent failures, and a hand-curated graph of how the repos connect cut agent failures to under 5% (mabl engineering, April 2026).

Cross-repo work is still unreliable for agents. On 500 tasks from 246 GitHub repositories that need knowledge beyond one repository, including cross-repo fixes, the best agent setups scored 46 to 57 out of 100 on average (BeyondSWE, March 2026).

So the cross-repo check has to sit outside the agent that wrote the change, because you shouldn't review code with the same tool that wrote it.

What a Multi-Repo Code Review Tool Has to Know Before Merge

A multi-repo code review tool answers one question before merge: what else does the change touch, and how risky is the change? Five criteria decide the answer, and three of them separate the tools most: dependency types, Git providers and risk level.

The tool traces dependencies in both directions. A signature change breaks callers, and your change can misuse another repo's API. The stale checkout-service call is a broken caller.
The tool knows the dependency type. Exports, contracts, schemas, config files and pipeline artifacts each break in their own way, and the rename is a library-export edge.
The tool discovers relationships and lets you correct them. Nobody maps hundreds of repositories by hand, and no document records that checkout-service calls createCharge.
The tool works across Git providers. Acquisitions bring GitLab next to GitHub, and linked repos on different providers should still count as linked, because checkout-service may not live where payments-sdk does.
The tool rates each change's risk before you open a file. A one-line production database config change can matter more than a 900-line docs update, so the level should weigh scope and sensitivity.

How I Evaluated the Tools

I checked every tool on the five criteria, dependency direction, dependency type, relationship discovery, Git providers and risk rating, using each tool's own docs and pricing pages in October 2026. For every tool I also traced what happens to the stale createCharge(4999, "USD") call.

How the 8 Multi-Repo Code Review Tools Handle One Breaking Rename

1. Qodo: Best for Platform Leads Tracing Impact Across Repos and Git Providers

Tool Overview

Qodo is an AI code review and governance platform for organizations where one change can reach many repositories. Qodo's cross-repo review reads related repositories on every relevant PR and traces impact in both directions. Specialized agents check correctness, standards, architecture and risk in parallel, a judge agent filters their findings, and your team and branch protection decide what merges.

Main Features

Cross-repo review. Qodo discovers relationships automatically or takes them from your team, across Git providers (cross-repo review docs). An agent reads the connected repos for code that depends on the change and code in the PR that conflicts with them, and a breaking change becomes a Cross-repo finding linked to the affected lines, so the developer fixes the change or coordinates with the other team before merge.
Dependency types. A cross-repo review follows each dependency type, such as a shared export, a REST endpoint contract, a database schema, a shared config or infrastructure file and a pipeline artifact.
Blast radius labels. When you turn on blast radius labels, Qodo rates each PR Large, Medium or Small from scope and sensitivity alongside diff size, so reviewers can triage the riskiest PRs first. The label is off by default; switch it on in Configurations or add publish_blast_radius_labels = true under [review_agent] in .pr_agent.toml.
Software Map. The Software Map is a live view of how your repositories connect that shows hubs, service contracts, their consumers and where findings cluster, so platform leads see the whole system in one place.
Cross-repo context inside coding agents. The Agentic Toolbox gives agents a Cross-repo tool group and a Reviewer skill that checks local changes with the PR review engine, both reading from the Qodo Context Engine. Agents can fix cross-repo conflicts before a PR exists.

The impact diagram puts both directions on one PR. Red arrows run from the changed createCharge line to checkout-service and orders-api, which depend on the change, a teal arrow comes from ledger-api, the repo the change misuses, and the Large label marks the PR as high risk.

Best For

Qodo is best for platform leads and architects at organizations with hundreds of repositories, often across Git providers, who need every PR checked against the repos that consume it.

How It Ranked

Qodo traces impact both ways across exports, contracts, schemas, config and pipelines, discovers relationships you can edit, links repos across Git providers and, with labels on, rates each PR's risk. In the createCharge case, the stale createCharge(4999, "USD") call becomes a Cross-repo finding on the SDK PR, linked to the affected line, before anyone merges.

2. CodeRabbit: Best for a Fixed Group of Linked Repos on One Platform

Tool Overview

CodeRabbit is an AI code review tool on GitHub, GitLab, Azure DevOps and Bitbucket that brings other repositories into a review through repos you link on the PR's own Git platform.

Main Features

Multi-Repo Analysis. Linked repositories are read as review context, up to 1 on Essentials, 5 on Team, 10 on Advanced and 20 on Enterprise.
Automatic linking. On Team and higher plans, CodeRabbit can link repos automatically within the plan's limit once you enable the setting, which is off by default.
Impact features on higher plans. Advanced and Enterprise list Blast Radius, which maps the downstream reach of a pull request, and Architecture Impact.

Best For

CodeRabbit is best for teams that want PR feedback on a known, fixed group of related repos, such as a service and the SDKs it consumes, all on one Git platform.

How It Ranked

CodeRabbit reads linked repos as context, within the plan's cap. In the createCharge case, checkout-service is in view once the service is linked to payments-sdk.

3. Greptile: Best for Teams That Group Repos Into Clusters

Tool Overview

Greptile is an AI code review tool for GitHub, GitLab, Bitbucket and Cursor Origin, priced at $1 per credit. Greptile groups related repositories into clusters that every review in the group reads.

Main Features

Repo Clusters. A review in one repository reads the other repos in its cluster as read-only context, so every consumer inside the cluster is part of each review.
File-based configuration. Clusters are defined in .greptile/config.json.

Best For

Greptile is best for teams that can group related repos up front, such as one cluster per product line, and want every review to read the whole cluster.

How It Ranked

Greptile reads the clusters you define, on one Git platform, and the cluster boundary decides what a review sees. In the createCharge case, checkout-service is in view if someone put the service in the SDK's cluster.

4. GitHub Copilot Code Review: Best for Automatic Review of Single-Repo PRs on GitHub.com

Tool Overview

Copilot code review is GitHub's PR reviewer, part of Copilot plans on GitHub.com and also available in Azure DevOps, and each review stays inside the PR's own repository.

Main Features

Automatic review through rulesets. Repository, organization or enterprise rulesets run a review on every PR, so a review happens without anyone requesting one.
Custom instructions. .github/copilot-instructions.md and path-specific instruction files tell each review what to check.

Best For

Copilot code review is best for teams on GitHub.com that want an automatic review pass on single-repo PRs.

How It Ranked

Copilot code review checks each PR inside its own repository. In the createCharge case, the SDK PR gets reviewed and checkout-service stays out of view.

5. Cursor Bugbot: Best for Bug-Focused Single-Repo Review, Billed by Usage

Tool Overview

Bugbot is Cursor's PR reviewer, billed by usage on Cursor's Premium and higher plans, Teams and Enterprise. Bugbot runs on GitHub, GitLab, Bitbucket, Azure DevOps and Cursor Origin, and each review reads the PR's own repository.

Main Features

Review rules. Team Rules and .cursor/BUGBOT.md tell Bugbot what to look for, so findings follow the team's standards.
Merge checks. When configured, Bugbot's PR check fails on unresolved findings, so a bug can block the merge.

Best For

Bugbot is best for teams that want bug-focused review of single-repo PRs, billed by usage through Cursor.

How It Ranked

Bugbot stays inside the PR's own repository. In the createCharge case, a bug inside payments-sdk is in scope, and the stale call in checkout-service stays outside the review.

6. Graphite: Best for Developers Shipping Stacks of Small PRs on GitHub

Tool Overview

Graphite is a code review product built around stacked PRs on GitHub, with Starter at $20 per user a month, billed annually, and Team at $40. Graphite changes how a large change splits into PRs, and each review reads one repository.

Main Features

Stacked PRs. A big change ships as a stack of small dependent PRs, so each review covers a smaller diff.
Merge queue. A merge queue lands the stack in order, in the same workflow as review.

Best For

Graphite is best for developers who ship big changes as stacks of small PRs on GitHub and want review and a merge queue in one workflow.

How It Ranked

Graphite reviews each PR in the stack inside its own repository. In the createCharge case, the rename gets reviewed in small pieces, and checkout-service stays outside every review in the stack.

7. Augment Code: Best for Teams That Declare Key Dependencies per Repo

Tool Overview

Augment's Code Review is one agent inside a coding-agent platform, native on GitHub and on other Git platforms through a CLI-based pipeline. Augment reads other repositories only when a team declares them.

Main Features

Cross Repo Context. Teams declare external repositories in AGENTS.md, and the review reads those repositories as context, so each repo states its own key dependencies.
Plans. Code Review is part of all Augment plans, next to the coding agents.

Best For

Augment Code is best for teams that already know their key dependencies and want to declare them per repo in AGENTS.md.

How It Ranked

Augment's coverage depends on what each team writes down. In the createCharge case, checkout-service is in view once someone declares the service in the SDK repo's AGENTS.md.

8. Gitar: Best for Org-Wide Cross-Repo Scanning on an Enterprise Plan

Tool Overview

Gitar is an AI code review tool with Cross-Repo Analysis on its Enterprise plan. Gitar scans the other repositories in the organization automatically.

Main Features

Org-wide scanning. Cross-Repo Analysis scans other repositories in the organization with no cap on linked repos, so nobody keeps a list by hand.
Mixed Git platforms. Gitar checks a GitHub service against a GitLab client (Gitar docs, October 2026).

Best For

Gitar is best for Enterprise-plan customers who want cross-repo analysis to run across the organization by default.

How It Ranked

Gitar's scope is the whole organization. In the createCharge case, checkout-service is in scope if the service sits in the same organization.

Rolling Out Cross-Repo Review Across Hundreds of Repos

Cross-repo review only works if it reaches every repository, so configure review once for the whole Git organization. Per-repo setup fails at the long tail: the 300th repository never gets configured, and the stale checkout-service call lives in exactly that kind of repo. Qodo applies settings at the Git organization level with per-repo overrides (Qodo changelog, Qodo 3.1, October 2026).

Organization-level setup is how teams with hundreds of repositories already run review. LoopUp configured Qodo at the organization level across its GitHub repos, and Qodo now handles about 90% of the initial review, with humans stepping in for the final 10%, according to CTO Chris Howard (LoopUp case study, April 2026).

How I'd Roll Out Cross-Repo Review

Turn on review at the Git organization level, not repo by repo.
Let automatic discovery propose relationships, then add the ones only your architects know.
Turn on blast radius labels and use them to triage the review queue.
Declare runtime-only edges, such as queues and env-configured URLs, by hand.
Give coding agents the Cross-repo tools so conflicts get fixed before the PR.

Conclusion

Multi-repo code review comes down to whether the reviewer knows what lives on the other side of the change. Pick by the dependency types a tool traces, whether linked repos can sit on different Git providers, and whether the tool rates each PR's risk before anyone opens a file.

Qodo covers dependency types, Git providers and risk rating, so the stale createCharge(4999, "USD") call reaches the SDK author before merge, with a blast radius label once labels are on.

FAQ

What are the best AI code review tools for multi-repo engineering organizations?

Qodo is the best AI code review tool for multi-repo engineering organizations. Judge tools by dependency types, Git providers and risk rating, the three criteria that separate them most (multi-repo code review glossary).

What tool can identify cross-repository dependencies and blast radius before a code change?

Qodo identifies cross-repository dependencies and blast radius before a change merges. Qodo traces impact in both directions across discovered or team-defined relationships. When you turn on blast radius labels, Qodo labels each PR Large, Medium or Small by risk.

What are the best AI code review tools for managing rollout across hundreds of repos?

The best AI code review tools for rollout across hundreds of repos let you configure once for a whole Git organization. Qodo 3.1 applies settings at the Git organization level with per-repo overrides.

What's the best tool for cross-repo context in my coding agent?

Qodo is the best tool for cross-repo context in a coding agent. Qodo's Agentic Toolbox gives agents a Cross-repo tool group through MCP, the CLI and plugins for Claude Code and Codex, so the agent can check what depends on a function while writing.

Does cross-repo review still work at thousands of repositories?

Cross-repo review scales when the reviewer reads the repos a change is related to, not every repo in the organization. Qodo checks a PR against its connected repositories and the blast radius label helps you triage which PRs need the closest review.

Can AI code review catch dependencies that only exist at runtime?

AI code review struggles with dependencies that only exist at runtime, such as a URL in an environment variable or an undeclared queue. In Qodo, you can add a runtime relationship by hand so the other repo is in scope at review.

Claude Code Review is GA: what a base-branch REVIEW.md teaches us about agent standards

Dave Barron — Fri, 16 Oct 2026 16:02:11 +0000

TL;DR

On October 15, 2026, Anthropic moved Code Review for Claude Code out of research preview and made it generally available for Claude Team and Enterprise plans.
The detail devs keep quoting: Claude Code Review reads REVIEW.md from the pull request's base branch or the default branch, never from the PR's own changes. A PR can't loosen the rules it's judged by.
The bigger lesson: an AI reviewer is only as good as the standard you write down, and that standard should be protected, owned, and reviewed like code.
Review time is the last place to apply a standard. Qodo moves the standard upstream: it mines rules from your team's PR history and hands them to the coding agent before it writes a line.

The one line in the docs everyone is quoting

Anthropic's GA post is mostly about speed and tuning. Most reviews now finish in about 6-10 minutes, down from roughly 20 during the preview, and admins pick a Quick, Standard, or Deep review level per repository.

The part developers latched onto is quieter. Here's how Donovan (@shipsatnight) put it on X the day after launch:

"REVIEW.md is read from the base branch, never from the PR. So a PR can't loosen the rules it's being judged by. Want new rules? Merge them first."

That's a small product decision with a big idea inside it. Your review rules are policy, and policy shouldn't be editable by the thing it's checking.

What REVIEW.md controls, and what each instruction needs

REVIEW.md is a freeform Markdown file at your repo root (plus optional subdirectory files) that tells Claude Code Review what to flag, at what severity, and what to skip. Per Anthropic's docs (checked October 16, 2026), some instructions only take effect when the root file sits on a protected default branch.

Instruction in REVIEW.md	Example	What it changes	Needs a protected default branch?
Redefine "Important"	"Important = breaks behavior, leaks data, blocks rollback"	Lowers or raises severity	Yes, for lowering severity
Cap nits	"Report at most five Nits"	Fewer low-value comments	Yes
Skip paths	"Ignore `src/gen/` and `*.lock`"	Excludes files or issue classes	Yes
Always check	"New API routes have an integration test"	Adds a team rule to every PR	Not listed as required
Demand evidence	"Behavior claims need a `file:line` citation"	Cuts false positives	Not listed as required

Every instruction that makes the reviewer quieter depends on branch protection, while instructions that add scrutiny aren't listed with that requirement.

7 lessons a base-branch REVIEW.md teaches about agent standards

1. A rule the PR can edit is only a suggestion

If a reviewer read its rules from the PR branch, any change could ship a friendlier REVIEW.md alongside the code it wants waved through. Reading from the base branch closes that gap: new rules go through their own PR, get reviewed, merge, and only then apply.

This lines up with how the security world now talks about agents. The OWASP Top 10 for Agentic Applications (December 2025) lists agent goal hijack and memory and context poisoning among its top risks. An instructions file that untrusted changes can rewrite fits both descriptions.

Try this: treat every file an agent reads as instructions (REVIEW.md, CLAUDE.md, AGENTS.md, rules files) as config that needs its own review, separate from feature work.

2. Loosening is the risky direction, so it needs the most protection

The diagram shows the flow. Claude Code Review reads REVIEW.md from main, where it can't be pushed to directly. The PR's edited copy, which drops the tenant check and the nit cap, has no effect on that PR's review. For your repo, that means protecting the branch first and writing the rules second.

Anthropic's docs spell out the fallback cases too. With no protection on either the default or the base branch, the review reads only the root file. If Code Review can't confirm the protection settings at all, it reads no REVIEW.md. In both cases the check run carries a message about it, so read it once after setup.

3. AI review quality tracks the standard you actually wrote down

Out of the box, Claude Code Review focuses on correctness: bugs that would break production. Everything team-specific (your tenancy model, your logging rules, which folders are generated) has to come from you.

Liz Fong-Jones made the same point on Qodo's The Agentic Review podcast (episode "Is AI Making You an Average Engineer?", September 30, 2026): "you have to deliberately defend your codebase," and "I think making your standards written down is a positive side effect of this."

Most teams aren't there yet. In Qodo's State of AI Code Quality 2026 survey, 41.7% of 300 U.S. engineering leaders reported centralized AI coding standards, and 37.0% could enforce policy across teams and repositories. Among 500 U.S. developers, 34.6% said agents always follow organizational standards.

The chart puts the gap in one picture. The same 300 leaders who report 87% confidence that standards are consistent across AI tools mostly lack the centralized standards and cross-repo enforcement behind that confidence. The developer bar comes from a separate sample, so read it on its own. Both groups work at U.S. organizations already using AI meaningfully in the software development lifecycle (SDLC), so this isn't a picture of every company.

4. Be specific, because the bot will follow the letter of the rule

Liz has a great line about this from the same episode: "the bot will happily, you know, work to rule and do exactly what you told it rather than what you meant." A rule like "review for quality" gives a reviewer nothing to check. A rule like "queries must be scoped to the caller's tenant" does.

Here's a starter REVIEW.md for a backend service, adapted from the structure in Anthropic's docs:

# Review instructions

## What Important means here
Reserve Important for findings that break behavior, leak data,
or block a rollback: wrong logic, unscoped database queries,
PII in logs, migrations that aren't backward compatible.
Naming and refactoring ideas are Nit at most.

## Cap the nits
Report at most five Nits per review.

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file

## Always check
- New API routes have an integration test
- Log lines never include email addresses or request bodies
- Database queries are scoped to the caller's tenant

## Evidence
Behavior claims need a `file:line` citation, not a guess from a name.

Each section maps to one decision. "What Important means here" calibrates severity, "Do not report" cuts noise that CI already handles, "Always check" encodes the rules a senior reviewer would otherwise repeat by hand, and "Evidence" pushes back on confident-sounding false positives.

5. Standards rot unless a named person owns them

A rules file has no tests, so nothing fails when it drifts out of date.

Emilie Schario described this on The Agentic Review (episode "What Engineering Organizations Get Wrong About AI Adoption", September 2026). An engineering leader told her a team's CLAUDE.md had its last commit 12 months earlier. Her take: "you wouldn't think that, like, you buy silverware once and it's gonna be good forever. Right? You have to wash it every time you use it."

Try this: add REVIEW.md and your agent instruction files to CODEOWNERS, so a tech lead signs off on every change. Put a recurring reminder on the calendar to prune rules nobody has triggered in a quarter.

6. One standard copied into five places turns into five standards

Qodo's report describes the drift problem well: "A security requirement may be documented in a wiki, summarized in a repository file, partially encoded in CI, inferred from review history, and paraphrased again inside a prompt. Each version may express a slightly different interpretation of the same standard."

The same survey asked how standards reach the agent: 43.8% of respondents named repository-level instruction files, 41.4% code review history, and 26.0% rules manually added to prompts. The shares add up to well over 100%, so plenty of teams run several channels at once.

Anthropic's own split helps here. CLAUDE.md holds project context that Claude Code reads for every task, reviews included. REVIEW.md holds review-only rules. Agent instruction files are also converging: the Linux Foundation's Agentic AI Foundation took on AGENTS.md in December 2025 as a shared format for project guidance. Pick one source of truth per rule, and link to it from everywhere else.

7. Review time is the latest point to apply a standard, so teach the agent first

The diagram splits the loop into "teach" and "check." REVIEW.md lives on the right side: it judges code that already exists. Every violation it catches is work an agent already did and someone now has to redo. The left side is where the same rule is cheaper, inside the agent's context before the first line gets written.

This is the part we work on at Qodo, and the short version is "teach the agent the standard, don't just catch it after." Qodo's Rule Miner (beta on GitHub, GitLab, and Azure DevOps) reads review comments your team accepted and acted on, turns recurring ones into rules, and links each rule back to the PRs it came from. The Get Rules skill (research preview) lets Claude Code, Codex, or any MCP client load the rules that apply to a task before implementation starts. Qodo's review reads your REVIEW.md (research preview) too, so one file drives both the agent writing the code and the reviewer checking it.

You don't need any tool to start, though. Take the five review comments you typed most often last month and write them into REVIEW.md this week. For more habits that hold up with agents in the loop, see these code review best practices.

Where each kind of standard should live

Kind of standard	Best home	Who can change it	Applied when
Formatting, lint, types	Linters and CI	Anyone, through a reviewed PR	Every commit
Project context (stack, conventions, goals)	`CLAUDE.md` or `AGENTS.md`	Code owners	While the agent writes code, and as review context
Review severity, nit caps, skip lists	`REVIEW.md` on a protected default branch	Code owners, merged before it applies	At PR review
Patterns your reviewers keep repeating	Rules mined from PR history, each linked to source PRs	Team admins approve or dismiss	Before generation and at review
Security and data rules	CI checks plus an "Always check" section in `REVIEW.md`	Security and code owners	Every PR, with human sign-off

The table works as a quick audit. If a rule only exists in someone's head or in a single prompt, it has no owner and no protection yet.

Wrap-up

The base-branch rule is a nice reminder that the boring parts of review (who can change the rules, and when) matter as much as the model. Protect the file, give it an owner, keep it specific, and get the same standard in front of the agent before it writes the code you'll later review.

What's rule one in your REVIEW.md? Drop it in the comments.

FAQ

What is Claude Code Review?

Claude Code Review is Anthropic's managed pull request reviewer for GitHub, generally available since October 15, 2026, for Claude Team and Enterprise plans. Several agents read each change, a verification step filters false positives, and findings land as inline comments. It never approves or blocks a PR. For teams whose code spans GitLab, Bitbucket, Azure DevOps, or Gerrit, Qodo runs one consistent review across every provider.

Why does Claude Code Review read REVIEW.md from the base branch?

Claude Code Review reads REVIEW.md from the base or default branch so a pull request can't change the rules used to judge it. To change review behavior, you merge the REVIEW.md change first. Qodo's docs recommend the same discipline for its REVIEW.md support: add the file in its own PR so the rule change gets reviewed on its own.

What is the difference between REVIEW.md and CLAUDE.md?

CLAUDE.md holds project instructions Claude Code reads for every task, reviews included. REVIEW.md holds review-only rules: severity, nit caps, paths to skip, and checks to always run. The local /code-review command reads CLAUDE.md, not REVIEW.md. Qodo can import rules from existing guideline files and apply them in both coding agents and review.

What should go in a REVIEW.md file?

A REVIEW.md file should define what counts as Important, cap nits, list paths and checks CI already covers, add the team rules a senior reviewer repeats, and require evidence for behavior claims. Keep it short and specific. Qodo's Rule Miner can suggest rules from comments your reviewers already accepted.

How do you keep AI code review standards consistent across coding agents?

Keeping AI code review standards consistent across coding agents starts with one source of truth per rule, a named owner, and branch protection on instruction files. Then feed the same rules to the agent while it writes code and to the reviewer at the PR. Qodo's Get Rules skill (research preview) loads team rules into Claude Code, Codex, or MCP clients before implementation.

Does REVIEW.md replace human code review?

REVIEW.md does not replace human code review. Claude Code Review never approves or blocks a pull request, so the merge decision stays with your team. REVIEW.md just makes the AI pass quieter and more relevant. Qodo keeps people in charge and learns from them: humans accept or dismiss findings, and when reviewers keep dismissing what a mined rule flags, Qodo lowers that rule's weight over time.