AI Code Reviewers With Low False Positive Rates (2026)

Direct answer

No AI code reviewer has a verified low false-positive rate, because nobody independent has ever published false-positive data for this category. Every FP and catch-rate number in circulation as of 2026-10-18 was published by a vendor scoring itself. Greptile’s benchmark states plainly that false positives “did not affect the catch rate.” Until independent data exists, judge noise by architecture: deterministic-static-first pipelines, suppression and learning systems, and configurable severity thresholds.

AI code reviewers with low false positive rates

Direct answer: No tool can prove a low false-positive rate. We found exactly four published FP figures, all vendor-sourced: Panto’s 11-per-PR for Greptile versus 2 for CodeRabbit (17 PRs, April 2026), and Graphite’s unmethodologised “under 5% negative comment rate.” Use precision as a proxy: Codex 68%, Bugbot 60%, Greptile 45%, CodeRabbit 36%, Claude Code 23%. Verified 2026-10-18.

This is the uncomfortable version of the answer, and it is the correct one.

I went looking for a false-positive rate I could stand behind. I read the academic benchmarks, the vendor benchmarks, the re-runs of the vendor benchmarks, and the leaderboards. There is no independent false-positive measurement for AI code review. Not one. Every number a buyer encounters traces back to a company that sells a reviewer.

The most honest statement of this comes, with some irony, from DeepSource, which published a post titled “Every AI code review vendor benchmarks itself, and wins”. Its core line: “Every vendor that has published one wins their own.” The post lists Greptile at 82% recall, Qodo at 60.1% F1, Augment at 59% F1, Propel at 64% F1, Macroscope at 48% detection and Entelligence at 47.2% F1 - six vendors, six victories. It does not list DeepSource’s own 84.51% F1 score, which appears on deepsource.com/resources/ai-code-review-tools alongside a 36.19% score for CodeRabbit. The critique is correct and it applies to its author.

The comparison the post is pointing at is the one worth memorising. Greptile’s own benchmark scored Greptile at 82%. Augment re-ran the same five repositories and scored Greptile at 45%. Same repos, same era, two publishers, a 37-point gap.

What false-positive data actually exists

Source	Publisher	Sells a reviewer?	FP figure published	Sample	Methodology published?
Greptile Benchmarks	Greptile	Yes	None. FPs explicitly excluded from scoring	50 PRs, 5 repos	Partial, no raw data
Augment 7-tool benchmark	Augment	Yes	Precision only (FP = “incorrect or irrelevant comments”)	50 PRs, 5 repos	Yes, data + scripts open sourced
Entelligence Benchmark 2026	Entelligence	Yes	Precision only, no FP count	67 golden comments, 50 PRs, 5 repos	Yes, LLM-ensemble golden set
DeepSource	DeepSource	Yes	None	165 CVEs from OpenSSF CVE Benchmark	Partial, results as JSONL
Panto comparisons	Panto	Yes	~11 FP/PR Greptile vs ~2 CodeRabbit	17 open-source PRs	Partial, o3-mini used as classifier
Graphite AI Reviews	Graphite	Yes	”Less than 5% negative comment rate”	Not stated	No
Martian Code Review Bench	Martian	No (sells model routing)	Precision as proxy: “bot suggestions matched to real fixes / total suggestions”	50 PRs offline, ~300k PRs online	Yes, open source
c-CRAB	NUS (academic)	No	None. No FP rate reported	184 PRs, 67 repos, 234 tests	Yes, in paper
CRBugBench	CMU + Microsoft Research	No	None. Recall@k only	1,800 tasks, 98 OSS + 2 proprietary repos	Yes, in paper

Seven of nine come from companies selling the thing being measured. Of the two that do not, neither reports a false-positive rate.

The miscitation to stop repeating

