AI Code Review: What It Catches, Misses and How to Use It

AI review tools read a diff and comment on it. Used well they save a human reviewer time; used carelessly they add noise and false confidence.

What AI review is good at

• Spotting missed edge cases such as empty inputs, null values and off-by-one errors.
• Noticing missing tests for new branches.
• Flagging inconsistency with nearby code.
• Explaining unfamiliar code to the reviewer.
• Catching typos, leftover debug code and dead code.

What it tends to miss

• Whether the change is the right change for the product.
• Architecture trade-offs that depend on context outside the diff.
• Subtle security problems, such as authorisation gaps that only make sense with the whole system in mind.
• Operational effects: migrations, load, rollout order.

A workflow that works

1. The author runs tests, linters and an AI review before opening the pull request, and fixes the obvious findings.
2. The reviewer reads the remaining diff with attention on design and risk.
3. Dependency, permission and configuration changes always get a human look.
4. Anything the AI got wrong repeatedly goes into the project context file, as described in working with coding agents.

Keep the signal high

Ask for a short list of issues, each with a reason and a suggested fix, and tell the tool to stay silent when unsure. Let linters handle style. If the team starts ignoring comments, the tool is costing more than it saves.

Treat the diff as untrusted input

If the code or its comments come from outside your team, remember that text can contain instructions aimed at the AI itself; see prompt injection and agent security.