The triage-nurse analogy
Hospitals run a triage nurse at the door. The nurse does not do surgery — they catch the obvious problems early so the surgeons spend their time on the hard cases. Most patients get help faster; a few are surprised to learn they need real attention.
AI code review is that triage nurse. It catches typos, off-by-ones, missing null checks, unused imports, security smells — the high-volume mechanical mistakes — and frees senior reviewers to focus on architecture, intent, and trade-offs.
What AI review is good at
- Mechanical bugs — off-by-ones, swapped arguments, unused variables, missing awaits, inverted booleans.
- Style consistency — naming conventions, import order, formatting drift the linter missed.
- Common security issues — SQL injection patterns, hardcoded secrets, unsafe deserialisation, missing CSRF on a write endpoint.
- Test coverage gaps — "this branch isn't covered" is mechanical and easy.
- Docs and comment drift — function docstring no longer matches the signature.
What AI review is bad at
- Architecture decisions. "Should this live in service or controller?" is judgement, not pattern-matching.
- Hidden assumptions. A function that seems fine but breaks because of a constraint nowhere in the diff.
- Code that looks reasonable but is wrong — confidently approving a subtle race condition that compiles and passes thin tests.
- Cross-PR context. Two PRs that conflict semantically but neither, alone, is wrong.
- Business correctness. The code does the wrong thing, correctly.
Three deployment patterns
1. PR comments (common)
Bot reviews every PR, leaves inline comments. Human reviewer sees the AI pass first, then adds their own. Easy to ship, easy to ignore.
2. Pre-commit / pre-push (lower friction)
AI runs locally before you push. Catches stuff before it reaches the team. Faster feedback, less noise on the PR.
3. Inline during edit (Cursor, Copilot)
The model is already in the editor; it can flag concerns as you type. Tightest feedback loop; harder to make depthful.
Designing the review prompt
A good system prompt for AI review tells it:
- What to check — bug categories, security, perf, your house style.
- What to ignore — formatting if you have a formatter, nits, opinion-only suggestions.
- How to comment — "be terse," "cite the line," "don't restate what the code does."
- When to refuse — "if you're uncertain, don't flag it." False positives are the silent killer.
The false-positive trap
A reviewer who flags everything is worse than no reviewer — engineers learn to ignore them. Track the false-positive rate and ruthlessly tune the prompt to drop signal that wastes time. A 30% false-positive rate is roughly the upper bound of "tolerable;" 10% is great.
Where it shines unexpectedly
- Onboarding new contributors. AI review surfaces conventions a newcomer wouldn't know.
- Big refactor PRs. Mechanical checks at scale catch the pieces a human reviewer fatigues on.
- Security-sensitive repos. A second pass on every diff for known patterns is cheap insurance.
- Test changes. "These two tests are now identical except for one assertion."
What does not work
- Treating AI review as the gate. It misses too many semantic bugs to be the only check.
- Letting it self-merge. A senior human still owns the merge button.
- Ignoring reviewer fatigue. Even a great AI reviewer at 100 comments per PR will be muted.
In one line
Use AI code review as a faster, cheaper first reviewer. The human reviewer still owns the architecture, the trade-offs, and the merge.