A widely-circulated claim attributes a “40-70% false positive rate” to c-CRAB, the Code Review Agent Benchmark from the National University of Singapore (arXiv 2603.23448, authors Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen, Abhik Roychoudhury). One disclosure, because we hold other publishers to it: c-CRAB is not conflict-free. Five of its six authors are academic (National University of Singapore, Zhejiang University), but one lists SonarSource as their affiliation (arXiv 2603.23448v3, verified 2026-10-18), and the paper carries a disclaimer that its conclusions do not represent SonarSource policy. Sonar sells SonarQube and acquired Gitar, which is a paid sponsor of this site. SonarQube is not among the four tools c-CRAB evaluates, which blunts the conflict considerably - but we are not going to call out vendor-funded benchmarks elsewhere and stay quiet about this one.

That figure does not appear in the paper. We read it. Here is what the paper actually contains.

The headline number is a pass rate, not an error rate: “Taking the union across all four tools, 97 out of the 234 tests were passed by at least one tool (41.5%).” Per-tool pass rates are Claude Code 32.1%, Devin Review 24.8%, PR-Agent 23.1%, Codex 20.1%.

The phrase “false positive” appears twice, both times conceptually and neither time as a measured rate for any tool. In section 2.2, discussing prior work: “While such complementary suggestions can be beneficial, the resulting false positives may also substantially increase the burden on maintainers during software development.” In section 4.2.1, describing how the authors tuned their own comment classifier: “We prioritize precision as the evaluation metric because false positives are particularly harmful.” That second quote is about the benchmark’s internal filtering prompt, not about the reviewed tools.

So: c-CRAB reports no false-positive rate for PR-Agent, Devin, Claude Code or Codex, and no number between 40% and 70% in the paper describes false positives. The 41.5% is how many curated tests the four agents collectively passed. If you have cited the 40-70% figure, it is not sourced to c-CRAB and you should drop it.

The methodology is worth knowing because it is genuinely novel. c-CRAB takes a human review comment on a real pull request, generates an executable test from the comment and the diff, then has a coding agent revise the patch using the review guidance and runs the revision against the generated test, verifying fail-then-pass behaviour. A review “passes” if acting on it makes a failing test pass. That is a far harder bar than string-matching against a golden comment, and it is why the numbers are low.

How accurate are automated code reviews?

Direct answer: Nothing clears roughly 60% F1 on a curated golden set. c-CRAB’s four agents collectively passed 41.5% of 234 tests. On Augment’s corrected 50-PR set, the best F-score was 59%. CodeRabbit led Martian’s online track at 51.2% F1 in March 2026. CRBugBench’s best model hit 79.6% recall@5 but reports no precision. Verified 2026-10-18.

The accurate answer has two halves, and conflating them is how buyers get misled.

On curated golden sets with precision counted, nothing is above 60% F1. Augment’s re-run of the five-repo set is the most useful single table in the category, because it publishes precision, recall and F-score together, and because Augment rebuilt the answer key by hand rather than inheriting Greptile’s: “We expanded and corrected the golden comments by reviewing each PR manually, verifying issues, and validating them against tool outputs.” The data and scripts are at github.com/ai-code-review-evaluations. Published 11 Dec 2025, updated 18 Jun 2026.

Tool	Precision	Recall	F-score	Shape
Augment Code Review	65%	55%	59%	Only row above 50% on both axes
Cursor Bugbot	60%	41%	49%	Precision-leaning
Greptile	45%	45%	45%	Balanced, vendor claims 82%
Codex	68%	29%	41%	Quietest, misses the most
CodeRabbit	36%	43%	39%	Recall-leaning
Claude Code	23%	51%	31%	Highest recall, lowest precision
GitHub Copilot	20%	34%	25%	Weakest on both

Note the benchmark’s owner tops it. That is the pattern, not an accusation - Augment published its corrected data, which is more than most.

Entelligence’s 2026 benchmark built a different golden set: 67 comments across 50 PRs in Cal.com (TypeScript), Sentry (Python), Discourse (Ruby), Keycloak (Java) and Grafana (Go), generated by an ensemble of Claude Opus, Gemini 2.5 and GPT-5, arbitrated by GPT-4o, then human-validated. Entelligence ranks first at 47.2% F1. The repository-level swings are the real finding: Entelligence hit 100% precision with 33.3% recall on Grafana and 68.1% F1 on Cal.com, while Greptile went from 52.6% F1 on Keycloak to 24.5% on Sentry. Language and repository move these scores more than tool choice does. If you take one methodological lesson from this article, take that one.

