HeyDeer has the highest precision on ReviewBench

ReviewBench is an open benchmark for AI code review, built by GitHub. It runs each reviewer on 219 real pull requests from 187 repositories and compares what the reviewer reports with findings that people have reviewed and labeled.

HeyDeer is now on the leaderboard. On high-severity findings, the leaderboard’s default view, HeyDeer has the highest precision of every reviewer on the board: 99.0%. Almost every serious problem HeyDeer reported was a real one.

We didn’t get there by accident. Precision has been HeyDeer’s first design goal from day one. This post explains why, and how we get there.

1. What the numbers mean

ReviewBench reports two main scores (see its methodology for details):

• Precision: of the problems a reviewer reports that the benchmark can judge, how many are real.
• Recall: of the known problems in a pull request, how many the reviewer finds.

The two pull against each other. A reviewer that reports everything finds more problems and more noise; one that reports almost nothing is rarely wrong and rarely useful. On the run ReviewBench published, HeyDeer’s recall on high-severity findings was 51.4%, in the same range as most reviewers on the board, while its precision was the highest.

2. Why precision matters

For people: noise hides the real bugs

Every false positive costs a person time: reading the comment, checking the code and deciding it’s wrong. The bigger cost comes later. After a few rounds of noise, people learn that the reviewer’s comments are usually wrong and start skimming them, and the one real bug slips through with the rest.

A review with eight comments, six of them false, is worse than one with three real ones. A reviewer is only useful if people still read what it says.

For coding agents: false positives become code

More and more teams hand review comments straight to a coding agent. Agents do sometimes push back, but research shows they often follow a fix request even after recognizing it as wrong, quietly introducing new errors along the way (Jaiswal et al., 2026). A false positive becomes a null check for a value that can’t be null, a try/catch around code that can’t throw, or validation for input that is already validated.

Each of these looks harmless on its own. Together they bloat the codebase, hide what the code really guarantees, and give the next person, or the next agent, more to read and maintain. The more of your review you automate, the more precision matters, because no one is left to filter the noise.

3. How HeyDeer keeps precision high

Several models review and cross-check each other

A single model misses issues and reports false ones, and several copies of the same model tend to make the same mistakes. HeyDeer has models from different vendors review each change, then has each potential issue verified independently before it reaches your pull request. Different models have different blind spots, so cross-checking catches much of what any one of them gets wrong.

Agreement alone doesn’t count as proof: two models can be wrong in the same way. What decides whether a finding is posted is the evidence.

Every finding needs evidence

A finding has to show how the problem happens: from a real caller, user action or input, through the changed code, to the consequence. “This might be null” isn’t enough; the reviewer has to show where the null comes from. When one fact can’t be settled from the available evidence, the finding says so and names that fact, instead of presenting a guess as certain.

Reading the source, not guessing

Many false positives come from guessing how something outside the diff behaves. HeyDeer’s reviewers check instead:

• Dependency source: when a claim depends on how a library behaves, the reviewer reads the library’s actual implementation rather than relying on what it remembers.
• Documentation: reviewers search the official documentation of the frameworks and services the code uses.
• Sandbox checks: when reading isn’t enough, a reviewer can test a narrow claim in an isolated sandbox, such as how a function handles an edge case. Your repository’s own code never runs.

4. Recall: finding more without adding noise

High precision is easy if you stay quiet, so recall matters just as much. Since the version ReviewBench measured, we have improved HeyDeer’s recall, and we’ll share the numbers when ReviewBench publishes a new run.

The idea is to keep finding and filtering separate. The reviewers that look for problems report every candidate they can support with evidence, even when it seems small or unlikely; verification then decides what is real. Because verification holds the line on precision, discovery can look harder and from more angles without sending more noise to your pull request.

You also decide how much you see. HeyDeer’s feedback scope lets a team show only the important findings or every confirmed one, for a workspace or a single repository.

5. About the benchmark

No benchmark tells the whole story. ReviewBench is a research preview; the numbers above are its default high-severity view and change with the severity filter; and one score doesn’t say how a reviewer fits your codebase or your team. We think it’s a fair, open way to compare reviewers on real pull requests, and we’re glad to be measured in the open.

Try it on your own pull requests

The best benchmark is your own code. HeyDeer has a free plan, so you can run it on the same pull requests as the reviewer you already use and compare the results yourself.