How AI code review works, and what it still misses

How AI code review works on a pull request

Every AI reviewer follows roughly the same pipeline. The differences between tools come from how much context they read and how strictly they check their own findings.

1. Trigger. A pull request is opened or updated, or someone asks for a review in a comment.
2. Context. The reviewer reads the diff, the files it touches and the code that calls them, plus the rules your team keeps in files such as REVIEW.md and AGENTS.md.
3. Candidate findings. The model lists what might be wrong: logic errors, missed edge cases, security issues, broken contracts with callers, rule violations.
4. Verification. Better reviewers check each candidate against the code before posting it. HeyDeer has a different model check every potential issue and posts only the ones that hold up.
5. Output. Inline comments on the affected lines, a summary, and often a status check that can gate merging. Some tools also open a fix.

The verification step is where most of the difference in quality comes from. Without it, a reviewer reports every suspicion. With it, the reviewer reports what it can support from the code, which is how HeyDeer reaches 99.0% precision on ReviewBench.

A worked example: one finding, start to finish

In our benchmark, one coding agent added a per-website list of excluded IP addresses to an open-source analytics app, so teams could stop counting their own office or VPN traffic. HeyDeer’s review posted this comment on line 37 of src/app/api/websites/[websiteId]/route.ts:

• Finding: Keep excluded IP addresses out of public sharing responses.
• Severity: Medium. Nothing crashes, but private network details leak to people who shouldn’t see them.
• Evidence: /api/share/[slug] issues a share token, canViewSharedWebsite() accepts it, and this endpoint returns the whole website object. Because getWebsite() reads every field, the new excludedIps column goes out to anyone with a public dashboard link.
• Suggested fix: Omit excludedIps from share-authorized responses and update the response schema to match.

Each part is checkable. The evidence names the exact call chain, so a reviewer can open three functions and confirm the leak in a couple of minutes, and the fix is small enough to verify with one test that requests the endpoint with a share token. A comment that only said “this might expose sensitive data” would leave all of that work to the reader.

What AI code review catches

AI review is strongest on problems that can be checked against the code itself. In our own benchmark, where eight coding agents built the same two features, the issues reviewers found were concrete behavior bugs: a saved IP range that never excluded anyone, a share link that exposed excluded office IPs, a network error that told visitors their link had expired.

• Unhandled errors and missed edge cases, such as empty input or a failed request.
• Security gaps, such as a query missing a permission filter or a secret in a URL.
• Changes that break an unchanged caller elsewhere in the codebase.
• Values computed but never used, and conditions that can never be true.
• Violations of rules your team wrote down, such as “store money as integer cents.”

That focus matches a long-standing gap in human review. Microsoft Research’s study of code review found that finding defects was developers’ top motivation, yet only 14% of review comments were about defects; most were about improving the code. AI review can take the defect-hunting pass so people review the rest.

What AI code review still misses

The weak spots are predictable once you know where the answer lives. If it isn’t in the repository, the reviewer can’t check it.

• Product intent. Whether the feature is the right one, or behaves the way customers expect.
• Design direction. Whether an abstraction will hold as the product grows, or whether this is the right place for the change.
• Outside context. Agreements with other teams, production data shapes, incidents that explain why code looks the way it does.
• Some real bugs. No reviewer finds everything. HeyDeer’s recall on ReviewBench’s high-severity view is 51.4%: about half of the labeled issues.

Why false positives matter more with coding agents

A wrong review comment used to cost a person a minute to dismiss. Now coding agents act on review comments, and research has found they follow fix requests even when they can tell the request is wrong (Jaiswal et al., 2026). Each false positive turns into a change someone has to review, and the real bug can still ship in the noise.

Developers already feel this. In the 2025 Stack Overflow Developer Survey, 84% of developers use or plan to use AI tools, yet more distrust their accuracy (46%) than trust it (33%), and the most common frustration, named by 66%, is output that is “almost right, but not quite.” A reviewer that adds more “almost right” comments makes that worse.

So judge a reviewer on two numbers: precision, the share of its findings that are real, and recall, the share of real issues it finds. They pull against each other. A reviewer that reports everything finds more and is wrong more often. Our 6,132 review runs on our own pull requests showed how much the balance depends on the review process, not only the model.

Reviewing AI-generated code

AI coding tools are now standard. Google’s 2025 DORA research puts AI adoption among software professionals at 90%. The code they write needs the same review as any other code, and some evidence says it needs more.

Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities, and that newer, larger models were no more secure. A Stanford study found developers with an AI assistant wrote less secure code while being more likely to believe it was secure.

Frontier models aren’t exempt. In our benchmark of 16 pull requests written by eight coding agents, every agent shipped issues, and HeyDeer found 78% more of them than GitHub Copilot code review with the same number of false positives (method and data).

How to get the most out of AI code review

• Keep pull requests small. At Google the median change modifies 24 lines and the median review takes under four hours. Small changes are easier for people and models to review well.
• Write your rules down. Put review rules in REVIEW.md and project conventions in AGENTS.md, so the reviewer flags what your team actually cares about.
• Use an independent reviewer for agent-written code. A different model from the one that wrote the code can catch what that model missed. It exposes blind spots; it doesn’t guarantee them away.
• Treat comments as claims. Ask the reviewer, or your agent, to show the line that proves a finding before changing code.
• Measure on your own code. Run tools on the same recent pull requests and score useful findings, false positives and time spent. Our evaluation guide includes a worksheet.

Ready to choose a tool? See the best AI code review tools ranked by precision.

Sources

1. Stack Overflow Developer Survey 2025: AI
2. Google: 2025 DORA State of AI-assisted Software Development
3. Veracode: 2025 GenAI Code Security Report
4. Perry et al. (Stanford): Do Users Write More Insecure Code with AI Assistants?
5. Bacchelli & Bird (Microsoft Research): Expectations, Outcomes, and Challenges of Modern Code Review
6. Sadowski et al. (Google): Modern Code Review: A Case Study at Google
7. Jaiswal et al.: coding agents and incorrect review feedback
8. ReviewBench