On recall-only measures of frontier models, the numbers look much better and mean less. CRBugBench (arXiv 2610.13668, Chenyang Yang, Hao He, Ti-Chung Cheng, Jenna Butler, Emerson Murphy-Hill, Carmen Badea, Christian Bird) runs 1,800 review tasks across 98 GitHub repositories plus 2 proprietary industry repositories in 5 languages. Its best performer, claude-opus-5, catches 79.6% of bugs found before PR merge and 64.2% of bugs found after merge, within its top five findings, at $2.97 per task and 9.8 minutes average latency. Detection climbed from 47.7% (opus-4.6, February 2026) to 71.9% (opus-5, July 2026).

That trajectory is real and it matters. But CRBugBench reports no precision and no false-positive figure. Recall@5 means the right answer was somewhere in five findings. It says nothing about the other four, and nothing about the twenty findings a tool posts on a PR where there is no bug. The paper’s framing is explicitly about whether a “lights-off” software factory is viable, and its answer is collaborative: human and agent together reach 82.1% coverage, above the agent’s 79.6% alone.

I would also note the obvious: Microsoft Research co-authored it, Microsoft owns GitHub and Copilot, and the primary agent harness was copilot-cli. That does not invalidate the work, which is careful and published. It does mean “academic” and “disinterested” are not synonyms, and we should say so.

The one leaderboard nobody sells a reviewer on

Martian’s Code Review Bench is the closest thing to an independent measurement that exists, for one structural reason: Martian sells model routing, not code review. It runs two tracks. The offline track scores tools against 50 PRs with human-verified golden comments. The online track continuously samples fresh real-world PRs where review bots left comments, then measures “bot suggestions matched to real fixes / total suggestions” - whether developers actually changed the code. Tracked bots include CodeRabbit, GitHub Copilot, Claude, Cursor, Augment, Codex, Gemini, Greptile, Graphite, Qodo and Propel.

The online track is the best precision proxy in the market because fresh PRs cannot be in anyone’s training data and because developer behaviour is hard to game. CodeRabbit announced on 3 March 2026 that it topped the online track with 51.2% F1, 49.2% precision, 53.5% recall across nearly 300,000 PRs over January and February.

Then the leaderboard got used the way every leaderboard gets used. Qodo announced on 15 March 2026 that it was first at 64.3% F1. Baz announced it was first on precision at 70.9% and F1 at 52.5% - on 790 PRs, against CodeRabbit’s roughly 300,000. Three claims of first place from one leaderboard inside twelve days, on samples differing by nearly three orders of magnitude.

Two cautions on the 51.2% number. It is a dated snapshot of a continuously-updating leaderboard, so cite it with the date or not at all. And “percentage of comments acted on” is not a false-positive rate: a developer can change code for a comment that was wrong, and ignore a comment that was right.

Which AI code reviewer gives the most useful feedback?

Direct answer: Depends which error you can absorb. Highest balance: Augment at 59% F-score. Highest precision: Codex at 68%, but it misses 71% of real issues. Highest recall: Claude Code at 51%, with 23% precision. Best behavioural signal: CodeRabbit at 49.2% precision on Martian’s online track, March 2026. No tool is best on both axes. Verified 2026-10-18.

There is no single answer and anyone giving you one is selling something. What there is, is a defensible way to choose.

Because false-positive rates are unverifiable, pick on architecture. These three properties are checkable from documentation, which makes them better evidence than a marketing percentage.

1. Deterministic static analysis runs first

A reviewer that resolves most findings with rules before a model ever sees the diff is predictable, and predictability is what you actually want. A rule that misfires misfires identically on every PR, so you suppress it once. A model that misfires produces a slightly different wrong opinion each time, which you re-litigate forever.

