# aicodereview.io — full content > The 2026 engineering standard for evaluating AI Code Review tools. Sponsored by Kodus (https://kodus.io); methodology at https://aicodereview.io/about/. --- # Part 1: The 9 Standards # Multi-dimensional Context: The end of hallucinations Reviewing a Pull Request by exclusively reading the `git diff` is an amateur approach. It is the equivalent of reviewing a chapter of a book without knowing the plot or the characters. Most first-generation AI code reviewers fail spectacularly because they lack *Multi-dimensional Context*. They operate in a vacuum. ## The Cost of Diff-only Analysis When an AI is constrained to the changed lines (`diff`), the following anti-patterns emerge: - **Hallucinated Functions:** The AI suggests calling a helper function from a standard library that your repository doesn't even use. - **Dependency Breaks:** The AI suggests an "optimization" that accidentally introduces a circular dependency because it cannot see the import tree. - **Style Inconsistencies:** The AI enforces generic Python/TypeScript styles instead of reading your `CONTRIBUTING.md` or existing files to understand the team's established conventions. ## The 2026 Standard for Context A production-grade AI code reviewer must operate across three distinct dimensions of context: ### 1. The Repository Dimension The tool must index the entire repository. When a developer modifies an interface in `src/types/user.ts`, the AI must instantly know all the services and controllers that implement or consume that interface across the codebase. ### 2. The Multi-repo / Enterprise Dimension In modern microservices architectures or large enterprise monorepos, context rarely lives in a single folder. The AI must be able to resolve cross-repository dependencies. If an API contract changes in the `backend-core` repository, the AI reviewing the `frontend-web` repository must be aware of that new contract. ### 3. The Business Logic Dimension (via MCP) Code exists to solve business problems. Validating syntax is the easy part. The AI must connect to your issue tracker (Jira, Linear) or documentation wiki (Notion, Confluence) via the **Model Context Protocol (MCP)**. Before the AI approves a Pull Request, it must validate the code against the original ticket: *"Does this implementation actually fulfill the acceptance criteria described in ticket ENG-104?"* --- **Bottom line:** If your AI code reviewer doesn't understand your entire repository and the business logic behind the change, you are paying for an expensive syntax highlighter. Demand context. # Rule-Centric & Default Quiet: The end of AI nitpicking If an AI comments on indentation, variable naming conventions, or missing semicolons, it should be uninstalled immediately. That is a linter's job, not an intelligence's job. First-generation AI code reviewers suffer from a critical flaw: **they are too eager to please.** Because they want to prove they are working, they leave dozens of trivial comments on every Pull Request. This generates immediate alert fatigue. Engineers learn to click "Resolve All" without reading, defeating the entire purpose of the review. ## The "Default Quiet" Philosophy A production-grade AI must adhere to the **Default Quiet** philosophy. Unless it detects a critical issue (e.g., a security vulnerability or a severe logic flaw), the AI should not comment on a Pull Request. **Every stylistic or architectural opinion must be backed by an explicit team rule.** The AI must enforce the company's standard, not the standard it (or its foundational model) thinks is best. ## Managing Rules as Code To achieve this, the AI must be **Rule-Centric**. 1. **Centralized Standards:** Rules should be defined in plain text (e.g., a `.kodyrules` file or `CONTRIBUTING.md`) and version-controlled alongside the code. 2. **Contextual Enforcement:** The AI must read these rules and use them as the absolute source of truth for its review context. 3. **No Unprompted Opinions:** If the team hasn't explicitly forbidden a pattern (and it isn't an objective bug), the AI must remain silent. A quiet PR is a good PR. Let the AI focus on the deep architectural flaws that linters cannot catch. # Dual-Workflow: The split between Feedback and Control Treating the IDE (Local) and the Pull Request (Remote) as the exact same environment is a fundamental design flaw in modern AI tooling. They serve entirely different purposes in the software development lifecycle. A production-grade AI code reviewer must adapt its behavior depending on *where* the review is happening. ## Local (The Fast Loop) The local environment (your IDE, terminal, or pre-commit hooks) is about **continuous feedback and exploration**. Here, the developer has a low cognitive load. They are actively shaping the code. If an AI suggests a different architectural approach or a clever refactor, the developer can easily hit `Tab` to accept it or ignore it without consequence. - **AI Behavior:** Verbose, opinionated, exploratory. - **Goal:** Help the developer write better code *before* it leaves their machine. ## PR (The Guardrails) The Pull Request environment is about **quality control, security, and business alignment**. By the time code reaches a PR, the developer considers the work "done". Fixing core architectural mistakes here is expensive, frustrating, and creates friction between teammates. The PR is not the place for brainstorming; it is the place for verification. - **AI Behavior:** Restricted, surgical, Default Quiet. Absolutely zero nitpicks. - **Goal:** Ensure the code meets the team's explicit rules, contains no critical bugs, and fulfills the business intent. An AI tool that doesn't respect the boundary between the Fast Loop and the Guardrails will eventually be disabled by frustrated engineers. # Business Logic Validation: Beyond Syntax Validating if code compiles is a solved problem. We have compilers, type checkers, and linters for that. The real challenge in software engineering is ensuring that the code actually solves the business problem it was intended to solve. A syntactically perfect function is worse than useless if it implements the wrong feature. ## The Vacuum of the Diff Most AI reviewers operate in a vacuum. They look at the code and say: *"This loop is O(N^2), you should use a Hash Map to make it O(N)."* That's a nice observation, but what if the array never has more than 10 items, and the real issue is that the function doesn't handle the edge case described in the Jira ticket? The AI completely missed the point because it lacked **Business Context**. ## The Model Context Protocol (MCP) To achieve the 2026 standard, an AI code reviewer must integrate deeply with the tools where business decisions are made (Jira, Linear, Notion, Confluence, GitHub Issues). This is achieved via standards like the **Model Context Protocol (MCP)**. Before the AI approves a Pull Request or suggests a change, it must: 1. Identify the ticket or issue associated with the branch/PR. 2. Read the acceptance criteria and product requirements from that ticket. 3. Validate the code against the *intent* of the developer. *"Does this implementation actually fulfill the acceptance criteria described in ticket ENG-104?"* If the AI cannot answer that question, it is not a reviewer; it is just an automated syntax checker. # Continuous Learning & Regression Prevention The fastest way to destroy an engineering team's trust in an AI tool is to force them to correct the same mistake twice. If a senior engineer tells a junior engineer, *"We don't use the `moment.js` library here, we use `date-fns`,"* the junior engineer learns. If an AI suggests using `moment.js` on Monday, gets rejected, and suggests it again on Wednesday, it becomes an annoyance. ## The Static Prompt Problem Most AI reviewers rely on static system prompts. They don't have a mechanism to learn from the specific dynamics, preferences, and historical decisions of your engineering team. ## The Standard: Dynamic Memory A mature AI code reviewer must treat the Pull Request history as its primary training data for your specific repository. 1. **Rejection Analysis:** When a developer rejects an AI suggestion, the tool must analyze *why* it was rejected and update its internal context (or propose a new team rule) to never make that suggestion again. 2. **Approval Analysis:** When a developer approves a suggestion, the tool reinforces that pattern. 3. **Regression Prevention:** The AI should index past post-mortem reports and resolved high-severity bugs. If a developer introduces code that looks structurally similar to a bug that caused an outage six months ago, the AI must flag it instantly. The AI should grow smarter alongside your team, effectively becoming a repository of institutional memory. # Dynamic Testing & Sandbox Validation Static analysis has hard limits. An AI can read a piece of code and logically deduce that it *should* work, but until that code is executed, it remains a hypothesis. A critical failure mode of AI-generated code suggestions is that they often compile perfectly but break the interface, violate an API contract, or fail under specific runtime conditions. ## Beyond Static Analysis The 2026 baseline demands that AI reviewers move beyond static text analysis and enter the realm of **Dynamic Validation**. Before an AI confidently suggests a complex refactor or approves a high-risk Pull Request, it must be able to prove that its assumptions hold up at runtime. ## The Execution Standard 1. **Preview Environments:** The AI must be capable of interacting with ephemeral preview environments (e.g., Vercel Previews, temporary Docker containers). 2. **Automated Test Generation:** If the AI suggests a fix, it must also generate the unit test that proves the fix works. A suggestion without a verifying test is incomplete. 3. **Chaos Testing:** For critical infrastructure changes, the AI should be able to simulate edge cases—network latency, malformed JSON payloads, null pointers—against the sandbox environment to ensure the new code handles failures gracefully. Don't trust an AI that only reads code. Trust an AI that can run it. # Economic Transparency & Model Independence The AI tooling market is currently flooded with "Wrappers"—companies that build a thin UI layer over OpenAI's API, hardcode a system prompt, and charge an exorbitant markup for the underlying tokens. This model is fundamentally misaligned with the needs of a scaling engineering team. ## The Wrapper Tax Paying $20 to $50 per month, per seat, for a tool that makes $0.50 worth of LLM API calls is burning engineering budget. It limits adoption because Engineering Managers cannot justify the cost for the entire organization, leading to fragmented tooling where only some developers have access to the AI reviewer. ## The 2026 Economic Standard A mature AI code reviewer platform must operate with absolute economic transparency: 1. **Zero Markup:** The platform's revenue should come from the value of its workflow integration, context management, and features—not from reselling LLM tokens. You should pay the AI provider (OpenAI, Anthropic, Google) at their base cost. 2. **Bring Your Own Key (BYOK):** Enterprise teams must be able to plug in their own API keys or route traffic through their own secure proxies (e.g., Azure OpenAI) to satisfy InfoSec requirements. 3. **Model Independence:** You must have the freedom to route different tasks to different models. You might want to use Claude 3.5 Sonnet for deep architectural analysis, but route simple documentation checks to a faster, cheaper model like Llama 3 or GPT-4o-mini. The tool cannot lock you into a single provider. Demand transparency. If a vendor won't tell you exactly how many tokens they are consuming and what they are charging for them, they are a wrapper. # Actionability: Zero-Friction Remediation There is a fundamental difference between an auditor and an engineer. An auditor points out what is wrong; an engineer fixes it. First-generation AI code reviewers act as auditors. They leave brilliant, five-paragraph comments explaining why a function is inefficient or why a database query might cause a bottleneck. The developer reads the comment, sighs, switches back to their IDE, rewrites the function, runs the tests, and pushes a new commit. The AI didn't save time; it created an administrative chore. ## The Rule of the Commit A production-grade AI reviewer must adhere to a strict standard of **Actionability**: > **If the AI cannot generate the exact code (`git diff`) required to fix the issue it found, it should not leave a comment.** ## The 2026 Standard for Remediation 1. **One-Click Commits:** Every suggestion must be a valid, syntactically correct code block that the developer can accept directly from the Pull Request interface with a single click. 2. **Context-Aware Fixes:** The suggested fix must respect the surrounding code. If the AI suggests replacing a standard loop with a utility function, it must ensure that utility function is actually imported at the top of the file. 3. **Automated Tech Debt Tracking:** If an AI suggestion is valid but the developer chooses to ignore it to merge the PR faster (e.g., a non-critical refactor), the AI must automatically convert that ignored suggestion into a trackable issue (Jira/Linear) in the technical debt backlog. We don't need more AI assistants explaining programming concepts in our Pull Requests. We need AI teammates that write the code to fix the problems they find. # Measurable ROI: The Observability Layer When an Engineering Manager decides to adopt an AI code review tool, they are making a financial investment. Six months later, when the CFO asks, *"Is that AI tool actually helping the engineering team?"*, the answer cannot be, *"I think so, the team seems to like it."* Gut feelings do not sustain software budgets. ## The Problem with Invisible Tooling Most AI developer tools operate as black boxes. They consume tokens and spit out code, but they offer zero visibility into their systemic impact on the engineering organization. Are developers accepting the AI's suggestions, or are they ignoring 90% of them? Is the tool actually reducing the time it takes to merge a Pull Request, or is it adding review friction? ## The 2026 Standard for Observability A mature AI platform must include an **Engineering Cockpit**—an observability layer that mathematically proves its Return on Investment (ROI) in real-time. The tool must track and report on core engineering metrics (like DORA): 1. **Cycle Time Velocity:** Has the average time from the first commit to the PR merge decreased since the tool was introduced? 2. **Acceptance Rate (Signal-to-Noise):** What percentage of the AI's generated code is actually committed to the main branch? A high rejection rate means the AI's rules need tuning. 3. **Escape Rate Reduction:** Is the AI actually catching bugs? The platform should correlate the number of issues caught in the PR phase with a reduction of bugs reported in the production environment. 4. **Economic Telemetry:** Real-time visibility into the cost-per-PR based on token usage (linking back to the [Economic Transparency](/standards/07-economic-transparency) pillar). If an AI tool cannot show you a dashboard proving that it is making your team faster and your code safer, it is a toy, not an enterprise investment. --- # Part 2: Blog # AI code review benchmarks: offline vs online evals > How Martian's Code Review Bench separates reproducible fixed-dataset evals from streaming real-world evals, and the tradeoffs hidden in each. Every AI code review vendor now publishes a benchmark where they win. Most of them are "we tested our own tool and it's great" documents. Martian took a different route with Code Review Bench, and the split between its two evals is worth understanding, because it exposes a real tension in how we grade these tools. ## The offline benchmark: fixed dataset, reproducible Fifty PRs, five open-source projects, human-verified golden comments. Sentry (Python), Grafana (Go), Cal.com (TypeScript), Discourse (Ruby), Keycloak (Java). Each golden comment carries a severity label, and an LLM judge decides whether a tool's comment describes the same underlying issue as a golden one. Standard precision and recall from there. The strong part is that it's reproducible. The PRs, the goldens, the judge prompts, the whole pipeline are all in an MIT-licensed repo. You can run it on your own stack, add a tool in an afternoon, and compare against the same fixed ground truth. That instantly beats the closed "we benchmarked ourselves" pages most vendors ship. The weak part is flagged right in their own README: **static datasets risk training data leakage**. The tools have almost certainly seen Sentry or Discourse in training. A tool could look great on this eval and have never learned a general "catch bugs" skill. ## The online benchmark: fresh PRs, recall as a proxy That's why they run a second, online eval. It streams real, recent PRs from GitHub where review bots commented, then does a three-step job: extract the bot's suggestions, extract what the developer actually fixed in post-review commits, and judge how many bot suggestions map to real fixes. Now precision and recall mean something different. Precision is "comments the dev acted on," and recall is "real fixes the dev made that the bot caught." It avoids leakage because the PRs are too fresh to be memorized. ## Where it gets interesting In both evals, the "judge" is an LLM matching whether two descriptions are the same underlying issue. The offline side mitigates this by storing per-judge-model results, and they report which model scored what. That's honest. The online side has a quieter assumption: **developer action is treated as evidence that a comment was correct**. A dev can merge a suggested fix because it's low-risk and they were about to refactor anyway, or reject a correct comment because they don't have time. Recall here is a proxy for "comments people acted on," not a clean measure of "comments that were right." It's a reasonable proxy, but it's a proxy. For anyone picking a reviewer, the practical reading is simple. Skim the offline results to confirm a tool doesn't embarrass itself on a held-out set you can inspect, then trust the online time series for real-world signal, because fresh PRs can't be gamed by memorization. And read which judge model produced the numbers. If a vendor won't tell you, treat the score as marketing. Run the benchmark yourself. The whole thing is open, which is more than most tool vendors can say about their own evals. # Reproducing zizmor's flag on the Snowflake injection > I ran zizmor 1.29.0 against the exact Snowflake GitHub Actions workflow. A deterministic static rule flagged the injection at High confidence while AI review cleared it. The public Snowflake incident is a useful test case for one question I keep coming back to: in a mixed workflow with both deterministic static analyzers and AI review, which one actually catches the injection? I decided to find out empirically instead of arguing from vibes. I pulled the exact vulnerable workflow pattern and ran zizmor 1.29.0 against it in a sandbox. Result: it flags the injection line. Rule `template-injection`, description "code injection via template expansion", High confidence / High severity, pointing at `jira_issue.yml:24:29` and naming `github.event.issue.title` as attacker-controllable input that can expand into a command. It reproduces with a plain `zizmor --quiet` run; the JSON output carries the same finding. Here is the boring mechanics of the bug, because that is the part worth understanding and it is checkable by eye: The workflow interpolates the issue title directly into a shell script: ``` run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\'/g") ``` The sed escaping runs after GitHub's `${{ }}` template expansion, not before. A single quote in the issue title breaks out of `echo '...'` and reaches the shell. That is the escape-ordering bug: you cannot escape a value that has already been interpolated into an execution context. Two structural bugs are worth separating because they fail at different layers: 1. Escape-ordering. The sanitizer runs after the expansion that made the value dangerous, so it is pure theater. This is structural, not a model failure, and you do not need AI to explain it. A linter rule can and does catch it. 2. The protective `if:` guard does not match the actual invocation path. A guard that only makes sense for a handler it never fires for is dead weight. Again fully statically checkable. The part I found notable: this is the same workflow that GH Advanced Security scanned and did not flag, and an AI autofix was associated with the same PR in a related file. So you get a clean A/B in the wild: a deterministic rule with an autofix caught the exact dangerous line, while the AI-assisted layer shipped a fix elsewhere in the same change. That is not a claim that static analysis replaces code review. It is a claim about layering and about test selection. If you have a static analyzer that flags `${{ }}` interpolation into `run:` with High confidence, that is reproducible evidence a given PR needs a human or an AI read on that specific line. The value of the deterministic layer is that it nominates the exact places where judgement is required. The reproducibility point is the one I want to keep: every claim here was derived by running a pinned tool version against a known input, not by reading a vendor's marketing page. That is the standard I would like the rest of the field held to. If a review tool claims it catches script injection, ask for the flag it produces on this workflow. It either names the line or it does not. # Netlify tested 11 coding models side by side > Netlify ran the same build prompt across 11 AI models using their open-source AXIS evaluator. Here is what the results tell us about model selection for code generation. Netlify published an experiment this week that more teams should run. They tested 11 different AI models on the same three coding prompts, using their open-source AXIS evaluation tool to score the results. Same task, same agent framework, same evaluation criteria. Only the model changed. The test covered three scenarios: a static coffee-shop site, a to-do list app with a database, and a recipe app that calls an AI inference API. Each model ran three times per prompt. The results are published at the-coffee-shop-brief.netlify.app for anyone to inspect. Some things that stood out. **Cost variance was wide** On the simple coffee-shop site, average credit cost ranged from 103 (Gemini 3.6 Flash) to 519 (Claude Opus 5). That is a 5x difference for a static one-pager. The gap would shrink on harder tasks where cheaper models fail more and require retries, but for straightforward work the cost spread is real. **Output quality was not uniform** While Netlify focused on functional correctness rather than aesthetics, the generated sites differed meaningfully. Some models picked a reasonable color palette and layout; others produced broken navigation or misused database primitives. The full report includes links to each generated site so you can judge visually. **Structured evaluation beats vibes** Netlify used their AXIS framework, which defines pass/fail checks programmatically (does the site use a database when needed, does it call the right API, is the site over-engineered). This catches regressions that manual review would miss. AXIS is open-source, so teams can adapt it to their own standards. The practical takeaway: model selection for code generation should be an empirical choice, not a brand preference. Run your prompts on 3-5 models. Measure pass rates and cost. The results will surprise you. Netlify's post hinted at follow-ups covering the harder scenarios. I will run the same methodology on my own test suite and report back with numbers. # AI Code Review vs Static Analysis: 2026 Guide > AI code review vs static analysis compared: determinism vs reasoning, false positives, SAST coverage, cost, and why mature teams run both. AI code review and static analysis solve different problems, and the honest answer to "which one?" is that mature teams run both. Static analysis parses your code into formal structures — syntax trees, control-flow and dataflow graphs — and checks them against deterministic rules: same input, same findings, every run, with the ability to prove a pattern is absent. AI code review feeds the diff plus surrounding context to a large language model that reasons about what the change is trying to do — catching logic errors, broken invariants, and intent mismatches no rule can express, at the cost of determinism. One is a proof engine with a bounded rulebook; the other is a judgment engine with unbounded scope and probabilistic reliability. This is a technical comparison, not a category pitch: how each actually works, how their false positives differ in kind, what the security benchmarks really show, what each costs, and how to stack them. Tools named on both sides — SonarQube, Semgrep, and CodeQL for static analysis; CodeRabbit, Kodus, and Greptile for AI review. ## How static analysis actually works Static analyzers never execute your code. They build formal representations and query them: - **AST matching.** The cheapest layer: parse the code, walk the tree, flag structural patterns. Most linter rules and a large share of [Semgrep's registry](https://github.com/semgrep/semgrep-rules) — thousands of community rules across 30+ languages — operate here. Fast enough to run on every keystroke. - **Dataflow and taint analysis.** The layer that makes SAST useful for security: track how values propagate from *sources* (user input, network reads) to *sinks* (SQL execution, HTML rendering, shell calls) and flag flows that skip sanitization. [CodeQL](https://codeql.github.com/), which powers GitHub code scanning, treats code as a queryable database and expresses these flows as declarative queries; Semgrep's cross-file dataflow and [SonarQube's](https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/languages/overview) injection analyzers do the same within their engines. - **Symbolic and abstract interpretation.** The deep end — reasoning about all possible values a variable could take. Powerful, expensive, and where analysis-time budgets go to die on large codebases. Three properties fall out of this design, and they're the ones AI cannot replicate. **Determinism:** a finding today is a finding tomorrow; CI gates can be built on it. **Provable absence:** "no `eval` calls exist in this codebase" is a statement a static tool can actually make. **Auditability:** every finding traces to a specific rule with a documented CWE mapping, which is what compliance frameworks consume. The structural limitation is the same property inverted: a static analyzer can only flag what someone wrote a rule for. An inverted discount calculation, a retry loop without backoff, an authorization check missing from one endpoint out of five — all syntactically unremarkable, all invisible to any rulebook, all exactly the bugs that reach production. ## How AI code review actually works An LLM-based reviewer — [CodeRabbit, Greptile, Kodus, Cursor Bugbot, and the rest of the field](/blog/best-ai-code-review-tools) — runs a different pipeline: ingest the PR diff, assemble context (surrounding files, symbol graphs, linked tickets, team rules), prompt one or more models to reason about the change, then filter and rank the candidate findings before posting line comments. The two stages that differentiate tools are context and filtering. Context, because the diff alone can't tell you a signature change breaks a caller three directories away — this is the argument for [multi-dimensional context](/standards/01-multi-dimensional-context) as a first-class requirement, and it's backed by field data: in [Qodo's 2025 survey of 609 developers](https://www.qodo.ai/reports/state-of-ai-code-quality/), 65% named missing context as AI's top failure during review-critical tasks. Filtering, because raw LLM output includes hallucinations, and the strongest pipelines [validate findings in a sandbox before a human ever sees them](/standards/06-sandbox-validation). What you gain is scope: reasoning about intent ("the ticket says backoff, the code busy-waits"), cross-file consistency, [business-logic correctness](/standards/04-business-logic), and novel bug classes with no CVE and no rule. What you give up is every guarantee in the previous section. Run the same reviewer twice on the same diff and you may get different findings. Nothing can be proven absent. And a finding's justification is a paragraph of generated prose, not a rule ID an auditor can cite. ## Determinism vs reasoning: the actual trade It's worth being precise about what non-determinism costs, because it's the fault line the whole comparison sits on. A deterministic tool can be a **contract**. You can gate merges on it, write exceptions against specific rule IDs, diff its output between releases, and hand its configuration to an auditor. Its false positives are *systematic* — annoying, but fixable once, permanently, per rule. A probabilistic tool is a **colleague**. It can be brilliant about things no contract anticipated and confidently wrong about things a contract would have caught. Its findings need the same treatment as a human reviewer's: evaluated, sometimes pushed back on. The [ICSE 2025 industrial study of an LLM reviewer](https://arxiv.org/abs/2412.18531) across 4,335 PRs captures both halves — 73.8% of the AI's comments were resolved by developers (high signal), yet average PR closure time rose from 5 hours 52 minutes to 8 hours 20 minutes (real cost), and practitioners' main complaints were faulty reviews and irrelevant comments (the colleague being wrong). The mistake teams make is applying one category's mental model to the other: gating merges on a probabilistic tool's unfiltered output, or expecting a rulebook to catch logic bugs. ## False positive profiles: different shapes of wrong Both tool families produce false positives; they produce them *differently*, and the difference dictates how you manage them. **Static analysis: systematic, tunable, front-loaded.** An over-broad rule fires on every matching pattern in the codebase, immediately, on day one. The industry's benchmark for what's tolerable comes from Google: their Tricorder platform enforced that [any check surfaced at review time must stay under a 10% effective false-positive rate](https://cacm.acm.org/research/lessons-from-building-static-analysis-tools-at-google/) — where "effective" means the *developer* judged it useless, regardless of technical correctness — or the check gets removed. That paper's core insight transfers directly to AI tools: developers, not vendors, define what counts as a false positive, and they stop reading tools that waste their time. **AI review: unpredictable, per-finding, ongoing.** There is no rule to suppress; each hallucinated bug or irrelevant suggestion is its own event. The empirical picture, as of August 2026, is wide variance with a good ceiling: an [independent 3.5-week field test running four AI reviewers in parallel on 146 production PRs](https://dev.to/_vjk/best-ai-code-reviewer-in-2026-we-ran-4-in-parallel-for-3-weeks-146-prs-679-findings-1c0f) (679 findings total) measured false-positive rates of roughly 0% for Greptile, 2.3% for CodeRabbit, and 4.8% for Bugbot with default configs — well under Google's 10% bar — while other tools' rates climbed to 15% in some severity tiers. The same test's most striking result: 93.4% of all findings were caught by exactly one of the four tools. AI reviewers barely overlap, which says the space of catchable issues is much larger than any single tool's coverage. The operational consequence: static-analysis noise is a *configuration debt* you pay down once; AI-review noise is a *per-PR tax* you can only control by choosing tools that filter aggressively and by [measuring resolution rates continuously](/standards/09-measurable-roi). ## Security coverage: what SAST does that AI doesn't (yet) Security is where the determinism trade bites hardest, and where marketing outruns evidence most often. The strongest public evidence comes from the [OpenSSF CVE Benchmark](https://github.com/ossf-cve-benchmark/ossf-cve-benchmark) — 200+ real, historical CVEs from real codebases, built specifically to test whether tools catch vulnerabilities that actually shipped. On a [2026 evaluation run against 165 of those CVEs](https://deepsource.com/benchmarks), F1 scores across AI-era review tools ranged from 84.5% at the top to the mid-30s for some of the most popular tools — a spread wide enough that the category label tells you nothing. Note the evaluator (DeepSource) is itself a vendor that finished first on its own run; the dataset is real and public, but the caveat from the next section applies. Meanwhile the demand side of the problem is well documented: [Veracode's 2025 GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/) found LLMs introduced vulnerabilities in 45% of coding tasks across 100+ models (Java worst at a 72% failure rate), consistent with the NYU "[Asleep at the Keyboard](https://arxiv.org/abs/2108.09293)" result that roughly 40% of Copilot-generated programs in security-relevant scenarios were vulnerable. More AI-generated code means more injected vulnerabilities per week, which is precisely the workload SAST's taint engines were built for. The convergence point is real, though: GitHub's [Copilot Autofix](https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/) layers an LLM *on top of* CodeQL findings — deterministic detection, AI-generated remediation — and GitHub's customer data showed median fix time dropping from 1.5 hours to 28 minutes, with SQL injection fixes 12x faster. That architecture (SAST finds, AI fixes and explains) is likely the durable shape of the security stack, not one side replacing the other. For compliance, the answer is not close: SOC 2, PCI-DSS, and internal security programs are built on auditable, reproducible scans mapped to CWEs. A probabilistic reviewer cannot produce an artifact that says "we scanned for the OWASP Top 10 and here is the evidence." ## Cost: two different bills | Cost component | Static analysis | AI code review | |---|---|---| | Licensing | OSS free (Semgrep CE, SonarQube CE, CodeQL for OSS); commercial tiers per-seat | Per-seat SaaS, typically priced like a mid-tier dev tool; open-source options ([Kodus](https://kodus.io)) self-hostable | | Compute | Your CI minutes; deep interprocedural analysis can get slow on large repos | Vendor-side LLM inference baked into subscription, or your own tokens if self-hosted | | Setup | Days to weeks: rule selection, baseline triage of the initial finding flood | Hours to install; days to tune rules and suppress overlap with linters | | Ongoing | Rule/config maintenance; suppressions accumulate | Per-PR triage of findings; prompt/rule tuning as the codebase evolves | | Hidden cost | Alert fatigue from untuned rules — the classic reason teams ignore SAST dashboards | Review latency and noise — the ICSE study measured PR closure time up ~40% post-adoption | The subscription line is rarely what matters. The dominant cost on both sides is *engineer attention*: an untuned SAST deployment burns it in a one-time flood, an unfiltered AI reviewer burns it forever in a drip. Price the triage time, not the seat. Two cost asymmetries deserve explicit mention. Static analysis scales with *codebase size* — analysis time and finding volume grow with lines of code, but adding contributors is free. AI review scales with *change volume* — every PR costs inference and triage, but a 10-million-line legacy monolith costs nothing extra to sit there. Teams with large stable codebases and modest PR throughput get static analysis nearly free; teams shipping hundreds of AI-assisted PRs weekly onto a young codebase feel the AI reviewer's per-PR economics directly. Model the bill against your actual shape. ## Convergence: the line is blurring from both directions Worth naming, because it changes how you should read vendor positioning as of August 2026: the categories are actively merging. From the static side, Sonar ships AI-assisted fix suggestions and AI-generated-code detection on top of its deterministic engine, and Semgrep layers an LLM assistant over its rule findings to auto-triage false positives. From the AI side, review tools increasingly embed deterministic sub-checks — running linters and secret scanners inside their pipeline and reserving the LLM for what rules can't express. GitHub's [Copilot Autofix](https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/) is the cleanest specimen: CodeQL's taint engine decides *what* is a vulnerability, the LLM decides *how to fix and explain it*, and each component does only the job it's structurally suited for. The composite architecture wins because the failure modes cancel: deterministic detection eliminates hallucinated vulnerabilities, generative remediation eliminates the "here's a finding, good luck" dead end that made developers ignore SAST dashboards for a decade. Expect every serious tool on both sides to look more like this hybrid each year — which means the buying question shifts from "which category?" to "which pipeline composes both with the least noise?" ## The benchmark problem: read every number adversarially This comparison would be incomplete without the epistemics, because as of August 2026 the AI-review benchmark landscape is vendor-run and self-serving — on all sides. The canonical example: Greptile's [own benchmark](https://www.greptile.com/benchmarks) of five tools across 50 real-bug PRs reported Greptile catching 82%, with CodeRabbit at 44%. [Augment Code re-ran an evaluation on the same five repositories](https://www.augmentcode.com/tools/coderabbit-vs-greptile-vs-augment-cosmos) and scored Greptile at 45%. Same repos, same tool, half the score, depending on who runs it. DeepSource — which, again, won its own OpenSSF-based benchmark — published a [candid analysis of why this keeps happening](https://deepsource.com/blog/notes-on-ai-code-review-benchmarks): ground truth in code review is genuinely subjective ("is a missing null check a bug or a design choice?"), datasets are hand-picked, and scoring rules embed dozens of judgment calls that reliably favor whoever makes them. Every vendor that publishes a benchmark wins it. Static analysis had decades to develop independent evaluation (NIST SATE, the original OpenSSF benchmark, academic tool comparisons); AI review has not yet. Until it does, the only benchmark that matters is the one you run yourself: take your last 20 escaped bugs, reconstruct the PRs that introduced them, and see what each candidate flags. We maintain a [structured evaluation methodology](/blog/how-to-evaluate-ai-code-review-tools) for exactly this, and a [comparison of the current tool field](/blog/coderabbit-alternatives) if you're shortlisting. ## When you need both — which is almost always The two families cover disjoint failure classes, fail in complementary ways, and barely overlap even with each other (recall: 93.4% of findings unique to one tool in the four-way field test). The layered pipeline that follows from the evidence: 1. **Pre-commit / editor: linters and formatters.** Deterministic, instant, free. Style never reaches review. 2. **CI: static analysis and SAST.** Semgrep or SonarQube for maintainability rules, CodeQL or equivalent for taint-based security. Deterministic gates you can build policy on; the compliance artifact. 3. **PR open: AI review.** The semantic layer — logic, intent, cross-file consistency, edge cases — configured to stay silent on anything layers 1-2 already cover, with severity routing so only validated, high-confidence findings block. 4. **Human review: architecture and product judgment.** With the mechanical and semantic layers cleared, the scarce resource — senior attention — goes where nothing else works. Microsoft's research found [most human review value is knowledge transfer, not defect-finding](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/) anyway; the machines free humans to do the part that was always uniquely theirs. Skip layer 2 and you lose your guarantees and your audit trail. Skip layer 3 and, at 2026 code volumes — [Google reporting a quarter-plus of new code AI-written](https://thehill.com/policy/technology/4962336-google-ceo-says-more-than-25-percent-of-companys-new-code-written-by-ai/) back in 2024, and [DORA linking AI adoption to degraded delivery stability](https://dora.dev/research/2024/dora-report/) — the semantic bug classes flow straight to your most expensive reviewers, or to production. If you want to know which layer is your current bottleneck, the [assessment](/assessment) scores your review pipeline against these standards in a few minutes. And for the definitional groundwork this comparison builds on, start with [what AI code review is](/blog/what-is-ai-code-review). ## Bottom line Static analysis is a proof engine: deterministic, auditable, tunable once, blind to everything outside its rulebook. AI code review is a judgment engine: unbounded in scope, probabilistic in reliability, taxed per-PR rather than per-rule. They are not competitors — they cover different bug classes with different failure modes at different points in the pipeline, and the best current security tooling already composes them. Run the deterministic layer as your contract, the AI layer as your tireless first-pass colleague, and reserve your skepticism for anyone's benchmark — including the one you'll inevitably run yourself. ## FAQ ### What is the difference between AI code review and static analysis? Static analysis parses code into formal representations (ASTs, dataflow graphs) and checks them against deterministic rules — same input, same output, every time. AI code review feeds the diff plus codebase context to a large language model that reasons about intent and logic probabilistically. Static analysis proves the provable; AI review judges the semantic layer rules can't express. ### Can AI code review replace SAST tools? Not today, and not for compliance. SAST tools provide deterministic, auditable coverage of known vulnerability classes, which frameworks like SOC 2 and PCI-DSS effectively assume. Benchmark results for AI tools on real CVEs vary wildly between evaluators, so treat AI review as an additional detection layer, not a SAST replacement. ### Which has more false positives, AI review or static analysis? They fail differently. Static analyzers produce systematic false positives — the same over-broad rule fires on every matching pattern until you tune or suppress it. AI reviewers produce unpredictable ones: hallucinated bugs and irrelevant suggestions that vary run to run. Field data shows well-filtered AI tools can hit low single-digit false-positive rates, but the variance between tools is enormous. ### Is SonarQube an AI code review tool? SonarQube is fundamentally a static analysis platform built on deterministic rules, though Sonar has added AI-assisted features like fix suggestions and AI-code detection. The distinction that matters is the decision mechanism: rule-based analyzers flag only patterns someone encoded in advance, whereas LLM-based reviewers can flag novel logic errors. ### Do small teams need both static analysis and AI review? Usually yes, because the cheap layer is nearly free: linters and open-source static analyzers like Semgrep cost minutes to configure and run deterministically forever. Add AI review when PR volume or AI-generated code volume outgrows your senior reviewers' capacity — that's the layer that catches logic and context bugs static tools structurally miss. ### Why do AI code review benchmark results disagree so much? Because vendors run their own benchmarks and make dozens of scoring judgment calls — what counts as a catch, which bugs make the dataset, how partial credit works. Greptile's self-benchmark reported an 82% catch rate; Augment Code re-ran the same repos and scored it at 45%. Until independent benchmarks mature, run tools on your own recent bugs. ### Should AI review run before or after static analysis in CI? Run them in parallel on PR open — they don't depend on each other. The practical rule is to configure the AI reviewer to stay silent on anything the linter or SAST already covers, so each layer only reports what it is uniquely good at. Deduplication is a configuration task, not a product feature you can assume. # Best AI Code Review Tools (2026): 12 Tools Compared > The best AI code review tools 2026 offers, compared honestly: Kodus, CodeRabbit, Greptile, Copilot and more — context depth, pricing, self-hosting. The best AI code review tools in 2026 are Kodus (open source, self-hosted, bring-your-own-key), CodeRabbit (most polished hosted SaaS), Greptile (deepest codebase-wide context), and Cursor BugBot (best pure bug-finder on GitHub). Which one is right for you comes down to three questions: how much of your codebase the tool actually reads, whether your code can leave your infrastructure, and whether the pricing model survives contact with a team that ships 40 PRs a day. We compared 12 tools on exactly those axes. Every price and claim below was checked against vendor pricing pages and docs in August 2026 — and where a vendor doesn't publish a number, we say so instead of making one up. ## How we evaluated these tools If you're new to the category, start with [what AI code review actually is](/blog/what-is-ai-code-review). For this comparison, we scored tools on the criteria from our [evaluation guide](/blog/how-to-evaluate-ai-code-review-tools): - **Context depth.** Does the tool review the diff in isolation, or does it pull in the rest of the repo — and ideally sibling repos — before commenting? This is the single biggest quality differentiator, and it's why [multi-dimensional context](/standards/01-multi-dimensional-context) is the first standard in our framework. A reviewer that only sees the diff can't catch a broken contract two files away. - **Rule enforcement.** Can your team encode its own standards, and does the tool actually enforce them, or are rules a prompt suggestion the model may ignore? See the [rule-centric reviews standard](/standards/02-rule-centric) for what good looks like. - **Signal-to-noise.** A reviewer that leaves 30 comments per PR gets muted within a week. Tools that validate their own findings before posting — the idea behind [sandbox validation](/standards/06-sandbox-validation) — earn trust; tools that pattern-match loudly lose it. - **Deployment and data control.** Cloud-only, enterprise self-host, or genuinely open source you can run yourself. - **Pricing honesty.** Published numbers, no forced sales calls, and no hidden markup on LLM tokens. If you want to score your current review process against these criteria, take the [assessment](/assessment) — it takes about three minutes. ## Comparison table All pricing verified on vendor sites as of August 2026. Annual billing where both are offered. | Tool | Context depth | Self-hosted? | Pricing | Best for | |---|---|---|---|---| | [Kodus](https://github.com/kodustech/kodus-ai) | Deep — repo + linked sibling repos, rule inheritance | Yes (free, AGPL) | Free tier; Teams $10/dev/mo + your token costs | Teams that want control: open source, BYOK, no token markup | | [CodeRabbit](https://www.coderabbit.ai/pricing) | Medium-deep — repo, linked repo analysis, linter integration | Enterprise only | Pro $24/user/mo; Pro Plus $48/user/mo | Teams that want a polished, batteries-included SaaS | | [Greptile](https://www.greptile.com/pricing) | Deep — indexes the full codebase | Enterprise only | Pro $30/seat/mo (50 credits/seat, $1/extra) | Large codebases where cross-file context matters most | | [Cursor BugBot](https://cursor.com/bugbot) | Medium — PR-focused logic-bug hunting | No | Usage-based, avg $1.00–1.50 per run | Cursor-heavy teams that want a low-noise bug-finder | | [Qodo](https://www.qodo.ai/pricing/) | Medium-deep — repo-aware, RAG-based | Enterprise (on-prem/air-gapped) | Pro Team $30/mo + credit packs ($0.012/credit) | Teams wanting review + test generation in one platform | | [GitHub Copilot code review](https://github.com/features/copilot/plans) | Shallow-medium — diff + instructions file | No | From Pro $10/mo (metered AI credits) | GitHub-native teams that want good-enough for cheap | | [Graphite Diamond](https://graphite.com/pricing) | Medium — stack-aware | No | Team $40/user/mo for unlimited AI reviews | Teams already committed to stacked PRs | | [Sourcery](https://sourcery.ai/pricing) | Shallow-medium — PR-level | Enterprise only | Pro $12/seat/mo; Team $24/seat/mo | Small teams and open-source projects on a budget | | [Codacy](https://www.codacy.com/pricing) | Rule-based static depth + AI layer | No (cloud-only) | Free tier; Team $18/dev/mo | Teams that want static analysis first, AI second | | [DeepSource](https://deepsource.com/pricing) | Static analyzers + metered AI review | Enterprise only | Team $24/user/mo; AI review $8–15 per 10K LOC | Quality/security coverage with AI as an add-on | | [Panto](https://www.getpanto.ai/) | Medium — pulls business context from Jira/Confluence | Yes (on-prem offered) | Not clearly published — verify with vendor | Teams that want requirement-aware reviews | | [Bito](https://bito.ai/pricing/) | Medium — repo-aware | Check with vendor | Team $12/seat/mo; Pro $20/seat/mo (5K LOC/seat incl.) | Budget-conscious teams on GitHub/GitLab/Bitbucket | ## The 2026 pricing shift: from seats to usage Before the tool-by-tool breakdown, one trend worth understanding, because it changes the math for every tool on this list: 2026 is the year AI code review pricing started decoupling from seats. - **Cursor BugBot** dropped its $40/seat/month subscription in June 2026 for pure usage-based billing — [an average run now costs $1.00–1.50](https://cursor.com/blog/may-2026-bugbot-changes), depending on PR size. - **GitHub Copilot** retired its premium-request system on June 1, 2026 in favor of metered [AI credits](https://github.com/features/copilot/plans) (Pro includes $15/month of credits, Pro+ $70, Max $200). - **Qodo** moved to a $30/month base plan with pooled credit packs at $0.012/credit. Usage-based pricing is honest in one way — you pay for what you run — and dangerous in another: a team merging 800 PRs a month at $1.25/run pays $1,000/month regardless of headcount, and the bill scales with your shipping velocity. The alternative model, which Kodus uses, is a flat platform fee plus direct LLM billing with zero markup: you pay your model provider at list price and can see exactly where every token goes. Neither model is universally better, but you should model your own PR volume before signing anything. ## 1. Kodus **The open-source option with full model control.** Full disclosure up front: Kodus sponsors this site (it's in the footer), so calibrate accordingly — but everything below is verifiable in the public repo and docs. Kodus is an AI code reviewer ([kodus-ai on GitHub](https://github.com/kodustech/kodus-ai), AGPL-3.0 for the core, with enterprise-marked files under a commercial license) that works on GitHub, GitLab, Bitbucket, and Azure Repos. Three things genuinely differentiate it: **Bring your own key, zero markup.** Kodus is model-agnostic — Claude, GPT, Gemini, Llama, GLM, Kimi, or any OpenAI-compatible endpoint including self-hosted models. You pay your LLM provider directly at list price. Kodus publishes real token-cost estimates: for a 30-developer team, roughly $570/month on Claude Sonnet 4.5 down to about $345/month on Gemini Flash, as of August 2026. No other tool on this list is that transparent about what the AI actually costs. **Plain-language rules that sync from your existing config.** [Kody Rules](https://docs.kodus.io/how_to_use/en/code_review/configs/kody_rules.md) are written in natural language and inherit from global to repository to directory scope. More usefully, Kodus [auto-detects and imports rule files you already have](https://docs.kodus.io/how_to_use/en/code_review/configs/rules_file_detection.md): `.cursorrules`, `.cursor/rules/*.mdc`, `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, `.windsurfrules`, and more — so the standards your AI coding agents follow in the IDE are the same ones enforced at review time. Kody can also generate rules automatically by analyzing your team's review history. **Real deep context.** Beyond repo-level analysis, [linked repositories](https://docs.kodus.io/how_to_use/en/code_review/configs/linked_repositories.md) let the reviewer read sibling repos to catch cross-repo contract mismatches — the frontend PR that breaks against the backend API it doesn't live next to. This is the [multi-dimensional context standard](/standards/01-multi-dimensional-context) implemented, not just marketed. Pricing (verified August 2026): free Community cloud tier with unlimited PRs on your own API key and up to 10 Kody Rules; Teams at $10/dev/month plus token costs; Enterprise custom with SSO, RBAC, and audit logs. Self-hosting via Docker Compose, generic VM, or Kubernetes/Helm is free under AGPL with no seat minimums — see our [self-hosted AI code review guide](/blog/self-hosted-ai-code-review). Kodus states it doesn't store source code or train models on customer data; self-hosted instances send one anonymous daily heartbeat you can disable. **Pros** - Open source (AGPL-3.0 core) — you can read the code and run it on your infra for free - BYOK with zero token markup; works with self-hosted models for full data control - Rule-file sync from Cursor, Claude, Copilot, Windsurf configs is unique on this list - Cross-repo context via linked repositories - Cheapest per-seat platform fee among team-oriented tools ($10/dev) - CLI for local and CI pipeline reviews **Cons** - You manage LLM keys and billing yourself — one more moving part vs. all-inclusive SaaS - Dual licensing means some enterprise features (files marked `ee`) are commercial, not AGPL - Smaller community than the biggest names (about 1.3K GitHub stars as of August 2026) ## 2. CodeRabbit **The most polished hosted SaaS.** CodeRabbit is probably the most widely adopted dedicated AI code reviewer, and the product shows it: PR summaries, line-level comments, agentic chat, docstring generation, integrated linters and SAST tools, and Jira/Linear connections. Pricing (verified on [their pricing page](https://www.coderabbit.ai/pricing), August 2026): free tier with PR summaries; Pro at $24/user/month billed annually; Pro Plus at $48/user/month adding pre-merge checks, unit test generation, and merge-conflict resolution. Worth knowing: Pro is rate-limited to 5 PR reviews per developer per hour (10 on Pro Plus), and cross-repo context is capped — 1 linked repository analysis on Pro, 10 on Pro Plus. Self-hosting exists but only on custom-priced Enterprise. **Pros** - Most complete feature set in the category; excellent onboarding and UX - Linter/SAST integration merges static analysis and AI review in one place - Strong ecosystem: MCP connections, agentic chat, reports **Cons** - $48/user/month for the full experience is the most expensive per-seat price on this list - Hourly review rate limits on paid tiers can bite high-velocity teams - Closed source; self-hosting gated behind enterprise sales - Linked-repo context is capped by plan tier If CodeRabbit's pricing or closed-source model doesn't fit, we wrote a full breakdown of [CodeRabbit alternatives](/blog/coderabbit-alternatives). ## 3. Greptile **The context specialist.** Greptile's pitch is simple: it indexes your entire codebase, so reviews are informed by how your code actually fits together, not just the diff. On large, tangled codebases that depth genuinely shows up in review quality — catching a change that violates a pattern established three directories away. Pricing (verified August 2026): free Starter tier for individuals with 50 credits/month; Pro at $30/seat/month including 50 credits per seat, extra credits at $1 each. One credit buys a standard review; their heavier "trex" review costs 3 credits. Enterprise adds self-hosting in your own infrastructure and SSO/SAML. Open-source projects with MIT/Apache licenses can apply for free access, and early-stage startups (pre-Series A, under $2M revenue) get 50% off. **Pros** - Full-codebase indexing is a real quality edge on large repos - Custom rules on Pro; clean credit model that maps to actual usage - Generous OSS and startup programs **Cons** - Credits add friction: heavy teams will buy overage at $1/review beyond included credits - Closed source; self-hosting is enterprise-only - Narrower feature surface than CodeRabbit (deliberately — it does review, not everything) Deciding between the two biggest names? See our head-to-head: [CodeRabbit vs Greptile](/blog/coderabbit-vs-greptile). ## 4. Cursor BugBot **The bug-finder.** BugBot doesn't try to be a full review platform. It hunts logic bugs in GitHub PRs with a deliberately low-noise posture, and it's good at it — Cursor reports that over 70% of flagged issues get resolved before merge, and that more than half of the bugs it finds are ultimately fixed by engineers. Teams can add project-specific "Bugbot Rules," and fixes hand off cleanly into the Cursor editor or a background agent. Pricing changed materially in 2026: the old $40/seat/month subscription was [replaced with usage-based billing effective at renewals after June 8, 2026](https://cursor.com/blog/may-2026-bugbot-changes). An average run costs $1.00–1.50 depending on PR size, and a new high-effort mode finds 35% more bugs at the same resolution rate. **Pros** - Best-in-class signal-to-noise for logic bugs; engineers actually read its comments - Usage pricing is cheap for low-volume teams — no seats to buy - Tight loop with Cursor for applying fixes **Cons** - GitHub only; no GitLab/Bitbucket/Azure support - Not a full review platform: no deep standards enforcement, summaries-lite - Usage billing scales with PR volume — high-velocity teams should model the monthly cost - Cloud-only, closed source ## 5. Qodo (formerly Codium) **Review plus test generation.** Qodo spans three products — IDE assistant (Gen), CLI, and Qodo Merge for PR review — under one subscription. Qodo Merge does agentic PR review with a rules system, dashboards, and git plus IDE integrations. Historical footnote that matters for open-source folks: Qodo built PR-Agent, the original open-source PR reviewer, and transferred it to a community-owned org in 2026 — details in our [open source AI code review guide](/blog/open-source-ai-code-review-tools). Pricing (verified August 2026): Pro Team at $30/month covering teams up to 30 users, with pooled credit packs at $0.012/credit (a 2,500-credit pack maps to roughly 18 reviews). Unused credits expire monthly. Enterprise adds SSO/SAML, audit logs, and on-prem or air-gapped deployment. Qualified open-source projects can apply for free access. **Pros** - One subscription covers review, test generation, and IDE assistance - Air-gapped enterprise option is rare and valuable for regulated industries - $30/month base (not per-user) is cheap for small teams **Cons** - Credit math is hard to predict — roughly 140 credits per review, and credits expire monthly - The all-in-one breadth means the review product is less focused than dedicated reviewers - Closed source (the open-source PR-Agent is now community-maintained, separate from Qodo's paid product) ## 6. GitHub Copilot code review **The default.** If your team is on GitHub and already pays for Copilot, code review is the checkbox you flip on. Copilot reviews PRs on request (or automatically), leaves comment-only reviews in under 30 seconds, and reads repo-level custom instructions from `.github/copilot-instructions.md` ([docs](https://docs.github.com/en/copilot/using-github-copilot/code-review/using-copilot-code-review)). Pricing (verified on [GitHub's plans page](https://github.com/features/copilot/plans), August 2026): code review is included from Pro at $10/month (with $15/month of AI credits), Pro+ at $39 ($70 credits), and Max at $100 ($200 credits); the free tier doesn't include it. Business and Enterprise org plans exist with sales-led pricing. Since June 1, 2026, usage is metered through AI credits at model token rates, so heavy review usage draws down your monthly credit pool. **Pros** - Cheapest entry point if you're already paying for Copilot; zero setup - Native GitHub UX — reviews appear like any other reviewer - Custom instructions give basic standards control **Cons** - Shallowest context on this list: it reviews the diff plus an instructions file, not your codebase - Comment-only — it won't reply to follow-up discussion, and re-reviews can repeat dismissed comments - Credit metering makes cost at scale less predictable than a flat seat - GitHub only, obviously For where diff-level review falls short, see [AI code review vs static analysis](/blog/ai-code-review-vs-static-analysis) — Copilot sits closer to the middle of that spectrum than vendors admit. ## 7. Graphite Diamond **AI review for stacked-PR teams.** Graphite is a code review platform built around stacked PRs; Diamond is its AI reviewer. If your team already works in stacks, Diamond's awareness of the stack context is a real advantage — most tools review each PR as an island. Pricing (verified August 2026): free Hobby tier with limited AI reviews; Starter at $20/user/month; Team at $40/user/month unlocks unlimited AI reviews and chat plus merge queue; Enterprise adds SAML, audit logs, and GitHub Enterprise Server support. **Pros** - The only AI reviewer designed around stacked-PR workflows - Merge queue, insights, and review tooling in one platform - Solid free tier for individuals **Cons** - $40/user/month for unlimited AI review is premium pricing - Buying Diamond means buying the Graphite workflow — poor fit if you don't stack - GitHub-centric; closed source, cloud-only ## 8. Sourcery **The budget pick with an OSS heart.** Sourcery started as a Python refactoring tool and grew into a general AI reviewer for GitHub and GitLab with line-by-line reviews, change summaries and diagrams, and customizable rules. Pricing (verified August 2026): free for open-source repos; Pro at $12/seat/month; Team at $24/seat/month adds repo analytics, 3x review rate limits, daily security scans, and — notably — the option to bring your own LLM. Enterprise adds self-hosting. Annual billing saves 20%. **Pros** - $12/seat is among the cheapest paid entry points for private repos - Free Pro for open source, no application hoops - BYO-LLM on Team tier is rare at this price **Cons** - Shallower context than Kodus, Greptile, or CodeRabbit — reviews are PR-scoped - Security scanning limits by tier add fine print - Smaller platform surface: no Bitbucket/Azure DevOps support ## 9. Codacy **Static analysis first, AI second.** Codacy is a code-quality platform — 49 languages, 12,000+ configurable rules, SAST, secrets detection, SCA, IaC scanning — that has layered AI on top: an AI code reviewer for PRs, one-click fixes, and "guardrails" that check AI-generated code in the IDE as it's written. Pricing (verified August 2026): free Developer tier (IDE plugin); Team at $18/developer/month billed annually ($21 monthly) for up to 30 devs and 100 private repos; Business is custom. Free for open source. Cloud-only — Codacy's pricing page confirms no self-hosted option for the current cloud product. **Pros** - Mature static analysis engine with enormous language and rule coverage - Quality gates and merge blocking are first-class, not bolted on - Sensible mid-range pricing **Cons** - The AI review layer is younger and thinner than dedicated AI reviewers - Cloud-only — a non-starter for teams that can't ship code to a third party - Rule configuration depth cuts both ways: real setup investment required If you're weighing a rules engine against an LLM reviewer, read [AI code review vs static analysis](/blog/ai-code-review-vs-static-analysis) — the honest answer is you likely want both, and Codacy is one way to get them together. ## 10. DeepSource **Quality platform with metered AI.** DeepSource pairs its static analyzers (code quality, coverage, secrets) with Autofix and a metered AI Review product. It's free for open source — unlimited public repos and 1,000 PRs/month reviewed. Pricing (verified August 2026): Team at $24/user/month billed yearly, which includes a $100 annual AI Review credit per user; AI review itself is metered at $8–15 per 10K lines of code depending on tier. Enterprise adds self-hosted and air-gapped deployment plus BYOK — bring your own Anthropic, OpenAI, or Gemini keys. **Pros** - Genuinely generous OSS tier - Enterprise BYOK and air-gapped options for regulated environments - Static analysis + AI in one platform, like Codacy but with self-host available **Cons** - Per-10K-LOC AI metering is awkward to predict and the included credit is small - AI review is an add-on to a static-analysis product, not the core competency - BYOK is enterprise-only — Kodus and Sourcery offer model control much cheaper ## 11. Panto **Business-context reviews.** Panto's differentiator is pulling business context into review: it aligns PR analysis with requirements from Jira and Confluence, on top of line-by-line review across 30+ languages and a large security-checks library. It supports GitHub, GitLab, Bitbucket, and Azure DevOps, with self-hosted/on-prem deployment offered. In 2026 Panto also expanded into autonomous mobile QA testing, so the company now runs two product lines. Pricing: as of August 2026 we could not find a clearly published price list for the code review product on Panto's site (the pricing page is dominated by the QA product); third-party trackers list around $15/dev/month with a higher tier around $40, but verify directly with the vendor before budgeting. **Pros** - Requirement-aware review (Jira/Confluence context) is a genuinely different angle - Broad platform support including Azure DevOps; on-prem available - Strong security-check coverage **Cons** - Opaque pricing for the review product as of this writing - Company focus is split across code review and mobile QA - Closed source; smaller track record than the category leaders ## 12. Bito **The budget all-platformer.** Bito's AI Code Review Agent covers GitHub, GitLab, and Bitbucket with repo-aware reviews, custom review guidelines, Jira integration, and review analytics. Pricing (per [Bito's billing docs](https://docs.bito.ai/help/billing-and-plans/overview), August 2026): Team at $12/seat/month billed annually ($15 monthly); Professional at $20/seat annually ($25 monthly) with a 14-day trial. Both include 5K lines of code reviewed per seat per month, then $5 per additional 1K lines — read that overage clause carefully, because a busy team can blow through 5K LOC per seat quickly. **Pros** - Low headline price with multi-platform support - Custom guidelines and Jira integration at the Professional tier - Reasonable analytics for the price **Cons** - The LOC-based overage ($5 per 1K lines past the cap) can quietly multiply the effective price - Less context depth than the leaders; closed source - Self-hosting story unclear from public materials — ask before assuming ## Which tool should you actually pick? Concrete recommendations, no hedging: - **You need self-hosting or data control without an enterprise contract:** Kodus. It's the only tool here you can run on your own infra for free, with your own models. See the [self-hosted guide](/blog/self-hosted-ai-code-review). - **You want the smoothest hosted experience and budget isn't tight:** CodeRabbit Pro Plus — accepting the rate limits and price. - **Your problem is a huge codebase where reviewers miss cross-file breakage:** Greptile, or Kodus with linked repositories if you also want it self-hosted. - **You just want bugs caught with minimal noise and you live in GitHub + Cursor:** BugBot. Model the usage cost against your PR volume first. - **You're already paying for Copilot and want free-ish coverage today:** turn on Copilot code review, and re-evaluate in six months when you notice what it misses. - **You're an open-source maintainer:** Sourcery, DeepSource, or Greptile's OSS programs are free; Kodus Community is free with your own key; Qodo has an OSS program. - **You need static analysis and AI in one contract:** Codacy (cloud-only) or DeepSource (if you'll eventually need self-hosting). Whatever you shortlist, run a two-week bake-off on real PRs and count two things: comments your engineers acted on, and comments they dismissed. That ratio — not the demo — is the product. Our [evaluation guide](/blog/how-to-evaluate-ai-code-review-tools) has a full scorecard, and the [assessment](/assessment) will tell you which criteria matter most for your team. And if control over your code, your models, and your costs is the deciding factor, that's the exact gap [Kodus](https://kodus.io) was built to fill — open source, self-hosted, and zero markup on tokens. ## FAQ ### What is the best AI code review tool in 2026? There is no single best tool — it depends on your constraints. Kodus is the strongest option if you want open source, self-hosting, and control over model costs. CodeRabbit is the most polished hosted SaaS, Greptile leads on whole-codebase context, and Cursor BugBot is the best pure bug-finder if you only use GitHub and don't mind usage-based billing. ### Are there free AI code review tools? Yes. Kodus has a free Community cloud tier (bring your own API key) and a free self-hosted AGPL version. Greptile gives individuals 50 free review credits per month, Sourcery and DeepSource are free for open-source repos, and GitHub Copilot code review is included from the $10/month Pro plan. Most other tools offer 14-day trials rather than permanent free tiers. ### Which AI code review tools can be self-hosted? Kodus is self-hostable on its free AGPL license via Docker Compose or Helm. CodeRabbit, Greptile, Sourcery, DeepSource, and Qodo offer self-hosted or on-prem deployments, but only on custom-priced enterprise plans. Cursor BugBot, GitHub Copilot, Graphite, and Codacy are cloud-only. ### Do AI code review tools replace human reviewers? No. They replace the mechanical part of review — catching bugs, style drift, and missed edge cases before a human looks at the PR. Humans still own architectural judgment, product context, and the final approve. The practical win is that human review time shifts from nitpicks to design. ### How is AI code review different from static analysis? Static analysis matches code against predefined patterns and rules, so it's deterministic but blind to intent. AI code review reads the diff in context and reasons about what the change is trying to do, which catches logic bugs and cross-file contract breaks that rules can't express. The best setups run both — several tools on this list (Codacy, DeepSource, CodeRabbit) combine them. ### How much do AI code review tools cost in 2026? Per-seat pricing runs roughly $10–48 per developer per month: Kodus at $10 plus your own token costs, Sourcery from $12, Codacy at $18, CodeRabbit at $24–48, Greptile and Qodo around $30. The notable 2026 shift is toward usage-based billing — Cursor BugBot now charges roughly $1.00–1.50 per review run instead of $40/seat, and GitHub Copilot moved to metered AI credits. ### Can AI code review tools enforce my team's coding standards? The good ones can. Kodus lets you write plain-language Kody Rules and auto-imports existing rule files like .cursorrules, CLAUDE.md, and copilot-instructions.md. CodeRabbit, Greptile, Qodo, BugBot, and Sourcery all support custom rules in some form, while Copilot reads a repository instructions file. Rule quality and enforcement depth vary a lot, so test with your real standards before committing. # CodeRabbit Alternatives: 7 Tools Compared (2026) > Why teams leave CodeRabbit and 7 alternatives compared — Kodus, Greptile, Qodo, BugBot, Copilot, Graphite, Panto. Pricing verified August 2026. If CodeRabbit's comment noise, plan churn, or Enterprise-only self-hosting has you shopping around, you have genuinely good options in 2026: Kodus if you want open source, self-hosting, and model control; Greptile if you want the deepest codebase context; Cursor BugBot if you only want bugs flagged; and Copilot, Qodo, Graphite, or Panto for more specific situations. All pricing and feature claims below were verified against vendor pages as of August 2026 — no benchmark theater, no affiliate spin. ## Why teams look for a CodeRabbit alternative Let's be fair first: CodeRabbit is the market leader for a reason. It reviews PRs on [GitHub, GitLab, Azure DevOps, and Bitbucket](https://docs.coderabbit.ai/), bundles linters and SAST, generates PR summaries, and ships IDE and CLI reviews. Plenty of teams are happy with it. But the same complaints keep showing up in engineering forums, and they're worth taking seriously before you renew. ### 1. Comment noise and nitpicks This is the big one. CodeRabbit's default posture is verbose: walkthrough, summary, sequence diagram, then a stack of inline comments that mixes real findings with style nitpicks. Hacker News threads on PR review bots regularly cite [the nitpicking problem](https://news.ycombinator.com/item?id=42484498) by name, and "too many comments, half of them nitpicks" is the recurring theme in community reviews. To CodeRabbit's credit, it has responded — review profiles, path filters, and custom instructions can cut a lot of the noise, and a quieter review profile now focuses conversation on high-impact issues (see [their docs and changelog](https://docs.coderabbit.ai/)). But "tune it until it stops annoying you" is real work, and the interesting counterpoint is that some users end up on the other side: in [one HN discussion](https://news.ycombinator.com/item?id=46777079), a commenter praised CodeRabbit precisely because even its low-confidence comments were worth reading. Signal-to-noise is partly a tool property and partly a configuration discipline — which is why we treat [actionability as a standard to measure](/standards/08-actionability), not a marketing claim. ### 2. Pricing and plan churn CodeRabbit retired its Lite and Pro Legacy plans on June 8, 2026 ([announcement](https://kb.coderabbit.ai/articles/2508018126-sunset-of-lite-and-pro-legacy-subscription-plans)). As of August 2026, [the lineup](https://www.coderabbit.ai/pricing) is: - **Free** — PR summarization, IDE/CLI reviews, and a 14-day Pro Plus trial. - **Pro** — $24/dev/month billed annually. Linters/SAST, Jira and Linear integration, agentic chat, analytics. - **Pro Plus** — $48/dev/month billed annually. Adds pre-merge checks, unit test generation, merge conflict resolution. - **Enterprise** — custom pricing. SSO, RBAC, audit logs, API access, and self-hosting. Note the fine print: each tier carries hourly review rate limits (5 PR reviews per developer per hour on Pro, 10 on Pro Plus, 12 on Enterprise, all subject to a fair usage policy). For teams that batch-merge or run monorepos with high PR volume, those caps matter. And if you were on Lite at its old price point, your renewal math changed whether you wanted it to or not. ### 3. Self-hosting is Enterprise-only If compliance, data residency, or plain institutional caution means PR diffs can't leave your infrastructure, CodeRabbit requires the custom-priced Enterprise tier. There's no self-hosted option at $24 or $48. For a 10-person team with a hard data requirement, that's a non-starter — which is exactly the gap [self-hosted AI code review tools](/blog/self-hosted-ai-code-review) exist to fill. ### 4. No model control On CodeRabbit's standard SaaS plans you don't choose which LLM reviews your code, and you can't bring your own API keys. You're buying an opaque pipeline. That's fine until you want to control cost per review, pin a model your security team has approved, or route to an internal endpoint. If BYOK matters to you, it rules out most of the market — but not all of it. ## What actually matters when you switch Before the tool list: switching review bots because the old one was noisy, only to configure the new one just as badly, is a common failure mode. If you haven't already, read [how to evaluate AI code review tools](/blog/how-to-evaluate-ai-code-review-tools) — the short version is that review quality comes down to two things. First, context: does the tool see beyond the diff — codebase structure, team standards, ticket intent? That's [multi-dimensional context](/standards/01-multi-dimensional-context). Second, rules: can you tell it what *your* team cares about in a form it reliably follows? That's [rule-centric review](/standards/02-rule-centric). Every tool below gets judged against those two axes. (New to the category entirely? Start with [what AI code review is](/blog/what-is-ai-code-review).) ## The 7 best CodeRabbit alternatives in 2026 ### 1. Kodus — open source, self-hosted, bring your own keys **What it is:** [Kodus](https://github.com/kodustech/kodus-ai) is an open-source (AGPLv3) AI code review platform, positioned explicitly as the open-source alternative to CodeRabbit. Its core ideas: **Kody Rules** let you define review standards in plain language (and sync existing rule files from Cursor, Copilot, or Claude setups), **BYOK on every plan** means you connect your own OpenAI, Anthropic, Gemini, or OpenAI-compatible keys and pay providers at list price with zero markup, and self-hosting works via Docker Compose or Helm with no seat minimums. It supports GitHub, GitLab, Bitbucket, Azure Repos, and Forgejo — the broadest platform coverage on this list — plus a CLI for local and CI review. It can also pull business context from Jira, Linear, and Notion to check a PR against what the ticket actually asked for. **Pros:** - AGPLv3 core you can read, audit, and run on your own infrastructure — full data control without an enterprise sales call. - BYOK with transparent token tracking: you see exactly what each review costs and bill it to your own provider account. - Plain-language rules as the primary review mechanism, not a bolt-on — the review enforces *your* standards instead of generic best practices. - Widest git platform support in this comparison, including Forgejo. **Cons:** - Younger product with a smaller community (1,300+ GitHub stars) than CodeRabbit's ecosystem. - Self-hosting means you own the ops: deployment, upgrades, and LLM key management are your job. - Fewer auxiliary extras than CodeRabbit Pro Plus (no docstring generator or merge-conflict resolver). **Pricing (as of August 2026):** Self-hosting the AGPL core is free — you pay infrastructure and your own LLM usage. Kodus Cloud offers a 14-day trial with up to 35 PR reviews, no credit card; see current cloud pricing on [kodus.io](https://kodus.io). **Best for:** teams that want CodeRabbit-style automation with open-source transparency, self-hosting on any budget, and control over which models review their code. It's the natural pick among [open-source AI code review tools](/blog/open-source-ai-code-review-tools) if you want a product rather than a framework. *Disclosure: Kodus sponsors this site. The pros and cons above are as honest as we can make them — the cons are real.* ### 2. Greptile — deepest codebase context **What it is:** [Greptile](https://www.greptile.com/) builds a graph index of your entire codebase, then uses parallel agents to review changes against it — catching cross-file breakage that diff-only reviewers miss. It learns team standards from your PR comments over time, supports plain-English custom rules, and offers TREX, an agent that writes and runs tests for each PR in a sandbox. Vendor claims 22,000+ teams including Nvidia, Brex, and PostHog. **Pros:** - The most serious attempt at whole-codebase context in the market — genuinely different from diff-plus-retrieval approaches. - TREX sandbox testing is a unique capability: it doesn't just guess a bug exists, it tries to demonstrate it. - Strong agent-ecosystem integrations: MCP, a Claude Code plugin, one-click IDE fixes. - Free for qualifying MIT/Apache open-source projects; 50% startup discount for pre-Series A companies under $2M revenue. **Cons:** - GitHub and GitLab only. No Bitbucket, no Azure DevOps. - Credit-based pricing gets expensive at volume: [Pro is $30/seat/month](https://www.greptile.com/pricing) with 50 credits per seat, then $1 per additional credit — and a TREX review burns 3 credits. A seat is any developer who received a review that billing period, so seat count tracks activity, not licenses. - Mixed community reports on precision — [one detailed HN thread](https://news.ycombinator.com/item?id=46777079) called its output "pretty much pure noise," with confidence scores lending false credibility to wrong findings. Others report much better results. Tune before you trust. - Closed source, cloud-first; self-hosting only on the custom Enterprise tier. **Pricing (as of August 2026):** Free tier with 50 credits/month for one developer; Pro at $30/seat/month + overages; Enterprise custom. **Best for:** GitHub/GitLab teams with tangled cross-module dependencies where whole-repo context pays for itself, and budget flexibility for usage-based billing. ### 3. Qodo — enterprise platform with an MIT-licensed core **What it is:** Qodo's review product grew out of [PR-Agent](https://github.com/qodo-ai/pr-agent), the MIT-licensed open-source tool known for its command-driven workflow (`/describe`, `/review`, `/improve`, `/ask`). PR-Agent remains community-maintained and self-hostable with your own API keys across GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. The commercial Qodo platform layers on agentic PR review, unlimited rules, analytics, and enterprise deployment. **Pros:** - PR-Agent is a genuinely useful free path: MIT license, your keys, five git platforms, multiple LLM providers via LiteLLM. - Enterprise tier offers single-tenant SaaS, on-prem, and air-gapped deployment — one of the few vendors that says "air-gapped" out loud. - Pooled team credits rather than per-seat pricing can favor teams with uneven review volume. **Cons:** - The pricing model takes a spreadsheet to understand: [Pro Team](https://www.qodo.ai/pricing/) is $30/month base (up to 30 users) plus credits at $0.012 each, with packs sized at 2,500 credits (~18 reviews/month) to 20,000 (~144 reviews/month). That works out to roughly $1.50-1.70 per review — do your own volume math before committing. - The open-source/commercial split is confusing; the PR-Agent README explicitly warns it "is not the Qodo free tier." - The platform's breadth (test generation, coverage, agents) can distract if all you want is sharp PR review. **Pricing (as of August 2026):** 14-day unlimited trial; Pro Team $30/month + credit packs; Enterprise custom for 30+ users. **Best for:** enterprises that want on-prem/air-gapped options with commercial support, and hackers happy to run MIT-licensed PR-Agent themselves. ### 4. Cursor BugBot — bugs only, minimal ceremony **What it is:** [BugBot](https://cursor.com/docs/bugbot) is Cursor's PR reviewer, deliberately scoped to bugs, security issues, and rule violations rather than full-spectrum review. It reads PR comments for context, supports team- and repo-level rules via `.cursor/BUGBOT.md` files, and its "Fix in Cursor" links open findings directly in the editor. Platform support is broad: GitHub (including GHES), GitLab (including self-hosted), Bitbucket (including Data Center), and Azure DevOps (limited availability). **Pros:** - The low-noise philosophy is structural, not configured: it doesn't try to comment on everything, so it mostly doesn't. - Usage-based pricing after the [May 2026 change](https://cursor.com/blog/may-2026-bugbot-changes) — Cursor estimates $1.00-1.50 per average run — beats per-seat pricing for teams with modest PR volume. - Tight fix loop if your team already lives in Cursor. **Cons:** - No PR summaries, no walkthroughs, no docstrings — it's a bug hunter, not a review platform. That's the point, but know what you're buying. - Effectively assumes the Cursor ecosystem; BugBot is bundled into [Cursor plans](https://cursor.com/pricing) rather than sold standalone. - The pricing transition confused even its own users ([community thread](https://forum.cursor.com/t/i-find-new-bugbot-pricing-difficult-to-understand/122143)), and usage-based billing makes monthly cost less predictable. - SaaS only — no self-hosted deployment of BugBot itself. **Pricing (as of August 2026):** usage-based; Cursor estimates $1.00-1.50 per run, with included usage on individual Cursor plans (from $20/month) and on-demand spend for teams. **Best for:** Cursor shops that want a second pair of eyes on bugs and are allergic to review-bot chatter. ### 5. GitHub Copilot code review — the default that's already there **What it is:** [Copilot code review](https://docs.github.com/en/copilot/concepts/agents/code-review) reviews PRs natively on GitHub, flags bugs, security issues, and style problems, and can apply suggested fixes via the Copilot coding agent. It's customizable through `copilot-instructions.md`, path-specific instruction files, and `AGENTS.md`, with Lite and Balanced review effort levels. **Pros:** - Cheapest entry point in the market: included with Copilot Pro ($10/month), Business ($19/user/month), and Enterprise ($39/user/month) as of August 2026. - Zero new vendors, zero new DPAs, zero onboarding — it's a checkbox in a repo you already have. - Instructions-file customization aligns with conventions your team may already maintain for coding agents. **Cons:** - Billing became genuinely complicated in 2026: reviews now consume [GitHub AI Credits based on token usage](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/) *plus* GitHub Actions minutes for agentic context gathering. Budgeting requires monitoring, not arithmetic. - GitHub only (Azure DevOps in public preview). No GitLab, no Bitbucket. - No model choice, and depth trails the specialists — GitHub's own docs position it as an assistant, not a replacement for human review. - Won't review dependency manifests, lock files, or SVGs. **Pricing (as of August 2026):** bundled with paid Copilot plans from $10/month; reviews draw down AI Credits plus Actions minutes, with overage billing past included allotments. **Best for:** GitHub teams already paying for Copilot who want baseline automated review before deciding whether a specialist tool earns its keep. ### 6. Graphite — code review inside a stacked-PR workflow **What it is:** [Graphite](https://graphite.com/pricing) is a code review platform built around stacked PRs, with AI reviews, a merge queue, and review automation layered on top. The AI reviewer (which absorbed what Graphite previously marketed as Diamond) is part of the workflow product rather than a standalone bot. **Pros:** - If your team adopts stacking, the whole package — review UI, AI review, merge queue — is coherent and fast. - Unlimited AI reviews on the Team plan; no per-review metering to think about. - Free Hobby tier with limited AI reviews for personal repos. **Cons:** - You're buying a workflow, not just a reviewer. If you don't want stacked PRs, you're paying for scaffolding you won't use. - GitHub-centric: GitHub org repos on paid plans, GHES support only on Enterprise. No GitLab or Bitbucket. - Unlimited AI review requires the $40/user/month Team plan (annual billing); the $20 Starter tier keeps AI reviews limited. **Pricing (as of August 2026):** Hobby free; Starter $20/user/month; Team $40/user/month (annual billing); Enterprise custom. **Best for:** GitHub teams sold on stacked-PR velocity who want AI review as part of a bigger workflow change, not a drop-in bot. ### 7. Panto — review plus security scanning, now with a QA twist **What it is:** [Panto](https://www.getpanto.ai/) started as an AI code reviewer with heavy security emphasis — 30,000+ SAST checks, IaC scanning, secret detection, business context from Jira and Confluence — across GitHub, GitLab, Bitbucket, and Azure DevOps. In 2026 the company repositioned around a unified platform that adds autonomous mobile QA testing on real devices. **Pros:** - Security-first review posture: SAST, IaC, and secrets in the same PR pass, with audit-friendly reporting. - Broad git platform support and on-premise deployment available for enterprise. - If you need mobile QA automation *and* code review, the bundle is unusual. **Cons:** - The pivot toward mobile QA makes the roadmap harder to read if code review is all you want. - Published pricing has shifted with the repositioning; third-party listings cite around $15/dev/month with PR volume caps, but verify current numbers directly with Panto before budgeting. - Smaller community and less independent coverage than the tools above. **Pricing (as of August 2026):** not clearly published for code review; contact Panto or check their pricing page. On-prem available at enterprise level. **Best for:** security-conscious teams — especially mobile shops — that want review, SAST, and QA under one vendor. ## Comparison table Verified against vendor pages, August 2026: | Tool | Entry price | Self-hosting | BYOK / model choice | Git platforms | Open source | |---|---|---|---|---|---| | **CodeRabbit** | $24/dev/mo (annual) | Enterprise only | No | GitHub, GitLab, Azure DevOps, Bitbucket | No | | **Kodus** | Free (self-host) | Yes, any plan (Docker/Helm) | Yes, every plan | GitHub, GitLab, Bitbucket, Azure Repos, Forgejo | AGPLv3 | | **Greptile** | Free (50 credits); $30/seat/mo | Enterprise only | No | GitHub, GitLab | No | | **Qodo / PR-Agent** | Free (PR-Agent); $30/mo + credits | PR-Agent: yes; platform: enterprise | PR-Agent: yes | GitHub, GitLab, Bitbucket, Azure DevOps, Gitea | PR-Agent: MIT | | **Cursor BugBot** | Usage-based (~$1.00-1.50/run, vendor est.) | No | No | GitHub, GitLab, Bitbucket, Azure DevOps (limited) | No | | **Copilot code review** | With Copilot from $10/mo | No | No | GitHub (Azure DevOps preview) | No | | **Graphite** | $20/user/mo; unlimited AI at $40 | No | No | GitHub (GHES on Enterprise) | No | | **Panto** | Contact vendor | Enterprise on-prem | No | GitHub, GitLab, Bitbucket, Azure DevOps | No | ## How to choose Cut through it with three questions: 1. **Can your code leave your infrastructure?** If no: Kodus or PR-Agent today, or enterprise negotiations with Greptile, Qodo, or Panto. Everyone else is out, including CodeRabbit below Enterprise. 2. **Do you want a reviewer or a bug detector?** Full-review platforms (Kodus, CodeRabbit, Greptile, Qodo) summarize, enforce standards, and flag issues. BugBot and Copilot's Lite mode are narrower by design. Narrower is quieter; broader is more leverage *if* you configure it. 3. **Per-seat or per-review?** High PR volume favors flat seats (CodeRabbit, Graphite Team) or self-hosted BYOK where you pay raw token costs. Low volume favors usage-based (BugBot, Greptile overage, Qodo credits). Then run a two-week trial against your five gnarliest recent PRs — the ones with the subtle bug that shipped. A tool that catches those and stays quiet otherwise is worth paying for; grade it with our [assessment](/assessment) if you want a structured scorecard. For the broader field beyond CodeRabbit's direct competitors, see our [best AI code review tools](/blog/best-ai-code-review-tools) roundup. ## Migrating without losing what you've tuned If you've already invested months teaching CodeRabbit your preferences, don't throw that away when you switch. Three practical notes from teams that have made the move: - **Export your rules first.** Whatever you've encoded in CodeRabbit's custom instructions and path filters is a distilled statement of your team's standards. Most alternatives accept something equivalent: Kodus syncs existing rule files from Cursor/Copilot/Claude setups and expresses standards as plain-language Kody Rules, BugBot reads `.cursor/BUGBOT.md`, Copilot reads `copilot-instructions.md`, and Greptile takes plain-English rules. Porting these on day one is the single highest-leverage migration step — a rule-centric setup transfers; vibes don't. - **Run both tools in parallel for two weeks.** Set the new tool to comment-only on a subset of repos while CodeRabbit keeps running. Compare what each catches and what each fabricates on the same PRs. This costs almost nothing on usage-based or free tiers and replaces opinion with evidence. - **Decide who owns tuning.** Every tool on this list degrades into noise or silence without an owner. Assign one engineer to review the reviewer for the first month — adjusting rules when the bot flags something dumb twice. Teams that skip this step churn through three tools and conclude the category is hype. One more honest note: if your only complaint is noise and you're otherwise happy, try CodeRabbit's quieter review profile and path filters before migrating. Switching tools is a real cost, and the cheapest fix is sometimes configuration. Migrate when the problem is structural — self-hosting, model control, platform support, or pricing — not cosmetic. ## Bottom line CodeRabbit remains a strong default for teams that want maximum features from a managed SaaS and don't mind tuning out the noise. But the 2026 market has real depth: Greptile for context, BugBot for signal purity, Copilot for price, Qodo for air-gapped enterprise — and Kodus if you've concluded, as we obviously have, that review infrastructure this close to your codebase should be open source, self-hostable, and running on models you control. ## FAQ ### Why do teams switch away from CodeRabbit? The three complaints that come up most are comment noise (nitpicks that bury real findings), pricing changes (the Lite and Pro Legacy plans were retired in June 2026, leaving Pro at $24/dev/month annual and Pro Plus at $48), and the fact that self-hosting is only available on the custom-priced Enterprise tier. Teams that need model control (BYOK) also can't get it on standard SaaS plans. ### What is the best open-source CodeRabbit alternative? Kodus (AGPLv3) and Qodo's PR-Agent (MIT) are the two serious open-source options. Kodus is a full review platform with plain-language rules, BYOK, and self-hosting via Docker Compose or Helm. PR-Agent is a leaner command-driven tool you run with your own API keys. Pick Kodus if you want a product, PR-Agent if you want a building block. ### Is there a free CodeRabbit alternative? Yes. Greptile's free tier includes 50 review credits per month for one developer, GitHub Copilot code review is bundled into paid Copilot plans starting at $10/month, and self-hosting an open-source tool like Kodus or PR-Agent costs only your infrastructure and LLM API usage. ### Which CodeRabbit alternatives can be self-hosted? Kodus and PR-Agent can be self-hosted by anyone, on any plan. Greptile, Qodo, and Panto offer self-hosted or on-prem deployment on enterprise tiers. CodeRabbit itself gates self-hosting behind Enterprise. Cursor BugBot, GitHub Copilot code review, and Graphite are SaaS-only, though BugBot and Graphite can connect to self-hosted git servers. ### Which alternative produces the least review noise? Cursor BugBot is the most deliberately narrow — it hunts bugs and security issues rather than commenting on style. Beyond tool choice, noise is mostly a configuration problem: tools with strong rule systems (Kodus's Kody Rules, Greptile's custom rules, Copilot's instructions files) let you define what's worth flagging instead of accepting generic defaults. ### Which tools support GitLab, Bitbucket, or Azure DevOps? Kodus supports GitHub, GitLab, Bitbucket, Azure Repos, and Forgejo. Qodo's PR-Agent covers GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Cursor BugBot covers GitHub, GitLab, Bitbucket, and Azure DevOps (limited). Greptile supports GitHub and GitLab only. Graphite and Copilot code review are GitHub-centric. ### How much does AI code review cost per developer in 2026? Roughly $10-48 per developer per month for SaaS seats, or $1-2 per review on usage-based models. As of August 2026: Copilot from $10, Graphite $20-40, CodeRabbit $24-48, Greptile $30/seat plus overages, BugBot around $1.00-1.50 per run. Self-hosted open-source tools cost infrastructure plus LLM tokens at provider list price. # CodeRabbit vs Greptile: Which to Pick in 2026 > CodeRabbit vs Greptile head-to-head: context models, review quality, pricing, self-hosting, and when to pick each. Verified August 2026. CodeRabbit and Greptile are both top-tier AI code reviewers solving different problems: CodeRabbit is a broad review platform — summaries, linters, standards, four git platforms — while Greptile is a depth play, indexing your whole codebase into a graph so its agents catch cross-file breakage that diff-focused reviewers miss. Pick CodeRabbit for breadth and flat pricing, Greptile for context depth on GitHub or GitLab — and neither if you need self-hosting or model control without an enterprise contract. Everything below was verified against vendor pages as of August 2026. ## TL;DR comparison | | CodeRabbit | Greptile | |---|---|---| | **Core approach** | Full-spectrum PR review: summaries, walkthroughs, linters/SAST, inline comments | Graph index of the codebase + parallel review agents | | **Entry pricing** | Free tier; Pro $24/dev/mo (annual) | Free tier (50 credits, 1 dev); Pro $30/seat/mo + 50 credits/seat | | **Overage model** | Hourly rate limits per tier (fair use) | $1 per credit past allotment; TREX review = 3 credits | | **Git platforms** | GitHub, GitLab, Azure DevOps, Bitbucket | GitHub, GitLab | | **Self-hosting** | Enterprise only | Enterprise only | | **BYOK / model choice** | No | No | | **Open source** | No | No | | **Standout feature** | IDE + CLI reviews, linter/SAST bundling | TREX: writes and runs tests per PR in a sandbox | | **Learns from feedback** | Yes (learnings from team interactions) | Yes (reads your PR comments) | ## Context model: retrieval breadth vs graph depth This is the most important technical difference, and it's a real one — not marketing. **CodeRabbit** reviews the diff with supporting context: related files, your configured instructions, linter and SAST output, and "learnings" accumulated from how your team responds to its comments. It also layers process context on top — [Jira and Linear integration](https://www.coderabbit.ai/pricing) on Pro means it can see what the change was supposed to do. The result is a reviewer with wide but comparatively shallow situational awareness: strong on the change itself and its immediate blast radius, weaker on distant coupling. **Greptile** starts from the other end. It [indexes your repositories into a graph](https://www.greptile.com/), then dispatches parallel agents that traverse that graph to evaluate a change's impact on code far outside the diff — callers three modules away, an invariant maintained in a different service, a config contract the diff silently breaks. It learns team standards by reading your PR comments over time. Its TREX agent goes a step further than static judgment: it writes and runs tests for the PR in a sandbox, attempting to demonstrate bugs rather than merely assert them. If you're scoring these against the [multi-dimensional context standard](/standards/01-multi-dimensional-context), Greptile is clearly ahead on the codebase dimension; CodeRabbit is ahead on tooling (linters/SAST) and process context (tickets). Neither has the full picture. Which gap hurts more depends on your codebase: a modular monolith with subtle cross-module contracts bleeds through CodeRabbit's gap, while a team whose bugs are mostly local logic errors and standards violations won't feel it. ## Review quality: what the noise debate actually tells you Both tools have vocal fans and detailed public complaints, which is itself informative. **CodeRabbit's** signature failure mode is volume. The default output — summary, walkthrough, sequence diagram, inline comments — is thorough to a fault, and community threads have complained about nitpick density for years ([this HN thread](https://news.ycombinator.com/item?id=42484498) is representative). CodeRabbit has responded with configuration: review profiles including a quieter setting focused on high-impact issues, path filters, and custom instructions ([docs](https://docs.coderabbit.ai/)). The counter-evidence matters too: in [a recent HN discussion](https://news.ycombinator.com/item?id=46777079), a user reported that even CodeRabbit's low-confidence comments were frequently worth reading — that's what a well-tuned deployment looks like. **Greptile's** signature failure mode, when it fails, is confident wrongness. That same HN thread's original poster ran Greptile on three PRs and called the output "pretty much pure noise" — wrong suggestions, factually incorrect claims, and confidence scores that lent credibility to bad findings. Other teams (Greptile claims 22,000+, including Nvidia and PostHog) clearly get value. The honest synthesis: a graph index raises the ceiling on what the tool *can* see, but doesn't guarantee precision on what it *says*. Two takeaways for evaluators. First, both tools improve substantially with explicit rules — plain-English custom rules on Greptile, instructions and profiles on CodeRabbit — which is why we treat [rule-centric review](/standards/02-rule-centric) as a core standard rather than an advanced feature. Second, judge candidates on [actionability](/standards/08-actionability): what fraction of comments would a senior engineer act on? Run both on your five hardest recent PRs and count. It's the only benchmark that transfers to your team. ## Pricing: flat seats vs metered credits As of August 2026, from the vendors' own pricing pages: **[CodeRabbit](https://www.coderabbit.ai/pricing):** - **Free** — $0: PR summarization, IDE/CLI reviews, 14-day Pro Plus trial. - **Pro** — $24/dev/month billed annually: linters/SAST, Jira/Linear, agentic chat, analytics; rate-limited to 5 PR reviews per developer per hour. - **Pro Plus** — $48/dev/month billed annually: adds pre-merge checks, unit test generation, merge conflict resolution; 10 reviews/dev/hour. - **Enterprise** — custom: SSO, RBAC, audit logs, self-hosting; 12 reviews/dev/hour. Note that CodeRabbit retired its cheaper Lite plan in June 2026 ([announcement](https://kb.coderabbit.ai/articles/2508018126-sunset-of-lite-and-pro-legacy-subscription-plans)), so the floor for paid team plans is now $24. **[Greptile](https://www.greptile.com/pricing):** - **Starter** — free: 50 credits/month, one active developer. A standard review costs 1 credit; a TREX review costs 3. - **Pro** — $30/seat/month: 50 credits included per seat, $1 per additional credit, custom rules, integrations. A "seat" is any developer who received a review that billing period. - **Enterprise** — custom: self-hosting, SSO/SAML, GHES support. - Free for qualifying MIT/Apache open-source projects; 50% discount for pre-Series A startups under $2M revenue. **The math that matters:** a 10-developer team merging ~15 PRs per developer per month sits comfortably inside CodeRabbit Pro at a flat $240/month. The same team on Greptile Pro pays $300/month base and stays within credits — until you turn on TREX (3 credits per review triples burn) or review volume spikes, at which point $1/credit overage kicks in. Conversely, a 3-person team shipping 20 PRs a month might ride Greptile's free tier or a single seat far cheaper than CodeRabbit's per-developer billing. Metered pricing rewards low volume and punishes success; flat seats are the opposite. Model your own PR volume before deciding — our guide to [evaluating AI code review tools](/blog/how-to-evaluate-ai-code-review-tools) has a worksheet for exactly this. ## Integrations and platform support **Git platforms** is the cleanest dividing line. CodeRabbit supports [GitHub, GitLab, Azure DevOps, and Bitbucket](https://docs.coderabbit.ai/). Greptile supports GitHub and GitLab, full stop. If you're on Bitbucket or Azure DevOps, this comparison is over — it's CodeRabbit or a different alternative entirely. **Where reviews happen** differs too. CodeRabbit extends into the IDE (VS Code, Cursor, Windsurf extensions) and a CLI for pre-commit review that plugs into Claude Code, Cursor, and other agents — shifting review left of the PR. Greptile instead integrates with the agent ecosystem for fixing: MCP support, a Claude Code plugin, one-click IDE fixes, and its `/greploop` for iterative resolution with any coding agent. **Process context:** CodeRabbit connects Jira and Linear on Pro. Greptile's focus is code-side context rather than ticket-side. **Language coverage:** Greptile lists full support for Python, JavaScript/TypeScript, Go, Java, C/C++/C#, Swift, PHP, Rust, and Elixir, with partial support beyond. CodeRabbit is language-agnostic in its review layer, with linter/SAST depth varying by ecosystem. ## Setup and day-two operations Onboarding is quick for both — OAuth the git org, pick repos, get reviews on the next PR. The operational differences show up in week two. **Indexing:** Greptile has to build its graph before it's useful, so first reviews on a large monorepo arrive after an indexing pass, and the index is another moving part that must stay current as the codebase churns. CodeRabbit has no equivalent build step; it assembles context per review. **How they learn:** CodeRabbit's learnings accumulate from direct interaction — reply to a comment telling it a pattern is fine, and it stops flagging that pattern. Greptile learns by reading your team's organic PR comments, which is lower-effort but less steerable: you can't easily tell it to *unlearn* something. Both support explicit rules, which beat implicit learning for anything you actually care about — write the rule instead of hoping the model infers it. **Throughput ceilings:** CodeRabbit's are temporal — 5 reviews per developer per hour on Pro, which bites during release-day merge trains. Greptile's are financial — credits deplete and overage bills at $1 each, which bites at the end of a heavy month. Decide which failure mode your team tolerates better: a delayed review or a surprise line item. **Watching the spend:** on Greptile, someone should own credit monitoring, especially with TREX enabled at 3 credits per review. On CodeRabbit, cost is fixed but attention isn't — someone should own tuning the comment volume so the team keeps reading the output. Neither tool stays good unattended. ## Self-hosting and data control Short version: both say yes, neither means it below Enterprise. CodeRabbit offers self-hosting exclusively on its custom-priced Enterprise tier. Greptile likewise lists self-hosting as an Enterprise feature. On every standard plan for both products, your diffs and repository context flow through vendor-run infrastructure on models you don't choose, with no BYOK option — you can't pin an approved model, route to your Azure/Bedrock tenancy, or pay providers at list price. For regulated teams this usually plays out one of two ways: you negotiate an enterprise contract with one of these vendors, or you conclude the requirement is structural and go [self-hosted from the start](/blog/self-hosted-ai-code-review). The second path is where [open-source review tools](/blog/open-source-ai-code-review-tools) — Kodus under AGPLv3, PR-Agent under MIT — earn their place: deployment is a Docker Compose file, not a procurement cycle. ## When to pick CodeRabbit - **You're on Bitbucket or Azure DevOps.** Greptile doesn't support them. - **You want one tool doing many jobs** — summaries, linters, SAST, docstrings, ticket cross-checks — and you'll invest in tuning its volume down. - **You want predictable billing.** Flat per-seat pricing with known rate limits beats metering for steady, high PR volume. - **You want review before the PR.** The IDE and CLI review surfaces are genuinely useful for catching issues pre-commit. ## When to pick Greptile - **Your bugs are cross-file bugs.** If postmortems keep saying "the change looked fine locally but broke a distant caller," Greptile's graph index targets exactly that failure class. - **You want the tool to prove it.** TREX writing and executing tests in a sandbox is the strongest verification story in this matchup. - **You're a small or spiky-volume team on GitHub/GitLab.** The free tier and per-credit model can be dramatically cheaper than per-seat billing. - **You're an OSS project or early startup.** Free for qualifying MIT/Apache projects; half price for pre-Series A companies. ## When neither fits Be honest about the structural gaps both share, because no amount of configuration fixes them: - **Hard self-hosting requirements at non-enterprise budgets.** Both gate on-prem behind sales conversations. If your code can't leave your infra this quarter, you need a tool you can deploy yourself today. - **Model control.** Neither offers BYOK. If your security team has approved exactly one model provider, or you want token costs at list price with full usage visibility, both are out. - **Open-source requirements.** Some organizations now require auditable source for tools with repository access. Both are closed. - **Platform edges.** Forgejo, Gitea, or mixed fleets spanning Bitbucket and GitLab need broader coverage than either offers. In those cases, look at [Kodus](https://kodus.io) — open source (AGPLv3), built to run inside your own boundary: self-hosted via Docker Compose or Helm, models under your own keys on every plan (BYOK, no markup), plain-language Kody Rules for org-wide standards, and support for GitHub, GitLab, Bitbucket, Azure Repos, and Forgejo. Full disclosure: Kodus sponsors this site, so weigh that as you will — but the four gaps above are facts about vendor pricing pages, not opinions. For the wider field, our [best AI code review tools](/blog/best-ai-code-review-tools) roundup covers the full market, and if you're still forming the requirements list, start with [what AI code review actually does](/blog/what-is-ai-code-review) and score candidates with the [assessment](/assessment). ## Verdict Both tools are serious, and the loser in this comparison is anyone who picks based on a listicle instead of a trial. CodeRabbit is the safer default: more platforms, more surfaces, flat pricing, and a noise problem you can configure down. Greptile is the higher-variance pick: a genuinely deeper context model and sandbox-verified findings when it works, metered billing and confidence-weighted noise when it doesn't. Run both against your hardest recent PRs for two weeks — the tool that catches your actual bug class, on your actual codebase, wins. And if the dealbreaker is self-hosting, model control, or open source, the answer isn't either of them. ## FAQ ### Which is better, CodeRabbit or Greptile? Neither wins outright. CodeRabbit is the broader platform — summaries, linters, SAST, four git platforms, IDE and CLI reviews — at flat per-seat pricing. Greptile bets everything on whole-codebase context via its graph index and catches cross-file issues diff-focused tools miss. Pick CodeRabbit for breadth and predictable cost, Greptile for depth on GitHub/GitLab. ### Does Greptile really read my whole codebase? It indexes it. Greptile builds a graph index of your repositories, then review agents traverse that graph to assess how a change affects code outside the diff. That's materially deeper than diff-plus-retrieval, but indexing isn't understanding — community reports on precision are mixed, so trial it on your own code. ### Which is cheaper for a small team? Depends on volume. As of August 2026, CodeRabbit Pro is $24/dev/month billed annually, flat. Greptile Pro is $30/seat/month with 50 review credits per seat, then $1 per extra credit — and TREX reviews cost 3 credits each. Low PR volume favors Greptile's free tier or Pro allotment; steady volume favors CodeRabbit's flat seat. ### Can CodeRabbit or Greptile be self-hosted? Both gate self-hosting behind custom-priced Enterprise tiers. Neither offers it at standard prices. If self-hosting is a hard requirement rather than a negotiation, look at open-source options like Kodus (AGPLv3) or Qodo's PR-Agent (MIT), which anyone can deploy. ### Do they support Bitbucket or Azure DevOps? CodeRabbit does — it covers GitHub, GitLab, Azure DevOps, and Bitbucket. Greptile supports GitHub and GitLab only as of August 2026. If your code lives on Bitbucket or Azure DevOps, Greptile is out of the running entirely. ### Is Greptile noisier than CodeRabbit? Community evidence points both ways. CodeRabbit's classic complaint is verbosity and nitpicks, which its quieter review profile and custom instructions mitigate. Greptile drew a detailed Hacker News complaint calling its output pure noise with misleading confidence scores — while other users report high signal. Both depend heavily on how you configure rules. ### What if I need BYOK or model control? Neither tool offers bring-your-own-key on standard plans — both run opaque model pipelines and bill you at their margin. If controlling model choice and paying providers directly matters, that's a structural reason to look at BYOK-first tools like Kodus instead. # Cursor BugBot vs CodeRabbit: 2026 Comparison > Cursor BugBot vs CodeRabbit: review philosophy, pricing, platform support, and self-hosting compared — plus when neither fits. Verified August 2026. Cursor BugBot and CodeRabbit sit at opposite ends of the AI code review spectrum: BugBot is a deliberately narrow bug hunter with usage-based pricing (around $1.00-1.50 per run, per Cursor's estimates), while CodeRabbit is a full review platform — summaries, linters, SAST, standards — at $24-48 per developer per month. Pick BugBot if you want high-signal bug detection with minimal ceremony; pick CodeRabbit if you want one tool to run your whole review process; pick neither if you need self-hosting or model control without an enterprise contract. Facts below verified as of August 2026. ## TL;DR comparison | | Cursor BugBot | CodeRabbit | |---|---|---| | **Scope** | Bugs, security issues, rule violations | Full review: summaries, walkthroughs, linters/SAST, standards, inline comments | | **Pricing model** | Usage-based (~$1.00-1.50/run, vendor estimate), bundled with Cursor plans | Per-seat: Free / $24 / $48 per dev/month (annual); Enterprise custom | | **Git platforms** | GitHub (incl. GHES), GitLab (incl. self-hosted), Bitbucket (incl. Data Center), Azure DevOps (limited) | GitHub, GitLab, Azure DevOps, Bitbucket | | **Rules/customization** | `.cursor/BUGBOT.md` files, learned repo rules, org-wide team rules | Review profiles, path filters, custom instructions, learnings | | **Fix loop** | "Fix in Cursor" opens findings in the editor | IDE extensions (VS Code, Cursor, Windsurf) + CLI pre-commit reviews | | **Self-hosting** | No (service is SaaS-only) | Enterprise tier only | | **BYOK / model choice** | No (effort levels only) | No | | **Open source** | No | No | | **Standalone product** | No — part of Cursor plans | Yes | ## Two different theories of code review Understanding this matchup starts with what each vendor believes review automation is *for*. **BugBot's theory:** the highest-value thing an AI reviewer can do is find bugs humans miss, and everything else is noise. So [BugBot](https://cursor.com/docs/bugbot) analyzes PR diffs for bugs, security vulnerabilities, and violations of your configured standards — and stops there. No summary comment, no walkthrough, no sequence diagram, no docstring suggestions. It reads existing top-level and inline PR comments so it doesn't duplicate what a human already said. The design bet is that a reviewer that speaks rarely gets taken seriously when it speaks. **CodeRabbit's theory:** review is a process, not an event, and automation should carry as much of it as possible. So [CodeRabbit](https://docs.coderabbit.ai/) generates PR summaries and walkthroughs, aggregates linters and SAST, checks changes against Jira/Linear tickets, chats about the diff, and comments across the spectrum from real defects to style preferences. The design bet is that saving reviewers time on comprehension and mechanics is worth more than minimalism. Neither theory is wrong. They optimize different failure modes: BugBot guards against the reviewer-fatigue problem where a chatty bot trains engineers to skim past everything it says; CodeRabbit guards against the blank-page problem where reviewers burn time reconstructing what a PR even does. Your team's pain determines which matters — a team drowning in unreviewed PRs wants CodeRabbit's comprehension aids; a team with healthy review culture but escaping bugs wants BugBot's precision posture. Our take on why signal density decides adoption is the [actionability standard](/standards/08-actionability): a bot's comments are only as valuable as the fraction engineers actually act on. ## Context and review depth **BugBot** works from the PR diff plus targeted context: your rule files, surrounding code, and the existing comment thread. Cursor's [May 2026 update](https://cursor.com/blog/may-2026-bugbot-changes) added selectable effort levels — the default targets what Cursor reports as an 80% bug resolution rate (the share of flagged bugs that developers actually fix), while the high-effort mode "finds 35% more bugs while resolution rate stays constant at 80%," per Cursor's own numbers. Treat those figures as vendor-reported, not independently verified — but note what the metric *is*: Cursor grades itself on whether developers act on findings, which is the right thing to optimize. **CodeRabbit** assembles broader context per review: related files, accumulated "learnings" from how your team responded to past comments, linter and static-analysis output, and ticket context from Jira/Linear on paid plans. It also reviews in more places — IDE extensions for VS Code, Cursor, and Windsurf, plus a CLI that runs pre-commit reviews and hooks into coding agents like Claude Code. Neither tool indexes your entire codebase into a persistent graph the way Greptile does, so both are strongest on the change itself and its near neighborhood — worth knowing if your bug class is cross-module breakage. For the taxonomy of what context a reviewer can draw on (code, standards, tickets, history), see [multi-dimensional context](/standards/01-multi-dimensional-context). ## Rules and customization Both tools take configuration seriously, with different ergonomics. **BugBot** reads `.cursor/BUGBOT.md` files: the root file always applies, and files discovered while traversing up from modified paths get included, so a `services/payments/.cursor/BUGBOT.md` can carry payments-specific review logic. Admins can add repo-level rules — including *learned* rules BugBot generates from team activity — and org-wide team rules. There's a hard cap: the combined rule set tops out at 100,000 characters per review (30,000 per individual rule), and rules get dropped if you exceed it. Predictable, file-based, versioned with your code. **CodeRabbit** offers review profiles (including a quieter setting focused on high-impact comments), path-based filters and instructions, and its learnings system, which accumulates team preferences from review interactions rather than requiring everything up front. More knobs, more surface area — and correspondingly more tuning debt if nobody owns the configuration. The pattern to notice: both vendors converged on plain-language, path-scoped rules as the customization backbone. That convergence is the whole thesis of [rule-centric review](/standards/02-rule-centric) — generic best-practice review is a commodity; encoding *your team's* standards is where the value is. Whichever tool you pick, budget the week it takes to write the rules, or you'll get the demo experience forever. ## Pricing: metered runs vs flat seats As of August 2026: **BugBot** moved from $40/seat/month to usage-based billing, effective at each customer's renewal after June 8, 2026 ([announcement](https://cursor.com/blog/may-2026-bugbot-changes)). Cursor estimates the average run at **$1.00-1.50 depending on PR size and complexity**. BugBot isn't sold standalone: individual [Cursor plans](https://cursor.com/pricing) (Pro from $20/month) include usage-based BugBot, and Teams plans ($40/user/month) include agentic code reviews with BugBot, with on-demand spend beyond included usage. Fair warning: the transition confused Cursor's own customers ([forum thread](https://forum.cursor.com/t/i-find-new-bugbot-pricing-difficult-to-understand/122143)), so model your PR volume before assuming it's cheaper. **CodeRabbit** is flat per-seat ([pricing](https://www.coderabbit.ai/pricing)): Free tier with PR summaries and IDE/CLI reviews; **Pro at $24/dev/month** billed annually (linters/SAST, Jira/Linear, analytics, 5 PR reviews per dev per hour); **Pro Plus at $48** (pre-merge checks, unit test generation, 10 reviews/hour); Enterprise custom with self-hosting. The cheaper Lite plan was [retired in June 2026](https://kb.coderabbit.ai/articles/2508018126-sunset-of-lite-and-pro-legacy-subscription-plans). **The crossover math:** at $1.25 per average run, a developer merging 15 PRs a month costs roughly $19 in BugBot runs — under CodeRabbit Pro's $24 seat. At 25 PRs it's ~$31 and CodeRabbit is cheaper, before counting the Cursor subscription you need anyway (which many teams already pay for the editor). High-volume teams favor flat seats; low-volume or spiky teams favor metering. Also compare *what you get* per dollar: CodeRabbit's seat buys summaries, linters, and process tooling BugBot simply doesn't produce. ## Integrations and ecosystem **Git platform support is broad on both sides** — a pleasant surprise in a market where most challengers are GitHub-only. BugBot covers GitHub including GitHub Enterprise Server, GitLab including self-hosted instances, Bitbucket including Data Center, and Azure DevOps in limited availability ([docs](https://cursor.com/docs/bugbot)). CodeRabbit covers GitHub, GitLab, Azure DevOps, and Bitbucket. **The fix loop is where they diverge.** BugBot's "Fix in Cursor" buttons open findings directly in the editor with context loaded — if your team writes code in Cursor, flag-to-fix is genuinely frictionless, and that lock-in is the strategy. CodeRabbit is editor-neutral: extensions for VS Code, Cursor, and Windsurf, a CLI for pre-commit review, agentic chat on the PR, and one-click commitable suggestions. **Process integrations** favor CodeRabbit: Jira and Linear ticket context, analytics dashboards, and reporting live in the product. BugBot has none of that — again, deliberately. ## Self-hosting and data control Neither tool will satisfy a hard data-residency requirement at standard pricing, but they fail differently. **BugBot: no self-hosting, full stop.** It *connects to* self-hosted git servers (GHES, self-hosted GitLab, Bitbucket Data Center) — which covers many enterprise topologies — but the review service itself runs on Cursor's infrastructure, on models Cursor selects. There is no BYOK, no model pinning, no on-prem deployment. **CodeRabbit: self-hosting exists, behind Enterprise.** The custom-priced tier includes self-hosting, SSO, RBAC, and audit logs. Below that, your diffs flow through CodeRabbit's cloud with no model choice. If code-leaves-the-building is a compliance line rather than a preference, the honest answer is that this entire matchup is the wrong shortlist — that's [self-hosted AI code review](/blog/self-hosted-ai-code-review) territory, where [open-source tools](/blog/open-source-ai-code-review-tools) you can deploy yourself are the realistic options. ## Running a fair trial Because these tools have such different shapes, naive side-by-side comparison misleads: CodeRabbit will always produce more comments, and counting comments rewards the wrong thing. A fairer two-week protocol: 1. **Enable both on the same two or three active repos**, BugBot via usage-based billing (cheap at trial volume) and CodeRabbit on its free trial. 2. **Write rules for both on day one** — port your existing conventions into `.cursor/BUGBOT.md` and CodeRabbit's instructions. Untuned trials test defaults, not tools. 3. **Track one number per tool: acted-upon findings.** A comment counts only if an engineer changed code (or filed a ticket) because of it. Nitpicks someone reluctantly appeased don't count. 4. **Separately, note comprehension value.** If reviewers say CodeRabbit's summaries made big PRs faster to pick up, that's real value BugBot doesn't attempt — record it as its own line, not as review quality. 5. **Replay your last three escaped bugs.** Open PRs recreating defects that actually shipped and see who catches them. Small sample, but it's *your* bug distribution, which beats any vendor benchmark. At the end you'll have something a pricing page can't give you: each tool's acted-upon rate on your codebase, and a defensible cost per useful finding. ## When to pick Cursor BugBot - **Your team already pays for Cursor.** The reviewer is bundled, the fix loop is native, and there's no new vendor to onboard. - **You want signal, not ceremony.** If your review culture is healthy and you just want escaped-bug insurance, BugBot's narrow scope is a feature. - **Your PR volume is modest or spiky.** Metered pricing beats a $24-48 seat when developers merge a handful of PRs monthly. - **You're on self-hosted git.** GHES, self-hosted GitLab, and Bitbucket Data Center support without an enterprise contract is unusual. ## When to pick CodeRabbit - **You want the review process carried, not just bugs flagged.** Summaries, walkthroughs, linter aggregation, and ticket cross-checks compound for teams with heavy review load. - **Reviewers spend more time understanding PRs than critiquing them.** CodeRabbit's comprehension aids attack the actual bottleneck. - **You want review before the PR exists.** The CLI and IDE surfaces catch issues pre-commit — BugBot has no equivalent. - **You don't use Cursor.** Buying into an editor ecosystem to get a review bot is backwards; CodeRabbit is standalone and editor-neutral. - **Predictable billing matters.** Flat seats are easier to budget than metered runs. ## When neither fits Shared structural gaps that no configuration fixes: - **Self-hosting on a normal budget.** BugBot: never. CodeRabbit: Enterprise only. - **Model control.** Neither offers BYOK. You can't pin an approved model, route to your own Azure/Bedrock tenancy, or pay token costs at provider list price. - **Open source.** Both are closed. If tools with read access to your entire codebase need auditable source in your org, both are out. - **Standards-first review without platform buy-in.** BugBot's rules ride inside Cursor's ecosystem; CodeRabbit's breadth comes with its noise-tuning tax. If those gaps describe your situation, look at [Kodus](https://kodus.io) — an open-source (AGPLv3) reviewer built to run where your organization controls: self-hosted via Docker Compose or Helm on any plan, models under your own keys and audit scope (BYOK, no token markup), plain-language Kody Rules for enforcing org-wide standards, and support for GitHub, GitLab, Bitbucket, Azure Repos, and Forgejo. Disclosure: Kodus sponsors this site; the structural facts above come from the vendors' own pricing and docs pages, so verify them yourself in ten minutes. For the full landscape, see [the best AI code review tools in 2026](/blog/best-ai-code-review-tools), brush up on [how this category actually works](/blog/what-is-ai-code-review), and pressure-test any shortlist with our [evaluation guide](/blog/how-to-evaluate-ai-code-review-tools) or the interactive [assessment](/assessment). ## Verdict This is the rare comparison where "which is better" has a clean answer once you name your problem. Escaping bugs with a healthy review culture: BugBot, especially if Cursor is already your editor — the narrow scope and metered pricing are exactly right for a second pair of eyes. Overloaded reviewers and inconsistent standards: CodeRabbit, which does far more per seat and has spent years building the process tooling around review — just assign someone to tune the volume down. And if your requirements include self-hosting, model control, or auditable source, stop forcing this shortlist and evaluate the open-source side of the market instead. The worst outcome isn't picking the wrong one of these two; it's paying for either and never writing the rules that make any AI reviewer worth reading. ## FAQ ### Is Cursor BugBot a full replacement for CodeRabbit? No — and it doesn't try to be. BugBot is deliberately scoped to bugs, security issues, and rule violations, with no PR summaries, walkthroughs, or docstring generation. CodeRabbit is a full review platform with linters, SAST, summaries, and ticket integration. BugBot replaces CodeRabbit only if bug detection is all you actually wanted. ### How much does Cursor BugBot cost per review? Cursor estimates the average BugBot run costs $1.00-1.50 depending on PR size and complexity, under the usage-based billing introduced at renewals after June 8, 2026. Individual Cursor plans include some BugBot usage; teams pay on-demand spend. The old $40/seat/month subscription is being phased out at renewal. ### Do I need a Cursor subscription to use BugBot? Effectively yes. BugBot is part of Cursor's plans rather than a standalone product — individual Pro plans (from $20/month) include usage-based BugBot, and Teams plans include agentic code reviews with BugBot. If your team doesn't use Cursor, you're buying into its ecosystem to get the reviewer. ### Which is noisier, BugBot or CodeRabbit? CodeRabbit, by design. Its default output includes summaries, walkthroughs, and inline comments spanning style to security, and nitpick complaints are common (though its quieter profile and custom instructions help). BugBot's narrow scope means fewer comments overall — it hunts bugs rather than commenting on everything reviewable. ### Which platforms do BugBot and CodeRabbit support? Both are broad. BugBot supports GitHub (including GHES), GitLab (including self-hosted), Bitbucket (including Data Center), and Azure DevOps with limited availability. CodeRabbit supports GitHub, GitLab, Azure DevOps, and Bitbucket, plus IDE extensions and a CLI for pre-commit reviews. ### Can BugBot or CodeRabbit be self-hosted? BugBot cannot be self-hosted at all — it connects to self-hosted git servers, but the review service runs on Cursor's infrastructure. CodeRabbit offers self-hosting only on its custom-priced Enterprise tier. If self-hosting on a normal budget is the requirement, open-source tools like Kodus (AGPLv3) or PR-Agent (MIT) are the realistic path. ### Can I use BugBot and CodeRabbit together? Yes, and some teams do: CodeRabbit for summaries, standards enforcement, and linter aggregation, BugBot as a second opinion on bugs. It doubles review spend and comment volume, so most teams treat it as an evaluation phase — run both for two weeks, count which comments engineers act on, keep the winner. # How to Evaluate AI Code Review Tools (2026): A Playbook > A practical playbook for how to evaluate AI code review tools: a 9-standard scoring rubric, red flags, a 2-week trial protocol, and vendor questions. To evaluate AI code review tools, score them against nine measurable standards — context depth, noise discipline, workflow separation, business-logic awareness, learning, runtime validation, economic transparency, actionability, and provable ROI — and then run a two-week instrumented trial on your own repositories: plant known bugs to measure recall, label every comment to measure signal-to-noise, and compare time-to-merge against a pre-trial baseline. A demo and a feature matrix cannot tell you whether a reviewer works on your codebase. A trial with numbers can. This playbook turns those nine standards into something you can execute: a weighted scoring rubric, the red flags that should end an evaluation early, a day-by-day trial protocol, and the questions that separate real answers from sales answers. ## Why most evaluations of AI code reviewers fail Most teams evaluate AI code review the way they evaluate a linter: install it on one repo, watch it comment for a few days, and go with gut feel. That process fails for three predictable reasons. **The first week is the honeymoon.** Every AI reviewer looks impressive on day one because any plausible-sounding comment feels like magic. The failure modes — repetitive nitpicks, hallucinated APIs, suggestions that ignore your architecture — show up over weeks, after the team has stopped reading carefully. If you're new to the category, start with [what AI code review actually is](/blog/what-is-ai-code-review) and what it structurally can and cannot do. **Demos are run on codebases chosen by the vendor.** A reviewer that shines on a clean, single-repo TypeScript project may collapse on your 9-year-old monorepo with three languages and a service mesh. The only codebase that matters is yours. **Nobody measures.** "The team seems to like it" is not an evaluation. Without a baseline for time-to-merge, a count of actionable versus noise comments, and a recall number against known bugs, you are choosing based on vibes — and you will re-run the whole evaluation in six months when the vibes wear off. The fix is to treat the evaluation like an engineering problem: define the criteria up front, instrument the trial, and let the numbers decide. ## The nine standards, and how to test each one These nine standards define what a production-grade AI code reviewer looks like in 2026. For each one: what it means, how to test it during a trial, and the red flags that should cost points — or end the conversation. ### 1. Multi-dimensional context A reviewer that only reads the git diff is reviewing a chapter without knowing the plot. It must index the whole repository, resolve cross-repo dependencies, and understand the intent behind the change. Full standard: [Multi-dimensional Context](/standards/01-multi-dimensional-context). **How to test:** Open a PR that changes a shared interface or API contract, then check whether the reviewer flags the consumers of that interface elsewhere in the codebase — or, better, in a sibling repository. Also watch for hallucinations: suggestions to call helpers that don't exist in your project. **Red flags:** The tool suggests functions from libraries you don't use. It "optimizes" code in ways that break callers it never saw. It enforces generic style conventions instead of reading your existing code and contribution docs. ### 2. Rule-centric and default quiet Unprompted style opinions are a linter's job done badly. Every stylistic or architectural comment should be backed by an explicit, version-controlled team rule; absent a rule or an objective bug, the reviewer should stay silent. Full standard: [Rule-Centric & Default Quiet](/standards/02-rule-centric). **How to test:** Run the tool with zero configuration on five real PRs and count the comments. Then define three team rules in plain language (for example: "never log request bodies", "all money math uses the decimal type", "no new endpoints without an authorization check") and verify the tool enforces exactly those — and stops commenting on things you never asked about. **Red flags:** Comments about naming, indentation, or missing semicolons. Ten-plus comments on a routine PR. No mechanism to define rules as versioned plain text alongside the code. ### 3. Dual workflow: local vs. PR The IDE is for exploration; the PR is for verification. A reviewer that behaves identically in both — verbose everywhere, or silent everywhere — will either exhaust the team in PRs or be useless locally. Full standard: [Dual-Workflow: Local vs. PR](/standards/03-dual-workflow). **How to test:** Check whether the tool offers a local surface (CLI, IDE, pre-commit) at all, and whether its PR behavior is configurably stricter than its local behavior. **Red flags:** The PR bot brainstorms alternative architectures on "done" code. There is one global verbosity setting for every surface. The vendor treats "IDE plugin" and "PR reviewer" as the same product with two logos. ### 4. Business logic validation Whether code compiles is a solved problem. The hard question is whether the code does what the ticket asked. A 2026-grade reviewer connects to your issue tracker via MCP or a native integration, reads the acceptance criteria, and reviews the PR against intent. Full standard: [Business Logic Validation](/standards/04-business-logic). **How to test:** Link a PR to a ticket with three explicit acceptance criteria, and deliberately leave one unimplemented. Does the reviewer notice? Even partial credit here — surfacing the ticket and summarizing the gap — is worth more than a dozen syntax observations. **Red flags:** No issue-tracker integration at all. The tool reviews a PR titled "Fix ENG-104" with no idea what ENG-104 says. It praises a technically clean implementation of the wrong feature. ### 5. Continuous learning Correcting the same bot mistake twice is how trust dies. Rejections should update the tool's context — or propose a new team rule — so the same suggestion never comes back. Full standard: [Continuous Learning](/standards/05-continuous-learning). **How to test:** This is the repetition test in the week-two protocol below: explicitly reject a category of suggestion, then count how many PRs pass before it reappears. **Red flags:** A static system prompt with no per-team memory. Rejected suggestions reappearing within days. No way to see what the tool has "learned" about your team, and no way to correct it. ### 6. Sandbox validation A suggestion that has never been executed is a hypothesis. The strongest reviewers can validate assumptions at runtime — generating tests for their own fixes, exercising preview environments, probing edge cases. Full standard: [Sandbox Validation](/standards/06-sandbox-validation). **How to test:** When the tool proposes a non-trivial fix, check whether it ships a verifying test with it, and whether the suggested code actually compiles and passes CI when applied unmodified. **Red flags:** Suggested fixes that don't compile. Refactors that break an API contract the tool never checked. Confident claims about runtime behavior ("this will deadlock") with no way to substantiate them. ### 7. Economic transparency If a vendor charges $30 per seat per month for what amounts to $0.50 of LLM calls, you are paying a wrapper tax. You should be able to bring your own API keys, choose which models run which tasks, and see exactly what tokens cost. Full standard: [Economic Transparency](/standards/07-economic-transparency). **How to test:** Ask for per-PR token and cost telemetry during the trial. Ask whether you can plug in your own OpenAI, Anthropic, or Azure OpenAI credentials. Divide your trial's total cost by PRs reviewed and write that number down — it's the denominator of every ROI claim. **Red flags:** Opaque per-seat pricing with no usage visibility. No BYOK option. Lock-in to a single model provider. A vendor that cannot — or will not — tell you how many tokens a review consumed. ### 8. Actionability An auditor points at problems; an engineer fixes them. If the reviewer found an issue, it should produce the exact diff that fixes it, applyable in one click — with imports resolved and surrounding code respected. Full standard: [Actionability](/standards/08-actionability). **How to test:** During the trial, count what fraction of comments come with a committable code suggestion, and how many of those apply cleanly and pass CI. Also check what happens to valid-but-deferred suggestions: do they become tracked tech-debt issues, or evaporate? **Red flags:** Five-paragraph explanations with no code. Suggestions referencing utilities that were never imported. "Consider refactoring this" as a complete review comment. ### 9. Measurable ROI Six months in, your CFO will ask whether the tool is working, and "the team likes it" is not an answer. The platform itself should track acceptance rate, cycle time impact, bugs caught pre-merge, and cost per PR. Full standard: [Measurable ROI](/standards/09-measurable-roi). **How to test:** Ask to see the dashboard during the trial — with your data in it. If the tool doesn't measure its own acceptance rate, you'll be measuring it by hand forever. **Red flags:** No analytics beyond "comments posted." No way to correlate reviews with time-to-merge or escaped bugs. ROI claims in the sales deck that the product itself cannot reproduce. ## The scoring rubric Score each standard 0-5 based on trial evidence, not vendor claims. The weighted total gives you a comparable score out of 100 across tools. | Standard | Weight | 5 looks like | 0 looks like | |---|---|---|---| | 1. Multi-dimensional context | 15 | Flags cross-file and cross-repo impacts; zero hallucinated APIs in the trial | Diff-only review; invents helpers your repo doesn't have | | 2. Rule-centric, default quiet | 15 | Silent unless a rule or real bug is violated; rules are plain text in version control | Unprompted style nitpicks on every PR; no rules mechanism | | 3. Dual workflow | 5 | Distinct local and PR behavior; strict, surgical PR mode | One verbosity everywhere, or no local surface at all | | 4. Business logic validation | 10 | Reads the linked ticket; flags the unimplemented acceptance criterion | No issue-tracker awareness whatsoever | | 5. Continuous learning | 10 | Rejected suggestion never returns; rejections can become team rules | Same rejected suggestion within 3 PRs | | 6. Sandbox validation | 5 | Fixes ship with verifying tests; suggestions pass CI unmodified | Suggested code doesn't compile | | 7. Economic transparency | 10 | BYOK, model choice per task, per-PR cost telemetry | Opaque seat pricing, single locked model, no usage data | | 8. Actionability | 15 | Nearly every finding has a one-click, CI-passing fix; ignored suggestions become tracked issues | Prose-only comments; broken suggested diffs | | 9. Measurable ROI | 15 | Live dashboard: acceptance rate, cycle time, cost per PR | No analytics; "trust us" | Scoring guidance: a 3 means the capability exists and worked in your trial with caveats; a 5 means it worked without your team compensating for it. Do not award points for roadmap items — "coming next quarter" scores zero, because you are buying what exists. **Interpreting the total:** below 50, pass — the tool will be muted within a quarter. 50-70, viable if its weak standards are ones you don't care about (a solo-repo startup can shrug at multi-repo context). Above 70, adopt and negotiate. If two tools land within 5 points, the tiebreakers are economic transparency and learning, because those determine cost and annoyance at scale. Weights are a starting point. A regulated fintech should bump business logic validation and actionability; a platform team drowning in bot noise should bump rule-centricity. Change the weights before the trial, not after — deciding weights after you've seen scores is how you rationalize a favorite. ## The two-week trial protocol Run this on 1-2 real, active repositories. If you're comparing tools, run them on different repos, or on the same repo with only one tool commenting per PR — two bots on one PR contaminates every measurement. ### Day 0: baseline before the bot You cannot measure change without a "before." From your Git provider's data, capture the previous 4 weeks: - **Median time-to-merge** (first commit to merge) per repo. - **Median human review comments per PR**, and roughly how many led to a code change. - **Escaped defects:** bugs filed against code merged in that window, if your tracker supports the query. Also set up a shared spreadsheet with one row per bot comment and four labels: **actionable** (a developer changed code because of it), **correct-but-trivial** (true, but nobody acted), **wrong** (factually incorrect or hallucinated), **duplicate** (repeat of previously rejected feedback). Fifteen minutes of labeling per day is the entire cost of a rigorous evaluation. ### Week 1: recall and raw noise **Plant known bugs.** Create 2-3 sacrificial PRs seeded with 8-12 real bugs — ideally reintroduced from your actual bug history, lightly disguised. Cover distinct categories: 1. An off-by-one in a loop boundary 2. A SQL query built with string interpolation 3. A new endpoint missing the authorization check every sibling endpoint has 4. A race condition on shared state 5. An N+1 query in a hot path 6. A null/undefined dereference on an optional field 7. A resource leak (unclosed connection or file handle) 8. A hardcoded secret in a config file 9. A timezone bug (naive datetime crossing a boundary) 10. A business-rule violation: code that contradicts the linked ticket's acceptance criteria Record which bugs each tool catches. **Recall on planted bugs is your single most honest capability number.** Expect no tool to catch everything — the race condition and the business-rule violation are genuinely hard, and that's the point: they discriminate between tools. Anything below 60% on the list overall, or a miss on the SQL injection or the missing auth check, is disqualifying. **Run real PRs with zero configuration.** Let the tool comment on every real PR this week, unconfigured, and label everything. This measures the out-of-the-box signal-to-noise — what a new team on this tool would actually experience. ### Week 2: rules, learning, and cost **Configure rules.** Write 3-5 team rules in the tool's rules mechanism, drawn from real conventions ("we use date-fns, never moment.js" is the classic). Verify the tool enforces them — and verify the noise from week 1 drops. A tool that can't get quieter when told to is not [default quiet](/standards/02-rule-centric); it's default loud with settings. **Run the repetition test.** Explicitly reject one category of suggestion — dismiss it with a comment explaining why. Then count PRs until it reappears. Reappearance within three PRs fails [continuous learning](/standards/05-continuous-learning) outright. **Measure time-to-merge.** Compare the trial's median time-to-merge against your Day 0 baseline. Two weeks is too short to prove a speedup — but it is plenty to catch a regression. If time-to-merge went up because developers are triaging bot comments, that's a red flag no feature offsets. **Compute cost per PR.** Total trial cost (tokens if BYOK, or prorated seats) divided by PRs reviewed. You'll need this number for the ROI conversation, and vendors who can't help you compute it are telling you something. ### The numbers that decide | Metric | How you got it | Healthy range | |---|---|---| | Planted-bug recall | Seeded PRs, week 1 | 60%+ overall; 100% on injection and authz | | Actionable-comment rate | Label sheet | 50%+ of all comments | | Wrong-comment rate | Label sheet | Under 20%, trending down in week 2 | | Repetition after rejection | Week 2 test | Zero recurrences | | Time-to-merge delta | Baseline vs. trial | Flat or better; any sustained increase fails | | Cost per PR | Spend ÷ PRs reviewed | Known and explainable — the number existing matters most | Feed the evidence into the rubric, compute weighted totals, decide. If you want a shortlist to run this protocol against, our comparison of the [best AI code review tools](/blog/best-ai-code-review-tools) is a reasonable starting bench. ## Questions to ask vendors Ask these with the trial data in front of you. Vague answers to specific questions are answers. **Context and correctness** - "Does the reviewer index the full repository, or only the diff plus N lines of context? How do you handle cross-repository dependencies?" - "Show me a hallucinated suggestion from any customer and walk me through what you changed." **Noise and rules** - "What does the tool comment on with zero configuration? Can we see the default severity thresholds?" - "Are team rules plain text in our repo, or settings in your UI? What happens to them if we leave?" **Learning** - "When a developer rejects a suggestion, what concretely updates? Where can we inspect what the tool has learned about our team?" **Economics** - "Can we bring our own API keys and choose models per task? What exactly do we pay you for, if not tokens?" (The wrong answer to this one is the [wrapper tax](/standards/07-economic-transparency) in action.) - "What's the average cost per PR across your customers, and will we see ours in the product?" **Accountability** - "Which metrics does your dashboard track — acceptance rate, time-to-merge impact, bugs caught? Can we export them?" - "If the acceptance rate of your suggestions is below 30% after 90 days, what do you do about it?" **Deployment and data** - "Where does our code go, and to whom? Is there a self-hosted or BYOK option if InfoSec requires it?" - "What happens to our data, embeddings, and learned context when we cancel?" A note on disclosure: this site is sponsored by [Kodus](https://kodus.io), an open-source (AGPLv3) AI code reviewer designed around these standards — self-hostable, BYOK, with plain-text team rules (Kody Rules). A sponsor naturally thinks it scores well on this rubric, but the rubric is the point: run the protocol, and let your numbers pick the tool — sponsor's or anyone else's. ## Run the assessment The nine standards give you the criteria; the trial gives you the evidence; the rubric turns evidence into a decision your CFO can audit. Before you schedule a single vendor call, spend ten minutes scoring your current setup — or the tool you're already trialing — against the standards with our [assessment](/assessment). It will tell you exactly where your biggest gaps are, and which standards deserve extra weight when you run this playbook for real. ## FAQ ### How long should a trial of an AI code review tool take? Two weeks of instrumented use on real repositories is the minimum. Week one measures raw signal-to-noise and recall on planted bugs; week two measures whether the tool responds to your rules and feedback. Anything shorter only tells you what the demo already told you. ### What is a good signal-to-noise ratio for an AI code reviewer? In a two-week trial, at least half of all comments should be actionable — something a developer actually changes code in response to. If fewer than 50% of comments are actionable, or more than 20% are outright wrong, the tool will get muted within a quarter. ### Should we test AI code review tools on real PRs or synthetic ones? Both, because they measure different things. Synthetic PRs with planted bugs measure recall — does the tool catch what you know is there. Real PRs measure precision and noise — what does the tool say when nothing is wrong. A tool needs to pass both tests. ### How many AI code review tools should we trial at once? Two or three, on different repositories or with only one commenting per PR. Running two bots on the same PR doubles the noise and contaminates your time-to-merge measurements. Use the same planted-bug set and the same rubric for each so scores are comparable. ### How do we measure whether an AI code review tool actually saves time? Baseline your median time-to-merge and human review effort for 4 weeks before the trial, then compare during the trial. Two weeks is too short to prove a speedup, but it is enough to catch a regression — if time-to-merge goes up because developers are triaging bot comments, that is disqualifying. ### Are open-source AI code review tools worth including in an evaluation? Yes, and they are easy to include because you can trial them without a sales call. Tools like Kodus (AGPLv3) and PR-Agent (MIT) run against your own LLM API keys, which also gives you a true cost-per-PR number to compare against per-seat pricing. ### What is the single biggest red flag when evaluating an AI code reviewer? Repetition. If you reject a suggestion and the tool makes the same suggestion again a few PRs later, it has no feedback loop. Teams forgive a wrong comment once; a tool that cannot learn from rejection gets uninstalled. # Open Source AI Code Review: The Real Options (2026) > Open source AI code review tools compared: Kodus (AGPL), PR-Agent (MIT), and more — real licenses, BYOK costs, and how they stack up against closed SaaS. Open source AI code review means you can read the reviewer's code, run it on your own infrastructure, and point it at models you control — instead of shipping every pull request to a closed SaaS. As of August 2026, the serious options are Kodus (AGPL-3.0, the most complete platform), PR-Agent (MIT, community-maintained since Qodo handed it over), and a handful of lighter tools like ai-review and OpenReview. This guide covers what's genuinely open source, what just markets the word, and when a closed tool is honestly the better call. Disclosure before anything else: Kodus sponsors this site, and Kodus is one of the tools reviewed here. Every license and claim below is verifiable in public repos, and we've been as blunt about Kodus's limitations as everyone else's. ## First, check the license — "open source" is doing a lot of work in 2026 Vendors have noticed that "open source" converts, and the term gets stretched three ways in this category: 1. **Actually open source.** A public repo with an OSI-approved license (MIT, Apache-2.0, AGPL-3.0). You can fork it, audit it, self-host it, and the license survives the vendor pivoting or dying. 2. **Open core / dual license.** The core is open, some features are commercial. This is legitimate — Kodus works this way (AGPL core, enterprise-marked files under a commercial license) — but you should know exactly which files sit on which side before you build on them. 3. **"Open source" as a vibe.** A repo that says open source in the README but ships no license file at all — which legally means all rights reserved, and you technically can't even self-host it safely. We found exactly this while researching: Vercel's OpenReview describes itself as "an open-source, self-hosted AI code review bot," but as of August 2026 the repository contains no license file. That's presumably an oversight, but until it's fixed, it isn't open source. The 30-second audit before adopting anything: open the repo, check the `LICENSE` file (not the README), check the last commit date, and check whether "enterprise" directories carry different terms. Every claim in this post went through that filter. ## Why open source matters more for code review than for most tools For a terminal theme, licensing is philosophy. For an AI code reviewer, it's operational: - **Your code is the input.** A code reviewer reads every diff your team produces — arguably your most sensitive IP stream. With a closed SaaS you're trusting a privacy policy; with self-hosted open source, the code path is inspectable and the data never has to leave your network. This is the whole argument of our [self-hosted AI code review guide](/blog/self-hosted-ai-code-review). - **You can audit the reviewer's judgment.** Review quality depends on what context the tool assembles and what it asks the model — see [multi-dimensional context](/standards/01-multi-dimensional-context). In an open tool, the prompts and context pipeline are readable code. In a closed tool, they're a black box that changes without notice. - **BYOK economics.** Open tools let you bring your own model keys, paying providers at list price with no markup, and swapping models as the frontier moves. Closed per-seat pricing bundles model costs opaquely — you can't see what you're actually paying for inference. - **No rug-pulls.** Pricing on closed tools moved a lot in 2026 (Cursor's BugBot switched from $40/seat to usage-based billing; GitHub Copilot moved to metered credits). An AGPL or MIT tool can change its pricing too — but the version you run today is yours forever. If you're still weighing whether AI review belongs in your pipeline at all, start with [what AI code review is](/blog/what-is-ai-code-review) and how it [differs from static analysis](/blog/ai-code-review-vs-static-analysis). ## The genuinely open source options, compared Licenses and activity verified on GitHub, August 2026. | Tool | License | Stars (Aug 2026) | Platforms | Models | Deployment | |---|---|---|---|---|---| | [Kodus](https://github.com/kodustech/kodus-ai) | AGPL-3.0 (dual: `ee` files commercial) | ~1.3K | GitHub, GitLab, Bitbucket, Azure Repos | Any: Claude, GPT, Gemini, Llama, self-hosted OpenAI-compatible | Docker Compose, VM, Kubernetes/Helm; also cloud | | [PR-Agent](https://github.com/The-PR-Agent/pr-agent) | MIT | ~12.5K | GitHub, GitLab, Bitbucket, Azure DevOps | OpenAI, Claude, and others via config | GitHub Action, CLI, self-hosted app | | [ai-review](https://github.com/Nikita-Filonov/ai-review) | Apache-2.0 | ~540 | GitHub, GitLab, Bitbucket (Cloud + Server), Azure DevOps, Gitea | OpenAI, Claude, Gemini, Ollama, Bedrock, OpenRouter, Azure OpenAI | CLI/CI; fully offline with Ollama | | [OpenReview](https://github.com/vercel-labs/openreview) | None published (see caveat) | ~1.5K | GitHub | Vercel AI SDK providers | Self-hosted Next.js app on Vercel | | [ai-codereviewer](https://github.com/freeedcom/ai-codereviewer) | MIT | ~1K | GitHub | OpenAI | GitHub Action | ### Kodus — the full platform, open Kodus is the most complete open-source AI code reviewer: not a script that pipes a diff to a model, but a review platform — context assembly, rule management, learning from review history — that happens to be AGPL. What sets it apart, all verifiable in the [repo](https://github.com/kodustech/kodus-ai) and [docs](https://docs.kodus.io): - **Self-hosting is the product, not a concession.** Docker Compose for a quick start, generic VM installs, Kubernetes and OpenShift via Helm. No seat minimums, no sales call. Self-hosted instances send one anonymous daily heartbeat (aggregated counters, no code or identifiers), and you can disable it with an environment variable — the kind of telemetry disclosure you only get from open source. - **BYOK, radically.** Claude, GPT, Gemini, Llama, GLM, Kimi, or any OpenAI-compatible endpoint — including models you host yourself, which is how you get a fully air-gapped review pipeline. Zero markup: you pay your provider at list price, and a token-usage dashboard shows exactly where spend goes. - **Rules as plain language, synced from what you already have.** Kody Rules are written in natural language and inherit global → repository → directory. Kodus auto-detects existing rule files — `.cursorrules`, `.cursor/rules/*.mdc`, `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, `.windsurfrules`, and more — so the standards your coding agents follow while writing code are the same ones enforced at review. That closes a loop most teams don't realize is open; it's the [rule-centric review standard](/standards/02-rule-centric) in practice. - **Context beyond the repo.** Linked repositories let the reviewer read sibling repos to catch cross-repo contract breaks — the kind of bug diff-scoped reviewers structurally cannot see. - **CLI + CI.** Reviews run locally, in pipelines, or on PRs. The honest caveats: it's dual-licensed, so files marked `ee` are commercial, not AGPL — check the [license](https://github.com/kodustech/kodus-ai/blob/main/license.md) if you plan to fork. Running it yourself means owning a deployment (Postgres, the orchestrator, model keys) that a SaaS would own for you. And the community is smaller than PR-Agent's star count suggests, though the company behind it ships actively. There's also a managed cloud if you want the open-source model without the ops: free Community tier on your own API key, Teams at $10/dev/month plus token costs (verified August 2026). ### PR-Agent — the original, now community-owned PR-Agent has the best origin story in the category, and 2026 rewrote its ending. Built by CodiumAI (later Qodo), it was the original open-source PR reviewer — `/review`, `/describe`, `/improve` commands on PRs, configurable models, self-hostable as a GitHub Action, CLI, or app across GitHub, GitLab, Bitbucket, and Azure DevOps. In 2026, Qodo transferred the project to a community-owned organization, [The-PR-Agent](https://github.com/The-PR-Agent/pr-agent), where it's MIT-licensed (verified August 2026) and community-maintained — the README now states plainly that it "is not the Qodo free tier." Qodo remains a sponsor, and its commercial, closed Qodo Merge product continues separately. For open-source users this is a good outcome: a permissive license, a maintainer community with ~12.5K stars behind it, and no ambiguity about where the open project ends and the paid one begins. Where it fits: PR-Agent is a tool, not a platform. You get solid per-PR review, description, and improvement commands with your own keys — but no rule management UI, no learning from review history, no cross-repo context, no dashboards. For a small team comfortable wiring a GitHub Action and tuning a TOML config, it's the fastest path to self-hosted AI review. For an org that needs enforced standards across 50 repos, it runs out of road. ### ai-review — the offline option [ai-review](https://github.com/Nikita-Filonov/ai-review) (Apache-2.0, ~540 stars, actively maintained as of August 2026) is a lighter tool with one killer feature: breadth of backends. It supports GitHub, GitLab, Bitbucket Cloud and Server, Azure DevOps, and Gitea on the git side, and OpenAI, Claude, Gemini, Bedrock, OpenRouter, Azure OpenAI, and Ollama on the model side. The Ollama support means reviews can run entirely inside your network with a local model — no tokens leave the building, full stop. If your constraint is a hard air-gap and your expectations are per-PR review rather than a platform, this is a pragmatic pick. ### OpenReview — promising, but read the fine print Vercel Labs' [OpenReview](https://github.com/vercel-labs/openreview) (~1.5K stars) is a self-hosted AI code review bot you deploy as a Next.js app — unsurprisingly polished for a Vercel project, and a nice architecture if you're already in that ecosystem. Two caveats, both verified August 2026: the repo ships no license file, so despite the "open-source" description it currently grants you no formal rights — and activity has been quiet since March 2026. Watch it, star it, but don't build your review pipeline on it until the license lands. ### ai-codereviewer — the minimal GitHub Action [freeedcom/ai-codereviewer](https://github.com/freeedcom/ai-codereviewer) (MIT, ~1K stars) is the "smallest thing that works": a GitHub Action that sends your PR diff to OpenAI and posts comments. It's a fine weekend install for a side project and a useful reference implementation for understanding how these tools work. It is not a team review process — no rules, no context beyond the diff, one model vendor. Worth knowing it exists; worth being honest about what it is. ### Worth a mention: the non-AI plumbing [reviewdog](https://github.com/reviewdog/reviewdog) and [Danger](https://danger.systems/) predate the LLM wave — they post linter output and enforce PR conventions rather than reason about code. They pair well underneath an AI reviewer (deterministic checks stay deterministic), and if you're deciding how to split responsibilities between the two layers, that's exactly the topic of [AI code review vs static analysis](/blog/ai-code-review-vs-static-analysis). ## "Self-hosted enterprise plan" is not open source This distinction gets blurred constantly, so let's be precise. CodeRabbit, Greptile, Sourcery, and DeepSource all offer self-hosted deployment — on custom-priced enterprise plans. Qodo goes further with air-gapped options, and DeepSource's enterprise tier even allows BYOK. Those are real options for regulated companies, and for some teams they're the right call. But self-hosting a closed binary gives you data locality, not transparency. You still can't read the context pipeline, audit the prompts, patch a bug yourself, or keep running the current version if the vendor changes terms. You also can't try before the sales call — every one of those self-hosted options is gated behind "contact us." The open-source difference is that `docker compose up` is the trial. We keep a fuller comparison of the closed tools in our [CodeRabbit alternatives](/blog/coderabbit-alternatives) breakdown and the [best AI code review tools](/blog/best-ai-code-review-tools) roundup. Where closed SaaS honestly wins: polish and ops. CodeRabbit's onboarding is smoother than any self-hosted install; hosted tools own uptime, scaling, and model-vendor churn for you; and per-seat billing is easier to get through procurement than "platform fee plus metered tokens." If nobody on your team wants to own a deployment, that's a legitimate reason to pay for closed SaaS — pick it with eyes open, not because a vendor's "open" marketing blurred the line. ## The cost math: BYOK vs per-seat Concrete numbers for a 30-developer team, using prices verified in August 2026: - **CodeRabbit Pro:** $24/user/month → $720/month ($1,440 on Pro Plus), model costs bundled and invisible. - **Greptile Pro:** $30/seat/month → $900/month, plus $1 per review beyond included credits. - **Kodus self-hosted (Community):** $0 platform + your tokens. Kodus's own published estimates for a 30-dev team: roughly $570/month on Claude Sonnet 4.5 down to about $345/month on Gemini Flash — visible, tunable line items. - **Kodus cloud (Teams):** $10/dev → $300/month + the same token costs, still landing near or below the closed per-seat tools with model choice included. - **PR-Agent / ai-review self-hosted:** $0 platform + tokens; on a cheap model, plausibly the cheapest functional setup, minus the platform features. The structural point matters more than any single number: under BYOK, your two cost levers — which model, how much context — are in your hands, and dropping to a cheaper model for routine PRs is a config change. Under per-seat SaaS, the lever belongs to the vendor. Neither is automatically cheaper at every scale, but only one of them lets you do the arithmetic yourself. ## What self-hosting actually involves The part open-source advocates undersell: someone on your team now owns a service. Be clear-eyed about what that means before you commit. **The install is the easy part.** Kodus comes up with Docker Compose in an afternoon; PR-Agent is a GitHub Action plus a config file; ai-review is a CLI in your pipeline. If the tool can't demonstrate value in the first week on real PRs, the problem isn't your ops — it's the tool. **The steady state is small but nonzero.** Expect to own upgrades (monthly-ish for active projects), model-key rotation and spend monitoring, and the database if the tool keeps state — Kodus persists rules and review history, which is exactly what makes it more useful over time and what makes it a real service rather than a stateless script. Budget a few hours a month, not a headcount. **Security posture flips in your favor.** With self-hosting, webhook traffic from your git provider terminates inside your network, model calls go to providers you already have data agreements with — or never leave at all if you run local models — and there's no third-party retention policy to diligence. For most teams that's the entire reason to be here. **Quality tuning is on you, and that's a feature.** Closed SaaS tunes noise thresholds globally for their average customer. Self-hosting an open tool means you set the bar: which rules block, which merely comment, how aggressive the reviewer is on legacy directories. The best practice we've seen is treating reviewer output like production alerts — track the dismissed-comment rate weekly and prune whatever your engineers ignore, the same discipline behind the [sandbox validation standard](/standards/06-sandbox-validation). An open tool lets you enforce that discipline in config rather than in a feature request to a vendor. ## How to choose - **You want a real review platform — rules, context, metrics — with open-source control:** Kodus. Self-host it free under AGPL, or take the cloud tier and keep BYOK. - **You want a lightweight, permissively-licensed tool you fully wire yourself:** PR-Agent. - **You have a hard air-gap requirement and modest expectations:** ai-review with Ollama, or Kodus pointed at a self-hosted model for the platform version of the same idea. - **You're experimenting on a side project:** ai-codereviewer, ten minutes, done. - **Nobody will own a deployment and budget is available:** be honest with yourself and evaluate the closed SaaS tools — our [evaluation guide](/blog/how-to-evaluate-ai-code-review-tools) and the [assessment](/assessment) will tell you what to test. Whichever way you go, apply the same two-week test: run it on real PRs, count the comments your engineers acted on versus dismissed, and check the license file — not the README — before you commit. If the platform-with-control option is what you're after, [Kodus](https://kodus.io) is open source for exactly that reason: read the code, run it on your infra, bring your own models, and pay no markup on tokens. ## FAQ ### What is the best open source AI code review tool? Kodus is the most complete open-source option as of August 2026: AGPL-3.0 core, self-hosted via Docker or Helm, bring-your-own-key model support, and plain-language rules that sync from files like .cursorrules and CLAUDE.md. PR-Agent (MIT, community-maintained) is the best lightweight alternative if you want a simpler tool you wire up yourself. ### Is PR-Agent still open source after Qodo? Yes. In 2026 Qodo transferred PR-Agent to a community-owned GitHub organization (The-PR-Agent), and the project is MIT-licensed as of August 2026. It is now community-maintained and explicitly separate from Qodo's commercial Qodo Merge product, though Qodo sponsors the project. ### Is CodeRabbit open source? No. CodeRabbit is closed-source SaaS; it offers self-hosting only on its custom-priced Enterprise plan, and self-hosting a closed binary is not the same as open source. You cannot read the code, audit the prompts, or run it without a commercial agreement. ### Can I run AI code review fully offline or air-gapped? Yes, with the right stack. Kodus self-hosted pointed at a self-hosted OpenAI-compatible model keeps everything inside your network, and the lightweight ai-review project supports Ollama so reviews never leave your infrastructure. Among closed vendors, only enterprise plans (Qodo, DeepSource) offer air-gapped deployments. ### What does BYOK mean for AI code review costs? Bring-your-own-key means the tool calls the LLM with your API credentials, so you pay the model provider directly at list price instead of paying a vendor's marked-up bundle. It also gives you model choice and a clean data path — your code goes to a provider you already have a data agreement with. Kodus publishes token estimates of roughly $345-570/month for a 30-developer team, depending on model. ### Is AGPL a problem for commercial use? Using an AGPL tool internally — running Kodus to review your private code — does not obligate you to open-source anything. AGPL obligations trigger when you modify the software and offer it to others as a network service. If you wanted to resell a hosted version, you'd need the commercial license; for the common case of an internal review bot, AGPL is a non-issue. ### Do open source AI code review tools match commercial ones on quality? The gap has mostly closed for the serious projects. Review quality is driven by the model (which you choose under BYOK) and by how much context the tool feeds it — and Kodus's cross-repo context matches or beats most closed tools. Where closed SaaS still leads is polish: onboarding, dashboards, and support. Small wrapper scripts, though, remain far behind dedicated tools. # Self-Hosted AI Code Review: Options & Trade-Offs (2026) > Self-hosted AI code review explained: full-stack vs BYOK vs on-prem runners, verified vendor options, and what deployment really costs in 2026. Self-hosted AI code review means running the review system — the service that reads your pull requests, builds context, calls a model, and posts comments — on infrastructure you control, so your source code never leaves your network. In practice, vendors use "self-hosted" to describe three very different things: full-stack self-hosting (the whole application in your infra, as with Kodus or PR-Agent), BYOK (vendor cloud app, your model keys), and on-prem runners (your compute executes jobs for a vendor's cloud control plane). Which one you need depends on whether your driver is compliance, IP protection, data residency, or cost — and conflating the three levels is the most common way teams end up buying the wrong thing. This guide defines the levels precisely, lists the real options as of August 2026 with what each vendor actually offers, and walks through the deployment decisions — models, GPUs, secrets — that determine what self-hosting really costs. ## Why teams self-host AI code review Nobody self-hosts for fun. The teams that need this have one of four concrete drivers. **Compliance and regulation.** If you operate under HIPAA, PCI DSS, SOC 2 with strict data-handling commitments, or government security frameworks, "we send source code to a third-party SaaS which forwards it to an LLM provider" can be somewhere between a hard conversation and a non-starter. Banks, healthcare companies, and defense contractors routinely require that code — which often embeds schema details, credentials-adjacent config, and security logic — stays inside audited boundaries. Some environments are fully air-gapped, which rules out every cloud service categorically. **Intellectual property.** For some companies, the codebase is the company. Trading firms, chip designers, and anyone with genuinely novel algorithms treat source code as a trade secret, and their security posture forbids transmitting it to third parties regardless of contractual promises. Vendor DPAs and "we don't train on your data" commitments help, but a contract is a legal control, not a technical one. Self-hosting converts the promise into an architecture. **Data residency.** GDPR-driven residency requirements, sector rules in markets like Germany and Brazil, and customer contracts that mandate "data stays in-region" all extend to source code and the metadata around it (commit messages, ticket contents, reviewer identities). A US-hosted review SaaS calling a US-hosted LLM can violate commitments you've made to your own customers, even if the vendor behaves perfectly. **Cost control at scale.** This one is underrated. Per-seat SaaS pricing for AI review typically runs tens of dollars per developer per month, while the underlying inference for a typical PR costs a fraction of that. Self-hosting with your own model keys means you pay the provider's base token price and nothing on top — the argument our [economic transparency standard](/standards/07-economic-transparency) makes in detail. At 200 engineers, the delta funds a platform engineer. If none of these four apply to you, a well-run cloud tool with a strong data policy is probably less total effort. But if one applies, it usually applies absolutely — which is why the next distinction matters so much. ## What "self-hosted" really means: three levels Vendors use one term for three architectures. The question that separates them: **where does your source code go, and who operates the software that processes it?** ### Level 1: Full-stack self-hosting The entire application — webhook receivers, context engine, orchestration, database, dashboard — runs in your infrastructure. You deploy it (typically Docker Compose or Kubernetes), you upgrade it, you control every byte of egress. If you also serve the model locally (vLLM, Ollama) or through an endpoint inside your cloud tenancy (AWS Bedrock, Azure OpenAI, Vertex AI), code never crosses your boundary at all. This is the only level that satisfies air-gapped and strict-residency requirements, and it's the level open-source tools naturally provide. The cost: you are now operating a distributed system. Someone owns upgrades, monitoring, database backups, and the repo index. ### Level 2: BYOK (bring your own key) The vendor's cloud application still receives and processes your code, but LLM inference runs against your API keys — direct provider keys, or endpoints inside your tenancy like Azure OpenAI. BYOK gives you cost transparency (you see every token at base price), model choice, and sometimes inference-side residency. What it does not give you: your code still transits and is processed by the vendor's cloud. BYOK is the right level when your driver is cost and model control rather than data boundary. It is genuinely valuable — and it is genuinely not self-hosting, no matter what the pricing page implies. ### Level 3: On-prem runners and hybrid architectures Your compute executes review jobs, but a vendor cloud control plane orchestrates them. GitHub Copilot code review is the clearest example: since its March 2026 move to an agentic architecture, it can execute validation steps on self-hosted Actions runners (ARC-managed, Ubuntu x64 only, per GitHub's docs) — but the review service itself remains GitHub's cloud. Some vendors offer variations, like CodeRabbit's reverse-tunnel option for reaching private networks without inbound access. Hybrid setups solve network reachability and compute placement; they do not keep your code out of the vendor's cloud. ### What actually leaves your network | Level | Code leaves your network? | Inference under your control? | Ops burden | Satisfies air-gap? | |---|---|---|---|---| | Full-stack self-hosted | No (with local or in-tenancy models) | Yes | High | Yes | | BYOK on vendor SaaS | Yes — vendor app processes it | Partially (your keys, your endpoints) | Low | No | | On-prem runners / hybrid | Yes — vendor control plane orchestrates | Sometimes | Medium | No | When a vendor says "self-hosted," ask which row they mean. It's a one-question filter that eliminates most ambiguity — and most disappointment. ## The honest options list (as of August 2026) What each vendor verifiably offers. Deployment offerings change; treat vendor docs as the source of truth and this as your shortlist. ### Kodus — open source, AGPLv3, full-stack [Kodus](https://kodus.io) is an open-source AI code review platform licensed under AGPLv3 (with a separate enterprise license covering some EE features — the repo carries both license files). The [self-hosting guide](https://docs.kodus.io/how_to_deploy/en/deploy_kodus/generic_vm) covers deployment on your own VM with Docker Compose; the stack is a NestJS API, background workers, a webhook service, and a Next.js dashboard, integrating with GitHub, GitLab, Bitbucket, and Azure Repos. BYOK is native: as of August 2026, the project supports OpenAI, Anthropic, Google Gemini, Vertex AI, Novita, and any OpenAI-compatible endpoint — which is the escape hatch that makes fully local serving via vLLM or Ollama work. You pay model providers directly, with no markup. Team conventions are enforced through Kody Rules, plain-language review rules scoped to organizations, repos, or paths. Disclosure: Kodus sponsors this site — evaluate it with the same rigor you'd apply to anything else. ### PR-Agent — open source, MIT, maximum flexibility [PR-Agent](https://github.com/qodo-ai/pr-agent) is MIT-licensed as of August 2026 and describes itself as a community-maintained open-source project (the legacy of what became Qodo's commercial platform). It runs as a CLI, a Docker container, a GitHub Action, or a persistent webhook server, against GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea. Model support goes through LiteLLM, which means effectively everything: OpenAI, Claude, Gemini, Mistral, DeepSeek, Azure OpenAI, Bedrock, Vertex, OpenRouter, and local Ollama. It's a toolkit more than a platform — commands like review, improve, and describe that you wire into your workflow — so expect to build your own conventions around it rather than configure them in a dashboard. For a deeper look at this category, see our guide to [open-source AI code review tools](/blog/open-source-ai-code-review-tools). ### GitLab Duo Code Review — self-managed with self-hosted models If you're already on self-managed GitLab, Duo Code Review with self-hosted models is a serious option: it reached general availability in GitLab 18.4 (2026), supporting Mistral, Meta Llama, Anthropic Claude, and OpenAI GPT model families served via vLLM, Azure OpenAI, or AWS Bedrock, per GitLab's documentation. GitLab positions Duo Self-Hosted explicitly at air-gapped and regulated environments, with request and response logs staying in your domain, and GitLab 19.0 broadened the supported open-model list further. The catches: it requires GitLab Duo add-on licensing (check current packaging), and it reviews merge requests on GitLab — it is not an option for GitHub or Bitbucket shops. ### Enterprise tiers of commercial tools Several closed-source vendors offer self-hosted deployment at the top of their pricing ladder: - **CodeRabbit** offers self-hosted deployment for Enterprise customers — as of August 2026 its docs state the option is available to organizations with 500+ seats, runs the review agent inside your infrastructure, and connects to your own LLM provider, with configuration delivered during onboarding ([CodeRabbit self-hosted docs](https://docs.coderabbit.ai/self-hosted/overview)). Below that threshold, you're on their cloud — one reason smaller regulated teams end up surveying [CodeRabbit alternatives](/blog/coderabbit-alternatives). - **Qodo** (the platform that grew out of Qodo Merge) offers single-tenant SaaS, on-premises, and air-gapped deployment options on its Enterprise plan, at custom pricing, per its documentation as of August 2026. - **Greptile** advertises self-hosted deployment for enterprise customers with strict data-privacy requirements, alongside SOC 2 Type II and SSO/SAML, per its enterprise page as of August 2026; details and pricing are custom, so confirm scope directly. - **Bito** supports self-managed Git platforms (GitHub Enterprise, GitLab self-managed, Bitbucket Data Center) and advertises BYOK options; verify the current deployment model for the agent itself with their team. The pattern across all four: self-hosting exists, but behind a sales conversation, at custom or high-minimum pricing, and you operate a black box — you can run the software, but you can't read it, and your ability to keep running it is tied to the contract. ### What you can't self-host **GitHub Copilot code review** has no self-hosted version as of August 2026 — self-hosted runners execute its agentic checks, but the review service is GitHub's cloud. If your constraint is "code never reaches a third-party cloud," Copilot code review is out, full stop. The same logic applies to any reviewer that offers only Level 2 or Level 3 deployment: check the vendor's architecture docs, not the marketing page. Our comparison of the [best AI code review tools](/blog/best-ai-code-review-tools) flags deployment models alongside capability. ### Summary table | Tool | License / tier gate | Deployment model | Model options | |---|---|---|---| | Kodus | AGPLv3 open source (plus EE tier) | Full stack, Docker Compose on your infra | BYOK: OpenAI, Anthropic, Gemini, Vertex, any OpenAI-compatible endpoint (vLLM, Ollama) | | PR-Agent | MIT open source | CLI, Action, Docker, webhook server | Anything via LiteLLM, incl. Bedrock, Azure OpenAI, Ollama | | GitLab Duo Code Review | Duo licensing, self-managed GitLab | Inside your GitLab deployment | Mistral, Llama, Claude, GPT via vLLM / Azure OpenAI / Bedrock | | CodeRabbit | Enterprise, 500+ seats | Agent in your infra, vendor-guided | Your LLM provider account | | Qodo | Enterprise, custom pricing | Single-tenant, on-prem, or air-gapped | Incl. self-hosted model options | | Greptile | Enterprise, custom pricing | Self-hosted for enterprise | Confirm with vendor | | GitHub Copilot code review | — | Cloud only (self-hosted runners execute checks) | GitHub-managed | ## Deployment considerations Choosing a tool is half the decision. The other half is the infrastructure underneath it. ### Models: three routes, one real trade-off Your model routing decision matters more than your tool decision for both quality and compliance. **Direct provider APIs** (OpenAI, Anthropic, Google) give you the strongest review quality — code review is a reasoning-heavy task, and frontier models still catch logic and architecture issues that smaller models miss. Code goes to the provider under their API data terms, which most providers pair with no-training commitments on API traffic; whether that satisfies your compliance bar is a question for your counsel, not your vendor. **In-tenancy cloud endpoints** — AWS Bedrock, Azure OpenAI, Google Vertex AI — are the pragmatic middle. You get frontier or near-frontier models served inside your cloud account and region, which satisfies most data-residency and many compliance requirements, with zero GPUs to own. For most regulated teams below "air-gapped," this is the right answer, and it's why BYOK support for these endpoints should be a hard requirement on your tool shortlist. **Fully local serving** — vLLM or Ollama running open-weight models (Llama, Qwen, DeepSeek, Mistral families) — is the only route for air-gapped environments. Be honest about the quality trade: open models have closed much of the gap, but review depth on subtle, cross-file logic issues still correlates with model strength. Whatever you deploy, test it with planted bugs before trusting it — the trial protocol in our guide on [how to evaluate AI code review tools](/blog/how-to-evaluate-ai-code-review-tools) works identically for a local model behind a self-hosted tool. ### GPU vs. API economics The math is less about unit prices (which change quarterly — verify current cloud pricing) than about utilization shape. Code review is bursty: PRs cluster around working hours and release cycles. API billing fits that shape perfectly — you pay per token, and a typical PR review lands in the cents-to-low-dollars range depending on diff size, context depth, and model choice. A 200-PR-per-month team on BYOK usually spends less on inference than one SaaS seat costs. Dedicated GPUs invert the shape. Serving a 70B-class model well means one or more 80GB-class GPUs (quantization reduces the footprint at some quality cost), running around the clock whether PRs are flowing or not, plus the serving stack and the person who owns it. That only pays off in two cases: review volume high and steady enough to keep utilization up, or a compliance mandate that removes the API option entirely. If you're buying GPUs to save money on code review alone, re-run the spreadsheet; if you're buying them because the code cannot leave, the spreadsheet was never the point. One under-appreciated cost either way: context. A reviewer that meets the [multi-dimensional context standard](/standards/01-multi-dimensional-context) indexes your repositories and feeds cross-file context into every review — that's more tokens per PR than diff-only tools burn, and it's exactly the spend that makes reviews worth reading. Budget for it rather than optimizing it away. ### Secrets and the security boundary Ironically, the tool you deploy for security reasons is itself a high-value target: it holds credentials that can read every repository. Treat it accordingly. - **Git tokens:** scope to the minimum (read code, write PR comments, read webhooks) and prefer short-lived app installations over long-lived PATs. Rotate on a schedule. - **LLM keys:** store in a real secret manager (Vault, AWS Secrets Manager, sealed secrets), never in compose files or env-committed config. Set provider-side spend alerts — a runaway review loop is a real failure mode. - **Webhook endpoints:** verify signatures on every event; an unauthenticated webhook receiver that triggers LLM calls is both an injection surface and a wallet drain. - **Egress control:** the point of Level 1 is a small, auditable egress list. Enforce it at the network layer — allowlist your model endpoint and Git platform, and alert on anything else. This is also how you verify a vendor's claims about their own agent. - **Data at rest:** review context, embeddings, and logs contain source code. Encrypt the database, apply your retention policy, and include the deployment in your existing backup and audit scope. ### The operational reality A self-hosted reviewer is a production service: webhook ingestion, queues, workers, a database, a repo index that must stay fresh as the codebase moves. Budget a real fraction of an engineer — heavier at setup, lighter in steady state — for upgrades, monitoring, and the occasional index rebuild. Open-source tools make this tractable (you can read the code when something breaks, and Docker Compose setups keep the surface small), but "self-hosted" is never "no-ops." If your team can't own another service, in-tenancy BYOK on a managed tool may be the honest compromise. ## How to choose Work backwards from your constraint. Air-gapped or "code never leaves the network": you need Level 1 plus local models — realistically Kodus, PR-Agent, GitLab Duo Self-Hosted, or an enterprise on-prem contract with Qodo. Residency and auditability, but cloud inference acceptable: Level 1 with in-tenancy endpoints (Bedrock, Azure OpenAI, Vertex), which the open-source tools support today without a sales call. Cost and model control only: BYOK may be all you need — just stop calling it self-hosting in your security review. Then evaluate the shortlist like an engineering decision, not a procurement one: deployment model is one axis, but review quality, noise discipline, and learning behavior decide whether the thing gets used after month one. Our [assessment](/assessment) scores any tool — including a self-hosted deployment you're already running — against the nine standards in about ten minutes, and tells you which gaps are architectural and which are just configuration. ## FAQ ### What does self-hosted AI code review actually mean? It means the software that reads your pull requests and produces review comments runs on infrastructure you control — your VMs, your Kubernetes cluster, your VPC. In the strictest form, the LLM itself also runs in your infrastructure, so no code ever crosses your network boundary. ### Is BYOK the same as self-hosting? No. Bring-your-own-key means LLM inference is billed to your API account and can be routed through your Azure OpenAI or AWS Bedrock tenancy, but the vendor's cloud application still receives and processes your code. BYOK solves cost transparency and model choice; it does not, by itself, keep code inside your network. ### Can I run AI code review fully offline or air-gapped? Yes, but only with tools that support both self-hosted deployment and locally served models. Open-source reviewers pointed at a vLLM or Ollama endpoint can run with zero external egress, and GitLab Duo Self-Hosted and Qodo's enterprise tier both advertise air-gapped deployment options as of August 2026. ### Does AGPLv3 licensing create problems for internal self-hosting? For ordinary internal use — running the tool for your own team's code review — AGPLv3 obligations are generally not triggered by simply using the software; they mainly concern offering modified versions to others as a network service. Most companies self-hosting an AGPL tool internally are fine, but this is not legal advice: run it past your counsel. ### What hardware do I need to run review models locally? Code review benefits from strong reasoning models, and the local models that review well are large. Serving a 70B-class model typically means one or more 80GB-class GPUs (fewer with quantization, at some quality cost), plus vLLM or a similar serving stack. Many teams instead use models hosted inside their cloud tenancy via AWS Bedrock, Azure OpenAI, or Vertex AI, which satisfies most residency requirements without owning GPUs. ### Is self-hosting cheaper than paying per seat? Often, but not automatically. BYOK API billing usually lands in the cents-to-low-dollars per PR range depending on diff size and model, which undercuts per-seat pricing for most teams. Dedicated GPUs are the expensive path: they cost the same whether or not PRs are flowing, so they only pay off at high, steady review volume or when compliance mandates them. ### Does GitHub Copilot code review have a self-hosted version? No. As of August 2026, Copilot code review is a GitHub cloud service. It can execute its agentic validation steps on self-hosted Actions runners (ARC on Ubuntu x64), but that is compute placement, not a self-hosted review service — your code is still processed by GitHub's cloud. # What Is AI Code Review? How It Works (2026) > AI code review explained: how LLM reviewers work, what they catch and miss, how they differ from linters and static analysis, plus sourced adoption data. AI code review is the use of large language models (LLMs) to automatically review code changes — usually pull requests — for bugs, security issues, logic errors, and violations of team standards. Unlike linters or static analyzers, which match code against predefined rules, an AI code reviewer reads the diff plus surrounding codebase context, reasons about what the change is trying to do, and posts line-level comments the way a human reviewer would. As of August 2026, this has moved from novelty to default: Google's [DORA research](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) reports that roughly 90% of technology professionals now use AI at work, and code review is one of the first workflows teams automate. This post is a precise, source-backed explainer: what AI code review actually is, how the pipeline works, what it reliably catches, where it fails, and how it differs from the tools it is often confused with. ## The definition, precisely A working definition with the parts that matter: - **Input:** a code change (a diff or pull request), plus context — the surrounding files, dependency graph, past PRs, style guides, and team-defined rules. - **Engine:** one or more large language models, usually orchestrated by an agent pipeline that decides what context to fetch and which checks to run. - **Output:** review comments (ideally line-anchored), severity labels, suggested fixes, and sometimes PR summaries or walkthroughs. - **Trigger:** automatic, on every push or PR open, before or alongside human review. Two things are *not* AI code review, even though they get bundled into the phrase. Code *generation* assistants (Copilot-style autocomplete, coding agents) write code; a reviewer's job is adversarial — it exists to find what's wrong with code, including AI-written code. And rule-based static analysis is not AI review either, even when marketed with an AI label: if the tool can only flag patterns a human encoded in advance, it's a scanner, not a reviewer. The distinction matters more each quarter because the volume of code needing review is exploding. Google said in October 2024 that [more than 25% of its new code was AI-generated](https://thehill.com/policy/technology/4962336-google-ceo-says-more-than-25-percent-of-companys-new-code-written-by-ai/); Microsoft's CEO put its figure at [20-30% by April 2025](https://www.entrepreneur.com/business-news/ai-is-taking-over-coding-at-microsoft-google-and-meta/490896); Anthropic's CFO said [over 90% of its code is now written by Claude](https://www.techspot.com/news/112408-anthropic-more-than-90-code-now-written-ai.html). Review capacity did not triple to match. That gap is the reason this category exists. ## How AI code review works: LLM + context + rules Every serious tool in the category — [CodeRabbit, Greptile, Kodus, Cursor Bugbot, Copilot code review and others](/blog/best-ai-code-review-tools) — is some arrangement of the same five-stage pipeline. The differences between tools are mostly differences in stages 2 and 4. ### 1. Diff ingestion The tool receives a webhook when a PR opens or updates, pulls the diff, and normalizes it: splitting by file, filtering generated code and lockfiles, and chunking large changes. Diff size matters here for the same reason it matters to humans — the classic [SmartBear study of code review at Cisco](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/) found defect discovery degrades sharply past 400 lines per review, and LLMs show an analogous degradation as context fills with noise. ### 2. Context assembly This is the stage that separates toy reviewers from useful ones. The diff alone rarely contains enough information to judge correctness: the function being modified has callers, the type being changed has consumers, the config being touched has an environment it deploys to. Strong tools build a retrieval layer over the repository — symbol graphs, embeddings, or agentic file exploration — and pull in whatever the model needs to reason about the change. Some go further and ingest linked tickets, past review comments, and architectural docs. We cover why single-dimension context fails in [multi-dimensional context](/standards/01-multi-dimensional-context). The evidence says context is the binding constraint, not model quality: in [Qodo's 2025 State of AI Code Quality survey](https://www.qodo.ai/reports/state-of-ai-code-quality/) of 609 developers, 65% said AI misses relevant context during critical tasks like reviewing code and refactoring — the single most-cited failure mode. ### 3. Rules and team standards Raw LLM opinions about code are generic. Useful review is opinionated in *your* codebase's terms: this service must not call the database directly, public APIs need docstrings, money is always integer cents. Tools encode this as natural-language rule files, learned conventions extracted from past reviews, or configurable severity policies. This layer is also how teams suppress entire categories of comment (style nits already covered by the linter) so the AI's budget of attention goes to what only it can do. ### 4. Generation and filtering The model (or several, in ensemble) drafts candidate findings. Then — critically — a filtering stage discards most of them. Deduplication, severity thresholds, confidence scoring, self-review passes ("is this comment actually actionable?"), and in the most rigorous designs, [sandbox execution to verify the claimed bug is real](/standards/06-sandbox-validation) before it ever reaches a human. Google's static-analysis team established the benchmark discipline here years before LLMs: their [Tricorder platform enforced a rule that review-time checks stay under a 10% effective false-positive rate](https://cacm.acm.org/research/lessons-from-building-static-analysis-tools-at-google/), because developers stop reading warnings from tools that waste their time. The same economics govern AI reviewers, only sharper — an LLM can generate plausible-sounding nonsense at scale. ### 5. Delivery Findings post back to the PR as line comments, ideally with committable suggested fixes. Placement in the workflow is part of the design: pre-human (AI clears the mechanical layer first), parallel (AI and human review simultaneously), or gate (AI review required to pass before merge). ## What AI code review catches The honest pitch for LLM-based review is that it covers the categories rule-based tools structurally cannot: - **Logic errors.** Inverted conditionals, off-by-one boundaries, wrong operator in a business calculation — bugs that are syntactically valid and type-correct, invisible to compilers and linters. - **Cross-file inconsistencies.** A signature changed in one file while a caller three directories away still passes the old arguments; an enum extended without updating the exhaustive switch that consumes it. - **Broken invariants and missing edge cases.** Null paths, empty collections, timezone handling, concurrent access to shared state. The [2025 Stack Overflow survey](https://survey.stackoverflow.co/2025/ai/) found 66% of developers name "solutions that are almost right, but not quite" as their top AI frustration — and these near-miss bugs are exactly the class a context-aware reviewer is positioned to catch in AI-written code. - **Intent mismatches.** The PR description says "add retry with backoff," the code retries in a tight loop. Judging code against stated intent requires reading both — no AST rule can do it. This extends to [business logic validation](/standards/04-business-logic): whether the discount calculation matches what the ticket actually asked for. - **Security issues with semantic shape.** Authorization checks missing on one of five similar endpoints, secrets in a new config path, injection via a string that only becomes a query four calls later. A concrete example makes the mechanism clear. A PR renames a config key from `timeout` to `timeout_ms` and updates the three call sites in the service. A linter passes: every file is syntactically clean. Static analysis passes: no rule exists about this key. But a deployment manifest in a sibling directory still sets `timeout`, which the new code silently ignores, falling back to a default that is 30x shorter. A context-aware reviewer that indexes the whole repository — not just the diff — flags the stale reference and the changed effective behavior. That is the category's core move: the bug lives in the *relationship* between the change and everything it touches, and only a reader of both can see it. There is also real-world evidence the category delivers beyond anecdotes: in Qodo's survey, [81% of developers using AI code review reported code-quality improvements, versus 55% of fast-moving teams without it](https://www.qodo.ai/reports/state-of-ai-code-quality/). And an [ICSE 2025 industrial study](https://arxiv.org/abs/2412.18531) of an LLM reviewer deployed across 4,335 pull requests found 73.8% of its automated comments were resolved by developers — most of the machine's feedback was acted on, not dismissed. ## What it misses — and gets wrong Anyone selling AI review without this section is selling. Known failure modes, with sources: - **Non-determinism.** Run the same reviewer on the same diff twice and you may get different findings. This is inherent to sampling-based generation and is the core trade against static analysis — covered in depth in our [AI code review vs static analysis comparison](/blog/ai-code-review-vs-static-analysis). - **Hallucinated findings.** The model can assert a bug that does not exist, citing behavior the code does not have. The mitigation is validation before delivery, but not all tools validate. That same [ICSE 2025 study](https://arxiv.org/abs/2412.18531) recorded faulty reviews, unnecessary corrections, and irrelevant comments as the main drawbacks practitioners reported. - **No proof of absence.** Static analysis can guarantee "this codebase contains zero uses of `eval`." An LLM can never guarantee absence of anything; it saw what it saw. - **Security depth is inconsistent.** On the [OpenSSF CVE Benchmark](https://github.com/ossf-cve-benchmark/ossf-cve-benchmark) — real historical CVEs, not synthetic tests — [one vendor-run 2026 evaluation](https://deepsource.com/benchmarks) measured F1 scores ranging from above 80% down to the mid-30s across popular AI review tools. The spread is the finding: the label "AI code review" tells you nothing about security coverage. - **Review latency and noise are real costs.** In the ICSE study above, average PR closure time *increased* from 5 hours 52 minutes to 8 hours 20 minutes after the AI reviewer was introduced — more comments means more to resolve. A tool that cannot filter itself moves the bottleneck rather than removing it, which is why [measuring actual ROI](/standards/09-measurable-roi) beats trusting vendor dashboards. - **It does not replace what humans actually do in review.** Microsoft's foundational research on code review found that [fewer than 15% of review comments relate to actual defects](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/) — the bulk of the value is knowledge transfer, shared ownership, and design discussion. AI review automates defect-finding; it does not make your team collectively understand the codebase. ## AI code review vs linters, static analysis, and human review The four layers are complements, not substitutes. The confusion between them is common enough to deserve a table: | Dimension | Linter | Static analysis / SAST | AI code review | Human review | |---|---|---|---|---| | How it decides | Syntax/style rules | Formal analysis (AST, dataflow, taint) | LLM reasoning over diff + context | Judgment and domain knowledge | | Deterministic | Yes | Yes | No | No | | Catches logic/intent bugs | No | Rarely | Yes, probabilistically | Yes | | Can prove absence of a pattern | Yes | Yes | No | No | | Cross-file, cross-repo reasoning | No | Limited (within analysis scope) | Yes, if context layer is good | Yes, if reviewer knows the code | | Novel bug classes (no rule exists) | No | No | Yes | Yes | | Cost per review | Negligible | CI compute | LLM inference (per PR/seat) | The most expensive engineering hour you have | | Speed | Seconds | Minutes | 1-5 minutes | Hours to days | | Feedback style | Pass/fail | Findings list | Conversational, line-anchored, with fixes | Conversational | The practical takeaway: linters enforce style for free, static analysis proves the provable, AI review covers the semantic middle ground at machine speed, and humans arbitrate architecture and intent. Teams that treat AI review as a SAST replacement get burned on security guarantees; teams that treat it as optional get buried in unreviewed AI-generated code. ## Adoption: the numbers behind the shift The adoption story, from primary sources, as of August 2026: - **AI is in nearly every workflow.** [90% of technology professionals use AI at work](https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/), up 14 points year over year, with a median of two hours per day spent working with it (DORA 2025, roughly 5,000 respondents). Stack Overflow's 2025 survey of 49,000+ developers puts [AI tool usage at 84%, up from 76% in 2024](https://survey.stackoverflow.co/2025/ai/). - **The trust gap is the striking part.** In the same Stack Overflow survey, [46% of developers actively distrust AI output accuracy](https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/) — up from 31% a year earlier — and only 3% report high trust. DORA 2025 similarly found [30% of respondents have little or no trust in AI-generated code](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report). Developers use AI heavily *and* don't trust it — which is precisely the market condition that makes automated review a necessity rather than a luxury. - **AI code volume keeps compounding.** GitHub's [Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) counted nearly 1 billion commits pushed in a year (up 25%), nearly 80% of new developers using Copilot within their first week, and GitHub's own coding agent authoring over 1 million pull requests in five months. In startups the shift is total: [a quarter of Y Combinator's Winter 2025 batch had codebases that were roughly 95% AI-generated](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated). - **Quality pressure is measurable, not hypothetical.** [Veracode's 2025 GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/) found LLMs introduced security vulnerabilities in 45% of coding tasks across 100+ models. [GitClear's analysis of 623 million changed lines](https://www.gitclear.com/the_ai_code_quality_maintainability_gap) shows refactoring collapsing (moved code down from 21% of changes in 2022 to under 4% by mid-2026) while copy-paste climbs. And [DORA's 2024 report](https://dora.dev/research/2024/dora-report/) linked a 25% increase in AI adoption to a 7.2% *decrease* in delivery stability. - **The review-tool market scaled in response.** CodeRabbit reported [13 million PRs reviewed across 2 million repositories](https://www.businesswire.com/news/home/20250916401011/en/CodeRabbit-Raises-%2460M-Series-B-Following-Unprecedented-Growth-as-Vibe-Coding-Triggers-a-Need-for-New-Code-Quality-Standards) when it raised its Series B in September 2025, and every major platform — GitHub, GitLab, Cursor — now ships a native AI reviewer. For a deeper stats treatment with every number sourced, see our [AI code review statistics roundup](/blog/ai-code-review-statistics). ## How teams actually roll it out A pattern that shows up consistently in teams that keep their AI reviewer (rather than muting it after three weeks): 1. **Start in comment-only mode on a subset of repos.** No gates. Measure signal: what fraction of comments get resolved vs ignored? The ICSE study's 73.8% resolution rate is a reasonable bar for "worth keeping." 2. **Configure aggressively in week one.** Turn off everything the linter already covers. Encode the three or four rules your senior reviewers repeat most often. A reviewer that repeats your linter is pure noise. 3. **Route by severity.** Critical findings block; suggestions don't. Non-blocking noise trains developers to ignore the tool; blocking noise trains them to hate it. 4. **Measure the loop, not the vibes.** Track review turnaround, escaped-defect rate, and comment resolution before and after. [DORA 2025's](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) central finding was that AI amplifies whatever process you already have — strong teams compound, struggling teams accelerate their dysfunction. If you want a structured way to score your own review process first, take the [assessment](/assessment). 5. **Keep humans on intent and architecture.** The division of labor that works: machine sweeps the semantic layer in minutes, human spends their attention on whether this is the right change at all. Choosing a tool is its own discipline — vendor benchmarks all disagree with each other, so [evaluate on your own bugs](/blog/how-to-evaluate-ai-code-review-tools), not on marketing pages. Open-source options (including [Kodus](https://kodus.io), which this site's maintainers build) let you self-host and inspect exactly what context the reviewer sees, which regulated teams increasingly require. ## Bottom line AI code review is LLM-powered, context-aware, automated review of code changes — a genuinely new layer in the quality stack, not a rebranded linter. It catches the semantic bug classes rules can't express, at a speed humans can't match, with a reliability neither rules nor humans would tolerate in themselves: probabilistic, occasionally wrong, and only as good as the context and filtering around the model. As of August 2026 the adoption question is settled — 90% of the industry works with AI daily and the code volume it produces has outrun human review capacity. The open question, and the one worth being rigorous about, is which tools convert model capability into trustworthy signal. That's an engineering evaluation, and it's yours to run. ## FAQ ### What is AI code review? AI code review is the use of large language models to automatically review code changes, usually pull requests, for bugs, security issues, and violations of team standards. Unlike linters that match predefined rules, an AI reviewer reads the diff plus surrounding codebase context and reasons about what the change actually does, then posts comments the way a human reviewer would. ### Is AI code review the same as static analysis? No. Static analysis parses code into a formal representation and checks it against deterministic rules, so the same input always produces the same output. AI code review uses a probabilistic language model that can reason about intent and cross-file logic but can also miss things or produce different results on repeated runs. Most mature teams run both. ### What bugs can AI code review catch that linters cannot? AI reviewers can flag logic errors, broken invariants, missing edge cases, race conditions, and mismatches between the code and its stated intent — categories that require understanding what the code is supposed to do. Linters and static analyzers only catch patterns someone has already written a rule for. ### Does AI code review replace human review? No. In practice it acts as a first-pass reviewer that clears mechanical and obvious issues before a human looks at the PR, so humans can focus on architecture, product intent, and trade-offs. Research at Microsoft found most human review value is knowledge transfer and design discussion, which AI does not replace. ### How accurate are AI code reviewers? It varies widely by tool and by who runs the benchmark. Greptile's own benchmark reported an 82% bug-catch rate, but an independent re-run by Augment Code scored the same tool at 45% on the same repositories. Treat every vendor-published number with skepticism and test tools on your own recent bugs. ### How widely adopted is AI code review? Very. As of August 2026, Google's DORA research reports that around 90% of technology professionals use AI at work, and GitHub's Octoverse found nearly 80% of new developers adopt Copilot in their first week. Dedicated review tools have scaled with that wave — CodeRabbit alone reported 13 million pull requests reviewed by late 2025. ### How much does AI code review cost? Most commercial tools charge per contributing developer per month, typically in the range of a mid-tier SaaS seat, with open-source options like Kodus available to self-host. The bigger cost question is signal quality: a noisy reviewer taxes every PR with triage time, which usually outweighs the subscription price. # AI Code Review Statistics (2026): Sourced Data > AI code review statistics for 2026: adoption, trust, review turnaround, AI code volume, and bug-catch benchmarks — every stat linked to a primary source. The most load-bearing AI code review statistics, as of August 2026: 90% of technology professionals use AI at work ([DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)), 46% of developers actively distrust AI output accuracy ([Stack Overflow 2025](https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/)), AI introduces security vulnerabilities in 45% of coding tasks ([Veracode](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/)), and bug-catch rates for AI review tools range from 82% to 45% *for the same tool on the same repos* depending on who runs the benchmark. This page collects every defensible statistic in the category, grouped by theme, each with a one-line takeaway and a link to its primary source. No unsourced numbers appear anywhere below. A note on method: we prefer primary sources (survey publishers, papers, vendor engineering blogs reporting their own telemetry) over listicles, we date every figure, and where a number is vendor-published we say so. If a widely-quoted stat is missing, it's because we couldn't trace it to a real source — a surprisingly common outcome in this category. Start with [what AI code review is](/blog/what-is-ai-code-review) if you need the conceptual groundwork. ## Adoption: AI is in the workflow **90% of technology professionals use AI at work** — up 14 points year over year, per [Google's 2025 DORA report](https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/) (~5,000 respondents). *Takeaway: AI-assisted development is no longer an early-adopter behavior; it's the baseline.* **Developers spend a median of 2 hours per day working with AI** — also [DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report). *Takeaway: a quarter of the working day now flows through tools that didn't exist four years ago.* **84% of developers use or plan to use AI tools**, up from 76% in 2024 and 70% in 2023 — [Stack Overflow 2025 Developer Survey](https://survey.stackoverflow.co/2025/ai/), 49,000+ respondents. *Takeaway: three consecutive years of growth, with the remaining gap mostly organizational rather than attitudinal.* **GitHub Copilot crossed 20 million all-time users** in July 2025, adding 5 million in a single quarter — [TechCrunch, reporting Microsoft's earnings call](https://techcrunch.com/2025/07/30/github-copilot-crosses-20-million-all-time-users/). *Takeaway: the largest single AI dev tool population on record.* **Nearly 80% of new GitHub developers use Copilot within their first week** — [GitHub Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/). *Takeaway: for the incoming generation of developers, AI-assisted is the only workflow they've ever known.* **82% of developers use AI coding assistants daily or weekly**, and **59% juggle three or more AI tools** — [Qodo's 2025 State of AI Code Quality survey](https://www.qodo.ai/reports/state-of-ai-code-quality/) (609 developers). *Takeaway: the question inside teams has shifted from whether to use AI to how many overlapping tools to tolerate.* **CodeRabbit reported 13 million pull requests reviewed across 2 million repositories** by its September 2025 Series B — [company announcement](https://www.businesswire.com/news/home/20250916401011/en/CodeRabbit-Raises-%2460M-Series-B-Following-Unprecedented-Growth-as-Vibe-Coding-Triggers-a-Need-for-New-Code-Quality-Standards) (vendor-published). *Takeaway: dedicated AI review, specifically — not just code generation — is operating at internet scale.* ## The trust gap: usage up, confidence down **46% of developers actively distrust the accuracy of AI output**, up from 31% a year earlier; **only 3% report high trust** — [Stack Overflow 2025 press release](https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/). *Takeaway: adoption and trust are moving in opposite directions — the defining tension of this era.* **30% of professionals report little or no trust in AI-generated code** — even while 90% use AI and 80%+ credit it with productivity gains ([DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)). *Takeaway: teams have decided verification, not abstinence, is the answer — which is exactly the job review exists to do.* **66% of developers say their top AI frustration is "solutions that are almost right, but not quite"**, and **45% say debugging AI-generated code takes more time** — [Stack Overflow 2025](https://survey.stackoverflow.co/2025/ai/). *Takeaway: near-miss code is the costliest kind — plausible enough to merge, wrong enough to bite.* **65% of developers say AI misses relevant codebase context** during refactoring, testing, and review — [Qodo 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/). *Takeaway: context, not raw model capability, is the binding constraint practitioners actually report.* **Only 25.8% of senior developers (10+ years) are confident shipping AI-written code without human review** — [Qodo 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/). *Takeaway: the people with the most scar tissue are the least willing to skip review.* ## How much code AI writes now **More than 25% of Google's new code was AI-generated** as of October 2024, per CEO Sundar Pichai on the Q3 2024 earnings call — [The Hill](https://thehill.com/policy/technology/4962336-google-ceo-says-more-than-25-percent-of-companys-new-code-written-by-ai/). *Takeaway: the first hyperscaler to put a hard number on it, and the number that made the trend undeniable.* **20-30% of code in Microsoft's repositories is written by AI**, per CEO Satya Nadella in April 2025 — [Entrepreneur's coverage](https://www.entrepreneur.com/business-news/ai-is-taking-over-coding-at-microsoft-google-and-meta/490896). *Takeaway: consistent order of magnitude across the two largest engineering organizations on earth.* **Over 90% of Anthropic's code is written by Claude**, per its CFO; individual engineers at Anthropic and OpenAI [claim 100% for their own work](https://finance.yahoo.com/news/top-engineers-anthropic-openai-ai-194731072.html) — [TechSpot](https://www.techspot.com/news/112408-anthropic-more-than-90-code-now-written-ai.html). *Takeaway: at the frontier labs, human-typed code is already the exception.* **A quarter of Y Combinator's Winter 2025 batch had codebases roughly 95% AI-generated** — [TechCrunch, quoting YC partner Jared Friedman](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated). *Takeaway: for new companies, the review question isn't about a minority of AI code — it's about nearly all of it.* **1.1 million public repositories import an LLM SDK, up 178% year over year** (as of August 2025), and **nearly 1 billion commits were pushed in a year, up 25%** — [GitHub Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/). *Takeaway: both the code and the software itself are becoming AI-native, and total change volume is accelerating.* **GitHub's Copilot coding agent authored over 1 million pull requests in its first five months** (May-September 2025) — [Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/). *Takeaway: agents don't just write code anymore; they open the PRs — and someone, or something, has to review them.* ## Quality and security of AI-generated code **AI introduced security vulnerabilities in 45% of coding tasks**, across 80 curated tasks and 100+ LLMs; **Java failed 72% of the time** — [Veracode 2025 GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/). *Takeaway: security performance has not improved with syntactic fluency — models write working, vulnerable code.* **About 40% of GitHub Copilot's generated programs were vulnerable** in security-relevant scenarios (1,689 programs, 89 CWE-based scenarios) — [Pearce et al., "Asleep at the Keyboard," IEEE S&P 2022](https://arxiv.org/abs/2108.09293). *Takeaway: the earliest rigorous result in the field, and its headline number has held up remarkably well across four years of newer models.* **Duplicated code blocks rose 8x during 2024** in GitClear's dataset of 211 million changed lines — [GitClear 2025 AI Code Quality research](https://www.gitclear.com/ai_assistant_code_quality_2025_research). *Takeaway: AI assistants default to copy-paste over reuse, and it shows up at dataset scale.* **Refactoring collapsed from 21% of changed lines (2022) to 3.8% (mid-2026)** while copy-paste rose from 9.4% to 15.7%, across 623 million analyzed changes — [GitClear 2026 Maintainability Gap research](https://www.gitclear.com/the_ai_code_quality_maintainability_gap). *Takeaway: codebases are accumulating structure debt at the exact moment change volume is exploding.* **Updates to code older than 12 months fell 74%** (1.7% of changes in 2023 to 0.46% by mid-2026), and cross-file function calls fell 35% — [GitClear 2026](https://www.gitclear.com/the_ai_code_quality_maintainability_gap). *Takeaway: new AI-era code increasingly bolts on rather than integrates — the maintenance bill hasn't arrived yet.* ## Speed and productivity: the evidence cuts both ways **Developers with Copilot completed a controlled task 55.8% faster** (95 freelancers, HTTP server task, 95% CI of 21-89%) — [Peng et al., 2023](https://arxiv.org/abs/2302.06590). *Takeaway: on greenfield, well-specified tasks, the speedup is real and large.* **Experienced open-source developers were 19% slower with AI tools** on their own mature codebases (randomized controlled trial, 16 developers, 246 tasks) — and forecast they'd be 24% faster, still believing afterward they'd been 20% faster — [METR, July 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). *Takeaway: on complex, familiar code, AI can be a net drag — and self-reported productivity is unreliable enough that you should [measure outcomes, not vibes](/standards/09-measurable-roi).* **A 25% increase in AI adoption correlated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability** — [DORA 2024 Accelerate State of DevOps report](https://dora.dev/research/2024/dora-report/). *Takeaway: more code, faster, without stronger review and smaller batches, measurably degrades delivery.* **More than 80% of DORA 2025 respondents say AI increased their productivity** — [DORA 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report). *Takeaway: perceived individual gains and measured organizational outcomes are different quantities; the gap between this stat and the previous one is where engineering leadership lives.* ## Human review baselines: the bar AI has to clear **Median code review latency at Google is under 1 hour for small changes and about 5 hours for very large ones**, with **70% of changes committed within 24 hours** of being sent for review — [Sadowski et al., "Modern Code Review: A Case Study at Google," ICSE 2018](https://sback.it/publications/icse2018seip.pdf). *Takeaway: the best-known review culture in the industry runs on small changes and same-day turnaround — that's the standard, not the average.* **Reviewers should cover no more than 200-400 lines at a time, yielding 70-90% defect discovery** in 60-90 minutes — [SmartBear's study of code review at Cisco](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/) (2,500 reviews). *Takeaway: human defect-finding degrades sharply with diff size — a constraint AI-scale code volume violates daily.* **Fewer than 15% of code review comments at Microsoft relate to actual defects** — the majority of value is knowledge transfer, awareness, and alternative solutions — [Bacchelli & Bird, "Expectations, Outcomes, and Challenges of Modern Code Review," ICSE 2013](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/). *Takeaway: automating defect-finding is tractable; automating what humans mostly do in review — teaching each other the codebase — is not.* **Targeted reminder nudges cut pull request resolution time by 60%** in a randomized trial across 147 Microsoft repositories (8,500 PRs) — [Maddila et al., "Nudge," 2020](https://arxiv.org/abs/2011.12468). *Takeaway: most review delay is idle waiting, not active reviewing — which is why instant first-pass AI review attacks the right bottleneck.* ## Does AI review work? Effectiveness and benchmark data **73.8% of an LLM reviewer's comments were resolved by developers** in an industrial deployment across 4,335 pull requests — but average PR closure time rose from 5 hours 52 minutes to 8 hours 20 minutes — [Automated Code Review in Practice, ICSE 2025](https://arxiv.org/abs/2412.18531). *Takeaway: the signal is real and so is the tax; net value depends on filtering, which is why [validating findings before surfacing them](/standards/06-sandbox-validation) matters.* **81% of developers using AI code review saw code quality improve, versus 55% of fast-moving teams without it** — [Qodo 2025](https://www.qodo.ai/reports/state-of-ai-code-quality/). *Takeaway: the largest practitioner survey in the category finds a 26-point quality gap in favor of AI review.* **Developers using Copilot Autofix fixed security alerts in a median of 28 minutes versus 1.5 hours manually** — 3x faster overall, 12x for SQL injection — [GitHub, from public beta telemetry](https://github.blog/news-insights/product-news/secure-code-more-than-three-times-faster-with-copilot-autofix/) (vendor-published). *Takeaway: the strongest measured wins come from AI layered on deterministic detection — the [AI-plus-static-analysis architecture](/blog/ai-code-review-vs-static-analysis), not either alone.* **The same tool scored 82% on its own benchmark and 45% on a competitor's re-run of the same repositories** — [Greptile's benchmark](https://www.greptile.com/benchmarks) versus [Augment Code's evaluation](https://www.augmentcode.com/tools/coderabbit-vs-greptile-vs-augment-cosmos). *Takeaway: vendor benchmark numbers are marketing until independently reproduced — every vendor that publishes one wins it.* **On 165 real CVEs from the OpenSSF CVE Benchmark, AI-era review tools scored from 84.5% F1 down to the mid-30s** — [DeepSource's 2026 evaluation](https://deepsource.com/benchmarks) (vendor-run, but on the public [OpenSSF dataset](https://github.com/ossf-cve-benchmark/ossf-cve-benchmark)). *Takeaway: the spread within the category is wider than the gap between categories — tool choice matters more than tool type.* **93.4% of findings in a four-tool, 146-PR field test were caught by exactly one tool**, with false-positive rates from ~0% to 15% depending on tool and severity tier — [independent 3.5-week parallel comparison, 679 findings](https://dev.to/_vjk/best-ai-code-reviewer-in-2026-we-ran-4-in-parallel-for-3-weeks-146-prs-679-findings-1c0f). *Takeaway: AI reviewers barely overlap — coverage is far from saturated, and no single tool sees most of what's catchable.* ## Using these numbers Three patterns worth extracting from the pile. First, the volume story is settled: AI writes a large and growing share of code, and that share carries a documented defect and vulnerability rate — the review workload is structural, not cyclical. Second, the trust gap is rational: developers distrust AI output *because* they use it daily, which makes verification infrastructure — human and automated — the growth constraint. Third, effectiveness numbers are the least trustworthy category on this page: whenever a bug-catch rate has only one source and that source sells the tool, treat it as a hypothesis. Our [evaluation guide](/blog/how-to-evaluate-ai-code-review-tools) covers how to generate your own numbers from your own bug history, the [tools comparison](/blog/best-ai-code-review-tools) maps the current field, and the [assessment](/assessment) benchmarks your review process against teams at your scale. Corrections welcome: if any figure above has been updated or corrected by its publisher, we'll revise it — that's the deal a stats page makes with its readers. ## FAQ ### What percentage of developers use AI coding tools? As of the most recent major surveys, 90% of technology professionals report using AI at work (Google DORA 2025) and 84% of developers say they use or plan to use AI tools in their development process (Stack Overflow 2025, 49,000+ respondents). Both figures rose year over year for the third consecutive year. ### How much code is written by AI? Google reported more than 25% of its new code was AI-generated in October 2024, Microsoft's CEO cited 20-30% in April 2025, and Anthropic's CFO said over 90% of its code is written by Claude. Among Y Combinator's Winter 2025 startups, a quarter had codebases that were roughly 95% AI-generated. ### Does AI-generated code have more bugs or vulnerabilities? Veracode's 2025 study of 100+ LLMs found AI introduced security vulnerabilities in 45% of coding tasks, and NYU researchers found about 40% of Copilot-generated programs in security-relevant scenarios were vulnerable. GitClear's longitudinal data also shows duplicated code rising sharply and refactoring collapsing as AI assistance spreads. ### How effective are AI code review tools at catching bugs? Published numbers vary enormously by who runs the benchmark. Greptile's self-run benchmark reported an 82% catch rate, while Augment Code's re-run on the same repositories scored it at 45%; on the OpenSSF CVE Benchmark, tools ranged from 84.5% F1 down to the mid-30s. The only reliable evaluation is running candidate tools on your own historical bugs. ### Does AI actually make developers faster? The evidence cuts both ways. A 2023 controlled experiment found Copilot users completed a task 55.8% faster, but METR's 2025 randomized trial found experienced open-source developers were 19% slower with AI tools on mature codebases — while believing they were 20% faster. Context and codebase familiarity appear to determine which result you get. ### How long do human code reviews take? At Google, median review latency is under one hour for small changes and about five hours for very large ones, with 70% of changes committed within 24 hours. Industry-wide, turnaround is typically much slower — Microsoft research found reminder nudges alone cut pull request resolution time by 60%, implying most delay is idle waiting.