False positives are an attention problem, not just a model problem. Use scope, evidence, confidence, deduplication, caps, and dismissal data to make AI review quieter and more trustworthy.
A false positive in AI code review is not free. A maintainer must read it, inspect the cited code, reconstruct enough context to reject it, and sometimes explain the rejection to a teammate. The direct cost may be a minute; the larger cost is trust. Once reviewers expect the bot to be wrong or irrelevant, they skim all of its comments, including the good ones. Precision is therefore a product requirement, not a cosmetic quality metric.
It helps to separate kinds of noise. A factually wrong finding claims a failure that cannot occur. An irrelevant finding may be true but outside the pull request or repository policy. A redundant finding repeats another comment. A weak finding lacks enough evidence to justify investigation. A misplaced finding is posted on a line that does not support the claim. These have different causes, so one prompt change will not fix them all.
A generic instruction to review everything encourages the model to fill every available category. Give specialist reviewers narrow responsibilities and explicit exclusions. A correctness reviewer can focus on runtime behavior, state transitions, error handling, and tests without offering naming preferences. A security reviewer can trace trust boundaries without commenting on component architecture. Narrow roles reduce competition among goals and make the absence of a finding an acceptable output.
Do not ask a final model call to solve every quality problem. Validate output against a schema, normalize paths, reject lines outside the diff, apply a minimum confidence threshold, and cap inline comments after sorting. Deduplicate using stable fields such as file, line, and normalized title. Code is better than another prompt for enforcing output shape and limits because its behavior is inspectable, repeatable, and cheap.
Repository context also matters, but more context is not always better. Include relevant configuration, nearby definitions, changed call sites, and concise project instructions. Avoid dumping an entire repository into a prompt simply because the context window allows it. Irrelevant context gives the model more patterns to speculate about and can bury the code that actually changed. Retrieval should answer a question raised by the diff, not become a tour of the codebase.
A maximum inline-comment count forces prioritization. Apply it after merging reviewer output so one specialist cannot consume the entire budget before stronger findings arrive. Sort by severity and then confidence, while preserving a route to inspect the remainder in run history. The cap does not make hidden findings correct, but it protects the pull request conversation from an unusually talkative run.
Record why findings are dismissed: incorrect, already handled, out of scope, duplicate, not actionable, or accepted risk. Review patterns by repository, reviewer role, model, and prompt version. If architecture comments are often marked out of scope in a maintenance repository, change that repository policy. If a model produces unsupported security claims, raise its threshold or switch the role. Do not optimize blindly for acceptance, because teams also accept low-value suggestions. The goal is fewer unjustified interruptions.
Noise reduction works as a stack: focused roles improve generation; evidence requirements improve explainability; confidence and schema filters remove weak output; aggregation removes duplication; caps preserve attention; and dismissal reasons guide later tuning. No layer is perfect. Together they let an AI reviewer say less, which is usually the first step toward making the things it does say worth reading.
PR Quorum turns specialist reviewer output into one clean GitHub review, with noise controls and predictable usage caps.