DeepSource runs 5,000-plus deterministic static analysis rules across 30-plus languages before the AI agent sees the code (verified 2026-10-18). SonarQube is rule-based at its core with the SAST engine running fully on-prem - with two caveats worth knowing before you budget: Community Build analyses the main branch only, so PR analysis is not included, and the AI features are Enterprise-tier. Semgrep rules are YAML and auditable, which means a finding is traceable to a rule you can read.

2. Suppression and learning that persists

The question is whether correcting the tool once sticks.

CodeRabbit has the deepest configuration surface here. In .coderabbit.yaml: a chill review profile versus assertive; path_filters with negation patterns for lockfiles, dist, node_modules, generated files and snapshot directories; path_instructions scoped per glob so API rules do not fire on tests; limit_reviews_by_label; and a knowledge_base.learnings block that retains the context you give it in replies. We cover the full file in the .coderabbit.yaml reference and the tuning sequence in reducing CodeRabbit noise.

Cursor Bugbot takes the rules-as-code route. It reads .cursor/BUGBOT.md from the repo root plus any it finds walking up from each changed file, so backend/.cursor/BUGBOT.md applies only when backend code changes. The limits are real and underdocumented in comparisons: 30,000 characters per rule, 100,000 characters of rules total per review, with overflow silently dropped - bugbot run verbose=true shows what got cut. Rules must be merged to the default branch to apply. And a trap: Bugbot reads .cursor/BUGBOT.md, not .cursor/rules/, so IDE rules do not carry over. Bugbot also promotes learned rules from accumulated signal and can disable active rules that generate consistent negative signal. See Bugbot vs Greptile for how that compares in practice.

3. A confidence or severity threshold you control

This is the first config lever any team should pull, and most teams never find it.

Qodo exposes it explicitly. In .pr_agent.toml under [review_agent], inline_comments_severity_threshold takes three ranks - 3 = action_required, 2 = remediation_recommended, 1 = informational - and publishes inline only findings at or above the threshold. Set it to 3 and you see action-required findings only. A separate suggestions_score_threshold filters the /improve tool’s confidence-ranked suggestions. Organisation-wide defaults go in a pr-agent-settings repository. Qodo also filters low-confidence findings before publication by design, using a judge agent that merges parallel specialist agents’ output and drops duplicates.

Severity gating beats tool-switching. A reviewer at 36% precision across all severities may be at acceptable precision on action-required findings alone. Before you churn vendors, gate on severity for two weeks and re-measure.

Noise control	CodeRabbit	Cursor Bugbot	Qodo	DeepSource	SonarQube
Deterministic rules before AI	No	No	No	Yes, 5,000+	Yes, rule-based core
Persistent learning from corrections	Yes (knowledge_base.learnings)	Yes (learned rules + BUGBOT.md)	Partial (PR history weighting)	No	No
Severity / confidence threshold	Profile + instructions	Scrutiny level	Yes, numeric	Rule-level	Rule-level
Path-scoped suppression	Yes (path_filters)	Yes (nested BUGBOT.md)	Yes	Yes	Yes
Config as code	.coderabbit.yaml	.cursor/BUGBOT.md, bugbot.yaml	.pr_agent.toml	.deepsource.toml	Quality profiles
Published FP rate	No	No	No	No	n/a

Verified against vendor documentation 2026-10-18.

Downsides of using AI for pull request reviews

Direct answer: Four. Noise at scale - 36% precision means most comments are not accepted findings. Silence read as safety - Graphite returned zero comments on a clean PR and scored 0 of 16 on Cal.com. Low FP rates hiding low recall - Codex posts few bad comments and misses 71% of real ones. And plausible-but-invalid reviews, which the best general LLM detected only 20.77% of the time.

Two of these are argued constantly. Two are almost never stated, and they are the important ones.

Silence is not precision

A reviewer that posts nothing scores perfectly on false positives. It is also worthless, and worse than worthless if a green check gets read as a safety signal.

