AI in Code Review: A Pre-Screen, Not an Approver

TL;DR: Code review has always been two jobs wearing one name: a mechanical job (does this code have bugs, does it follow our conventions, is anything obviously unsafe) and a judgment job (should this change exist, does it fit the system, what does it cost us later). AI is genuinely good at the first job and structurally bad at the second. The teams getting value run AI as a pre-screen that fires before a human ever opens the PR, clearing the mechanical layer so human attention lands on design and intent, while approval, and accountability for it, stays human. This guide covers what AI review catches, what it misses, how to wire it in, and how to stop reviewers from outsourcing their reading to the bot.

Part of the AI for Engineering hub. If AI is also writing your code, read this alongside the coding assistants rollout guide, rising code volume is exactly what makes review the control point.

Why review is where the pressure lands

When a team adopts coding assistants, output rises. PRs get bigger, more frequent, or both. Review capacity doesn’t rise with it, so one of two things happens: review becomes the bottleneck, or review becomes a rubber stamp. Both are bad; the second is worse, because it’s silent.

AI review tooling is the honest response to that pressure, not because it replaces reviewers, but because it triages what reaches them. A large language model reading a diff with codebase context can clear (or flag) the mechanical layer in seconds, every time, at 5 p.m. on a Friday, with no ego and no fatigue. That consistency, more than any individual catch, is the value.

What AI review reliably catches

Tools in this category, GitHub Copilot’s PR review, purpose-built reviewers, or a general assistant like Claude or ChatGPT given the diff and context, perform well on:

That last row is underrated. An AI-written summary of a 900-line diff, what changed, what’s risky, where to look first, measurably improves the human review that follows, because the reviewer starts oriented instead of archaeology-first.

What AI review misses, structurally, not temporarily

These aren’t gaps that the next model version fixes; they follow from what a reviewer-bot can’t know:

• Whether the change should exist. The model sees a diff, not a roadmap. A beautifully implemented feature that duplicates an existing capability, contradicts a deprecation plan, or solves the wrong problem sails through.
• Architectural fit. “This works, but it puts business logic in the wrong layer and the next three features will copy it” is the highest-value review comment there is, and it requires knowing where the system is going.
• Context that lives outside the repo. The incident three months ago that makes this code path sensitive. The customer commitment that makes this default dangerous. The team norm that this module is being strangled, not extended.
• Intent mismatches. Code that correctly implements the wrong interpretation of the ticket. Tests pass; the product is wrong.
• Novel security issues. AI catches the OWASP-catalog patterns; it does not model your threat model, trust boundaries, or the clever interaction between two individually-safe changes.

And one active failure mode rather than a blind spot: hallucinated findings. AI reviewers sometimes flag “bugs” that aren’t, misreading a framework’s semantics, inventing a constraint, with the same confident tone as real findings. Untriaged, these erode trust in the tool; worse, developers “fix” non-bugs and introduce real ones.

How to wire it in: the pre-screen pattern

1. Run AI review automatically on PR open, before human review is requested. The output is a comment thread, not an approval. Authors fix or rebut the mechanical findings first, so humans review a cleaner diff.
2. Scope the bot deliberately. Configure or prompt it toward the mechanical categories above and away from subjective design opinions. A bot that comments on everything trains people to read nothing.
3. Make it advisory, with two exceptions. Leaked secrets and known-vulnerable dependencies can hard-block, those are objective. Everything else is a comment a human can dismiss with a reason. Ritual overrides of a blocking bot are worse than no bot.
4. Keep human approval mandatory and named. The person who approves owns the merge, exactly as before. The bot’s findings inform that judgment; they never substitute for it. “The AI reviewed it” appears in no acceptable postmortem.
5. Feed it context, not just the diff. Review quality tracks context quality: the linked ticket, the module’s conventions, your review checklist. Teams using a general assistant get big gains from a standing prompt that encodes house rules.

A working prompt pattern for teams doing this with a general-purpose assistant rather than a dedicated tool:

You are pre-screening a pull request before human review. Here is the diff: [diff]. Here is the ticket it implements: [ticket]. Here are our conventions: [error handling example, naming rules, test requirements]. Report, in order: (1) probable bugs, each with the line and why you believe it’s wrong; (2) changed logic that lacks test changes; (3) deviations from the conventions above; (4) security concerns. For each finding, state your confidence as high/medium/low. Do not comment on style covered by our linter. Do not suggest architectural changes. If you find nothing in a category, say so, do not pad.

The confidence labels and the “do not pad” instruction do real work: they make hallucinated findings visibly low-confidence and stop the bot from manufacturing feedback to seem useful.

The complacency problem

The documented failure mode of any inspection automation applies here: humans downgrade their own vigilance when a machine checks first. Three countermeasures that work:

• Divide the labor explicitly. Team norm: the bot owns mechanical findings; humans are required to comment on design, intent, and fit, a human review consisting only of “LGTM, bot passed” is an incomplete review.
• Audit merged PRs monthly. Sample five or ten, re-review cold, and log what both the bot and the human missed. This calibrates trust in the tool with data instead of vibes and keeps reviewers honest.
• Track escaped defects by origin. When a bug ships, note whether the introducing PR had AI review, what the bot said, and what the human said. Six months of this tells you exactly what your pre-screen is and isn’t catching.

Reviewing AI-written code: same gate, sharper eyes

When the diff itself was largely AI-generated (see the coding assistants guide), review needs two adjustments. First, calibrate for the failure signature: AI code fails plausibly, correct-looking API usage that’s subtly wrong, edge cases handled generically rather than for your domain, and confident comments describing what the code should do rather than what it does. Reviewers used to human failure patterns (laziness, shortcuts, TODO debt) need to retune for competence-shaped errors. Second, insist the human author can explain the change. The author is the first reviewer; an author who can’t walk the diff hasn’t authored it, and the review burden silently doubles.

A 30-day pilot

1. Week 0: pick one repo with steady PR flow. Baseline: review turnaround, comments per PR, escaped defects.
2. Weeks 1-2: enable AI pre-screen, advisory-only. Authors triage bot findings before requesting review. Log false positives in a shared doc.
3. Weeks 3-4: tune scope based on the false-positive log. Add the two hard blocks (secrets, vulnerable deps) if trust is holding.
4. Day 30: compare. Success looks like faster human turnaround, human comments shifting toward design/intent, and no rise in escaped defects. Failure looks like LGTM-culture, if human comment depth dropped, fix the norms before expanding.

FAQ

Can AI replace human code review? No. It reliably handles the mechanical layer, bug patterns, conventions, coverage gaps, and structurally cannot judge whether a change fits the architecture, the roadmap, or the intent behind the ticket. Approval stays human and named.

What does AI code review actually catch? Common bug patterns, inconsistencies with surrounding code, missing tests for changed logic, style drift, and well-known security smells, consistently, which is the point. It never reviews tired.

Does AI review make human reviewers lazy? It can; automation complacency is the main risk. Scope the bot to mechanical findings, require human comments on design and intent, and audit merged PRs monthly for what both missed.

Should the AI reviewer be able to block a merge? Only on objective findings like leaked secrets or known-vulnerable dependencies. Judgment-call blocks get ritually overridden, which teaches the team to ignore the tool entirely.

Related: rolling out AI coding assistants covers the write side of this loop, and the AI for Engineering hub maps the rest of the cluster.

Curious where review fits in your team’s AI sequence? The free AI readiness assessment gives you a prioritized answer in ten minutes.