Using AI to review code and catch bugs — without drowning in false positives
An LLM will find real bugs a tired human skims past. Left untuned, it also buries them under fifty nitpicks and a few confident-but-wrong "issues." AI code review is genuinely valuable, but only if you engineer for signal. Volume is easy; signal is the skill. Here's how to get a review pass actually worth reading.
Where AI review shines, and where it's noise
Shines: subtle logic bugs, missed edge cases, off-by-ones, unhandled error paths, "you forgot to update the other call site," security smells, and consistency issues across files. The semantic stuff humans miss at the end of a long day.
Noise: style nitpicks, "consider extracting a helper," reformatting opinions, and false-positive "bugs" that aren't bugs. And the dangerous one: confidently-wrong findings, stated with the same authority as the real ones.
The job is to amplify the first list and suppress the second.
How to get signal
Scope it to the diff. Review the change, not the whole repo, and give it the context: what changed and why. An unscoped "review this codebase" produces unscoped noise.
Tell it the bar, concretely. This is the biggest lever. Vague instructions get vague output. Be explicit:
"Report bugs that could cause incorrect behavior, a test failure, a security issue, or data loss. Ignore style, naming, and formatting. For each finding, give a confidence level and a severity."
Naming the bar in concrete terms ("incorrect behavior, test failure, security, data loss") beats qualitative words like "important," which the model interprets however it likes.
Split finding from filtering. The counterintuitive trick that works: tell the model its job at the finding stage is coverage, not judgment: report everything, including low-confidence items, with confidence and severity attached. Then filter and rank in a separate step (a second pass, or a human). When you ask one pass to both find and self-censor, modern models follow the "only report important issues" instruction so faithfully that they drop real bugs. Moving the filter downstream improves recall and precision at once.
Don't ask the reviewer to find bugs and decide which ones matter in the same breath. Find broadly, filter separately. One job per pass.
Treat every finding as a hypothesis. The model can be confidently wrong, so a finding is a lead, not a verdict. A claimed bug you can't reproduce or trace is something to investigate, not to action blindly. This is the same verify-don't-trust discipline that runs through all agentic work.
Pair it with deterministic tools. Linters and SAST catch the mechanical and known-pattern issues cheaply and correctly. Use those for what they're good at, and spend the LLM on the semantic bugs they structurally can't see. Belt and suspenders, each doing its job.
The workflow that works
Use AI review as a pre-human pass: it surfaces candidate issues with confidence/severity; a human (or a second AI pass tuned for filtering) confirms and prioritizes. It's a force multiplier for the human review, making sure it starts from "here are 6 things worth looking at" instead of a blank diff.
For the model, this is a reach for a strong one: bug-finding is exactly the kind of careful reasoning where Sonnet or Opus earns its tokens over a cheap model.
The security angle
AI review can flag injection risks, hardcoded secrets, missing authorization checks, and unsafe deserialization. That's real value, but don't make it your only gate: it has false negatives, and a confident "looks secure" is not a security guarantee. Use it to widen the net, keep deterministic scanners and human judgment in the loop, and remember that if the code came from an agent, the agent's own sandbox and review discipline matter just as much as reviewing its output.
Tuned this way (scoped, with a concrete bar, finding split from filtering, findings verified), AI review is a second reviewer that never gets tired, the one that catches the bug you would have shipped.