Graphite is the clean illustration, and I want to be fair about why. In a 2026 test on a clean, default-configuration TypeScript PR with 0 custom rules, 0 exclusions and no skip, Graphite’s AI review completed successfully and returned zero comments - re-run on a clean PR to confirm it had actually executed - while Qodo, Claude Code and Bito each caught all four seeded defects. Entelligence’s larger set agrees: Graphite found 5 of 67 golden issues overall (7.5% recall, 13.4% F1) and 0 of 16 on Cal.com, 0 of 12 on Keycloak, 0 of 17 on Sentry. Greptile’s benchmark scored it 6%. Tenki’s 122-bug set scored it 3.3% recall. Macroscope’s 118-bug set was the most generous at 18.26%.

Here is the honest counterweight: Graphite had the highest aggregate precision in Entelligence’s benchmark, at 66.7%. It is tuned for extreme precision, and that is a defensible product decision - Macroscope frames it as a complement to a primary reviewer rather than a standalone one. Graphite’s own published figure is a negative comment rate under 5%, and Diamond launched in March 2025 claiming a sub-3% false-positive rate via whole-repo context. Graphite was acquired by Cursor on 19 December 2025, and the Diamond name was retired in favour of Graphite Agent.

But a passing check with no findings creates false reassurance, and no AI reviewer should be wired into branch protection as though silence were a verdict. Relatedly, on GitHub the Cursor Bugbot check concludes neutral when Bugbot finds issues, so requiring it in branch protection proves Bugbot ran and does not stop a merge with findings open.

A low false-positive rate can simply mask low recall

False positives cost reviewer attention. False negatives ship bugs. These are not symmetric and the market talks as if they were.

Codex is the case study. 68% precision in Augment’s run - the best of seven - and 29% recall, which placed it fourth of seven on F-score. It is the quietest reviewer in the set and it misses roughly seven of every ten real issues. If you bought Codex because it does not spam you, you bought silence on 71% of your defects.

Claude Code is the mirror image: 51% recall, the second-highest in that benchmark, on 23% precision, the lowest. Augment attributes the gap to its filtering stage. Depending on which column you sort, Claude Code is second or sixth of seven. Our own Claude Sonnet 4.5 code review benchmark found model-level behaviour pointing the same direction, and Qodo’s model-isolated run puts Claude Opus 5.5 at high reasoning at 56.8% F1 with 60.2% precision - which tells you the harness, not the model, drives most of the precision gap.

Ask any vendor quoting you a low false-positive rate what their recall is on the same dataset. If they do not have the second number, the first one is not a quality claim.

Plausible-but-invalid reviews are the hardest failure

This is the failure mode the benchmarks mostly miss: a comment that reads as expert, cites the right-looking concern, and is technically wrong about this codebase.

CRJudgeBench (Yue Pan, Jiawei Li, Ziyuan Zhang, Xiangxin Zhao, He Ye - University College London, Amazon, Zhejiang University) measured exactly this across 1,199 instances, 764 trustworthy and 435 untrustworthy review comments. The strongest general-purpose LLM baseline, GLM-5.3, detected only 20.77% of untrustworthy comments while recalling 98.69% of trustworthy ones. Models say yes to almost everything that sounds right.

Their Sentinel agent, which actively gathers repository evidence - searching repo elements, inspecting patches, tracing definitions - before judging, reached 76.60% overall accuracy versus 70.47%, and 37.69% untrustworthy recall versus 20.77%. Grounding in repository evidence nearly doubled detection of bad reviews and still missed most of them.

The practical implication runs straight into our companion piece: if neither you nor a model can reliably tell a valid review from a plausible one by reading the verdict, the explanation is the only thing you can check. That is the argument in AI code review tools that explain their findings, and it is why we treat explainability and noise as the two halves of one question.

The costs nobody puts in the FP column

Two concrete ones, verified 2026-10-18. Since 1 June 2026, GitHub Copilot code review on private repositories consumes GitHub Actions minutes in addition to Copilot AI credits - a line item most comparisons omit. And Greptile’s credits are per author and do not pool, with a “seat” counting any developer who received a review and Apex depth costing 10 credits per review, which makes noisy reviews expensive in a way seat pricing hides. See Greptile pricing and CodeRabbit pricing for the full breakdowns.

