How to Use AI for Code Review (Without Trusting It Blindly)

AI is decent at code review. It's also confidently wrong about half the time on subtle stuff. Most teams pick one of two bad options: rubber-stamp whatever the bot says, or refuse to use it at all because someone got burned once.

The right move sits in between, and it depends on knowing exactly what an LLM is good at on a diff and what it cannot do reliably no matter how much you prompt it.

What AI is actually good at

If you point Claude, ChatGPT, or a tool like CodeRabbit at a pull request, here's what you'll consistently get value from:

• Style consistency. Naming, indentation, lint-level stuff. Fast, accurate, and the kind of feedback humans hate giving.
• - Missing null checks and unhandled error paths. LLMs are good at scanning every branch and asking "what if this is undefined."
• - Duplicated logic across files you forgot existed.
• - Typos in variable names that compile but break at runtime (Python, JavaScript, anywhere there's no strong typing).
• - Better names for badly named things. Bots have no ego about this.
• - The docstring or commit message you were about to skip.

That's the boring 60% of code review. Letting AI handle it frees humans for the parts that actually need judgment.

What it's bad at

This is the part that gets people in trouble. Three categories where an LLM will mislead you:

Security. It will catch obvious SQL injection in a textbook example. It will miss a real exploit hiding behind two helper functions and a config flag. Worse, it will tell you the code is fine in a confident paragraph that reads like a senior engineer wrote it. Treat any "this code looks secure" output as worthless until a human with security context confirms it.

Performance at scale. AI can spot an N+1 query if the loop and the query are in the same function. It cannot see that your innocent-looking method gets called 10,000 times per request from somewhere three files away. That kind of finding requires execution traces, profilers, or production knowledge. The bot has none of those.

Architectural intent. If you're refactoring toward a new pattern and a reviewer needs to evaluate whether the change moves you in the right direction, AI is useless. It doesn't know your roadmap. It will happily suggest "improvements" that undo the change you just spent two weeks making.

The workflow that works

I run AI on every PR before a human looks at it. Not after. The order matters.

• Open the PR and run AI review first. CodeRabbit and Greptile both do this automatically as a GitHub bot; Claude works fine if you paste the diff into a chat and tell it the language and framework.
• - Triage the AI comments yourself. Roughly half are noise. Resolve those before a human sees them so they don't waste a reviewer's attention.
• - Apply the genuinely useful suggestions yourself, in the same commit. Don't let the AI commit directly. If it can't be bothered to commit, you have a human author on every line.
• - Now request human review. The reviewer is looking at a cleaner diff and can focus on logic, design, and edge cases instead of pointing out a missing semicolon.

This routine cuts my reviewer turnaround by something like a day on a busy week, mostly because reviewers stop being annoyed.

Tools worth using

A short list of what I actually use and why:

CodeRabbit. The most thorough automated reviewer right now. Aggressive on style and dead code, decent at catching small bugs. Costs money for private repos but the free tier on open source is unlimited.

Greptile. Better at understanding cross-file context than CodeRabbit. If your codebase is sprawling, Greptile finds things its competitor misses. Less polished UI.

Claude or ChatGPT in chat. Underrated workflow: copy your diff, paste it, ask "what's broken here and what would a senior engineer flag." Faster than waiting for a bot, and the model can answer follow-up questions about why.

GitHub Copilot's built-in PR review. Convenient because it's in the same window. Quality is a step below the specialized tools, but the friction is zero.

Whatever you pick, don't run two of them on the same PR. The overlap is irritating and the marginal catch rate doesn't justify reading the same comment twice.

The line you don't cross

Never merge code on the strength of an AI review alone. Not for security-adjacent changes, not for production database migrations, not for anything touching auth, billing, or data deletion. The bot is a second pair of eyes, not the only pair. Treat its output the way you'd treat advice from a smart junior engineer who has never seen your codebase before, because functionally that is what it is.

The teams I've seen burned by AI code review are always the ones who started letting it auto-approve PRs. The teams that get the productivity win are the ones who keep a human in the loop and use AI to make that human's job less tedious.

Next up: how to write the kind of PR description that gets reviewed faster, with or without a bot doing the first pass.