Why AI code review is noisy, and how to cut the false positives.
An AI reviewer that blocks your merge on a hunch, or buries one real problem under ten minor notes, gets ignored. These are the rules Veridu uses to decide what can block and what gets shown.
- It only reads the diff. A reviewer that cannot open the caller or the subclass guesses about them, and some of those guesses are wrong.
- One model, one opinion. A single reviewer's hunch reads exactly like a confirmed defect in the comment.
- It rates its own severity. A test typo or a style point can come back as "critical" and block the merge.
- Everything gets posted. Minor notes sit next to real problems, and the real ones get skimmed past.
- 1Look outside the diff first. Veridu looks for the callers, subclasses and other code a change affects and gives it to the reviewers, so fewer findings are guesses about code they could not see. What it checks, by language
- 2Drop findings that point at nothing. A finding that cites a file that does not exist, or a line the file does not have, is dropped. The rest still need your judgement.
- 3Only corroborated problems block. A review blocks only when two reviewers find the same defect independently and both rate it at or above your blocking threshold. Anything else is "needs review", never a block.
- 4A second look at single-reviewer findings. On reviews run by agent reviewers, when both reviewers finish, up to three medium-or-higher findings that only one of them reported (each with a file and line) are shown to the other to prove, refute or leave unproven.
- 5Unsure findings are capped. A finding from one reviewer, which that reviewer itself marked as unsure (low or possible confidence) and which was not confirmed, counts at most as medium. Its original severity is still shown.
- 6Hide what is below your level. On reviews that do not block, findings below the repository's display level (medium by default) can be left out of the PR comment and check summary, with a link to the full review. A blocking review shows every finding, and at least one finding is always shown.
- 7Dismiss the wrong ones, with a reason. Comment /veridu dismiss F1 <reason> or use Dismiss on the review page. The finding leaves the verdict, and the reason is recorded and shown.
Does this make every finding correct?
No. These rules decide what can block and what gets shown. Some findings will still be wrong, and a human decides.
Why not just raise the severity bar?
Because a reviewer's own severity is part of the problem. Requiring two reviewers to find the same defect independently is a stronger filter than any single rating.
Can a real problem be missed because only one reviewer found it?
A finding from one reviewer cannot block, so the review reads as needs review, not pass. It is shown in the PR comment unless it falls below the display level while other findings are shown, and the comment links the full review.
What does it cost?
Up to 20 reviews a month on public GitHub repositories are free, no card. Solo and Team plans add private repositories.
The demo is a real review, stored as it ran, with the findings the reviewers agreed on and the ones they disputed.