Run the only benchmark that counts: yours

Every number above is someone else’s repository. The only defensible false-positive rate for your team is the one you measure on your code. Here is a protocol that takes about a day of engineering time and produces a number you can defend in a budget meeting.

1. Pick 30 merged PRs from the last 90 days that each contain a bug fixed later, found in review, or caught in staging. You need ground truth, and your own history is the only ground truth you have.
2. Write down each known issue before you run anything. File, line, one sentence on consequence. This is your golden set. Do not let the tool’s output shape it - that is how Greptile’s and Augment’s keys diverged into a 37-point gap.
3. Run each candidate at default settings, on the same 30 PRs, in the same week. Default settings matter: a tuned tool against an untuned one is not a comparison.
4. Classify every single comment into: true positive matching your golden set, true positive you missed when writing the set (count it, and note it - this is where tools earn their money), false positive, or style/nitpick. Keep style separate from false positives. They are different problems with different fixes.
5. Compute three numbers per tool: precision, recall, and false positives per PR - the metric engineers actually feel and almost nobody publishes.
6. Then tune, and re-measure. Set Qodo’s inline_comments_severity_threshold to 3, CodeRabbit’s profile to chill with path_filters on generated code, Bugbot’s rules in .cursor/BUGBOT.md. Re-run. Most teams that report a noise problem have never pulled the severity lever.
7. Report the denominators. “11 false positives across 30 PRs” is a fact. “Low false positive rate” is a vibe.

Two things this protocol will tell you that no published benchmark can. First, how the tool behaves on your language and your architecture - and per-repository swings in Entelligence’s data were larger than per-tool swings. Second, whether the misses it produces are the kind your team catches anyway.

We are building this into a repeatable measurement. The ACR Noise Index will publish false positives per PR, precision and recall per tool on a fixed golden set we construct and release, with per-finding classifications public so anyone can dispute our calls. It will be the first false-positive measurement in this category published by a party that does not sell a code reviewer. Target: Q4 2026. We have no tool to sell, which is the entire reason it is worth doing and the entire reason you should still check our work.

How we verified this

What we checked, and when. All claims verified 2026-10-18 unless a different date is stated inline.

Primary sources read directly:

• c-CRAB, arXiv 2603.23448 - full text. Confirmed the 41.5% union figure as a test pass rate (“97 out of the 234 tests were passed by at least one tool”), the per-tool rates, the 184-PR / 67-repo / 234-test dataset, and the test-generation pipeline. Searched the text for “false positive” and found two conceptual mentions, neither a measured rate for any reviewed tool.
• CRJudgeBench, arXiv 2609.37216v1 - dataset composition, baseline and Sentinel accuracy figures.
• CRBugBench, arXiv 2610.13668 - abstract, task counts, recall@5 figures, cost and latency. Confirmed no precision metric is reported.
• Greptile Benchmarks - confirmed the scoring rule verbatim: “Scoring considered only detection of the original bug; false positives, style suggestions, and unrelated comments did not affect the catch rate.” Confirmed no FP counts are published for any tool.
• Augment’s 7-tool benchmark - full precision/recall/F table, the FP definition, and the open-sourced dataset location.
• Entelligence Code Review Benchmark 2026 - aggregate and per-repository tables, golden-set construction.
• DeepSource’s benchmark meta-post and its tool comparison.
• Martian Code Review Bench - offline and online track methodology, the precision definition, tracked tools.
• Vendor configuration documentation for CodeRabbit, Cursor Bugbot and Qodo.

What we could not verify.

• Panto’s 11-versus-2 false-positives-per-PR figure. We found it cited to an April 2026 Panto comparison, and we confirmed Panto’s broader methodology (17 open-source PRs, comments bucketed including a false-positive category, OpenAI o3-mini used as the classifier with severity labels stripped). We could not open a primary Panto page stating that exact per-PR pair. Treat it as reported, not confirmed. The same secondary source cautions that other runs rate Greptile’s precision far higher.
• Two of the three CodeRabbit scores reportedly printed from Martian’s leaderboard (30.3% on 25 March 2026 and 57.5% on 30 July 2026). We confirmed the 51.2% figure from CodeRabbit’s own newsroom, dated 3 March 2026, and we confirmed Qodo’s 64.3% and Baz’s 790-PR claim as vendor announcements. The other two CodeRabbit snapshots come from a secondary summary we could not trace to a primary post.
• Graphite’s sub-3% false-positive claim from Diamond’s March 2025 launch. Graphite’s current feature page states “Less than 5% negative comment rate” with no methodology. We found no methodology for either figure.
• The zero-comment Graphite result is reported by a third-party 2026 test with a stated clean-config setup. We did not reproduce it ourselves. Entelligence’s 0-of-16, 0-of-12 and 0-of-17 repository results are consistent with it.
• Any independent false-positive rate for any tool. This is the central finding and the reason for this article. If you have one, send it and we will publish it with attribution.

Where our numbers differ from a vendor’s, we print both and name the publisher. Greptile at 82% (Greptile), 45% (Augment) and 23.61% (Macroscope) is the same tool measured three ways, and the spread is the information.

Disclosure. Gitar is a paying sponsor of this site and Ito is an unpaid editorial baseline partner. Neither appears in the rankings above, for the same reason: neither has a published third-party benchmark, so we have no evidence to rank them on. Sponsorship buys placement, never a score. See gitar-review for our editorial assessment.

Recommendations

Stated criteria: we rank on verifiability of noise behaviour, not on claimed false-positive rates, because no claimed rate is independently verified. Architecture you can read beats a percentage you cannot check.

If you need predictable, auditable, suppressible findings: DeepSource or SonarQube. 5,000-plus deterministic rules across 30-plus languages running before the AI agent is the single strongest architectural predictor of low noise, because rule findings are reproducible and you suppress a class once. Budget warnings: SonarQube Community Build analyses the main branch only, so PR review is not included, and AI features are Enterprise-tier. DeepSource bills AI review per use.

If you need the most tunable noise floor: CodeRabbit. It has the deepest suppression surface in the category - chill profile, path_filters, path_instructions, persistent knowledge_base.learnings - and it leads the one leaderboard not published by a code review vendor (51.2% F1, 49.2% precision, Martian online track, 3 March 2026). Its 36% precision in Augment’s run is a default-settings number, and defaults are not where you should run it. Essentials is $24/dev/mo billed annually. Start at reducing CodeRabbit noise.

If you want a hard confidence gate: Qodo. It is the only tool in our set with a documented numeric severity threshold (inline_comments_severity_threshold, ranks 1-3) plus a judge agent that drops low-confidence findings before publication. Qodo also posted the highest self-reported F1 of any vendor benchmark at 60.1% - which is a vendor number, and we are labelling it as one.

If you want rules-as-code and a team that iterates: Cursor Bugbot. .cursor/BUGBOT.md with directory-scoped rules, learned rules that auto-disable on negative signal, and 60% precision in Augment’s run - second-best in that table. Watch the 100,000-character rule budget and remember the check concludes neutral on findings.

If recall is what you are buying, accept the noise: Claude Code. 51% recall at 23% precision in Augment’s run, and Anthropic’s multi-agent Code Review went GA to Claude Team and Enterprise on 15 October 2026 with $10k-plus in review credits for eligible Enterprise orgs. This is the right choice for payment, auth and migration code where a missed bug costs more than an hour of triage. Pair it with severity gating or a deterministic linter, not with hope.

Do not buy on a published false-positive rate. There isn’t one worth the pixels. Buy on architecture, then run the seven-step protocol above on 30 of your own PRs. That number is yours, it is defensible, and it is the only one your CFO should accept.

Next: the tools that explain their findings, which is the other half of whether you can trust the output. Or start from the full ranked list and the state of AI code review in 2026.