AI code review: using AI reviewers and reviewing AI code

What AI reviewers catch well

Model-based reviewers are good at problems visible inside the diff and its immediate surroundings. The reliable catches are:

• Local logic errors: inverted conditions, off-by-one loops, wrong variable used after a copy-paste, unhandled null or empty cases.
• Error handling gaps: swallowed exceptions, missing timeouts on network calls, promises or futures that are never awaited.
• Obvious security smells: string-built SQL, unsanitized input reaching a shell or template, secrets in code, overly permissive CORS.
• Resource leaks: files, connections or transactions that aren’t closed on every path.
• Mismatches between code and its description: the PR says it adds pagination, the code doesn’t bound the query.
• Missing tests for new branches, and tests that don’t assert anything meaningful.
• Consistency issues: naming, dead code, duplicated helpers, outdated comments.

That’s valuable. A first pass that removes these before a human looks means the human can spend their attention on the things only they can judge.

What AI reviewers miss

• Intent. Whether the change should exist at all, or solves the right problem. That needs product context the reviewer doesn’t have.
• Cross-system effects. A renamed field that breaks a consumer in another repository, an event schema change, a cache key that another service relies on.
• Your authorization model. A reviewer can spot a missing check if the pattern is obvious. It usually can’t tell that this endpoint needs an organization-level permission rather than a user-level one.
• Operational risk. A migration that adds an index without CONCURRENTLY on a 200-million-row Postgres table and locks writes. A backfill that will run for six hours inside a deploy.
• Concurrency and ordering. Race conditions between workers, non-idempotent webhook handlers, read-modify-write without a lock.
• Performance at real scale. N+1 queries are sometimes caught; a query plan that flips once a table grows is not.
• Architecture drift. Code that works but puts logic in the wrong layer, adds a second way of doing something the codebase already does, or quietly couples two modules.

AI reviewers also produce false positives and confidently wrong suggestions. If half the comments are noise, engineers stop reading them, and the true positives get ignored with the rest. Tuning matters more than tool choice.

Choosing a tool: Cursor code review and the alternatives

The main options are reviewers built into the editor-agent tools – Cursor’s code review agent (Bugbot), Claude Code’s review commands and GitHub integration – plus GitHub Copilot’s pull request review and dedicated review products such as CodeRabbit. Features, pricing and models change often, so check each vendor’s current docs rather than a comparison post.

What to evaluate is more stable than which tool wins this month:

• Context: does it see only the diff, or the whole repository, related files and your conventions?
• Configurability: can you give it review rules in a file in the repo, and tell it what to ignore?
• Signal-to-noise: run it on 20 to 30 recent merged PRs where you know the bugs that slipped through. Count real findings against noise.
• Data handling: where your code is sent, whether it is retained, and whether it can be used for training under your plan.
• Workflow fit: comments inline on the PR, severity levels, and the ability to resolve or dismiss with a reason.

Reviewing AI-generated code is a different job

AI generated code review needs a slightly different mindset from reviewing a colleague’s work. Human mistakes tend to look like mistakes. AI mistakes look plausible: well-formatted, confidently named, with a tidy docstring. The surface signals reviewers rely on are no longer reliable. Things to look for specifically:

• Invented APIs and packages. Methods that don’t exist on the library version you use, configuration options that were never real, or package names that are close to a real one. Check every new dependency by hand.
• Reimplementation instead of reuse. A new date helper, a new HTTP client wrapper, a new permission check – when the codebase already has one. This is the main source of long-term rot.
• Tests that test the implementation. Mocks of everything, assertions that the mock was called, or expected values copied from the code’s own output. These pass forever and protect nothing.
• Weakened tests. An agent asked to make CI green may loosen an assertion, add a skip, or widen a timeout. Read test diffs as carefully as code diffs.
• Over-broad error handling. Catch-all blocks that log and continue, hiding the failure the code was meant to surface.
• Scope creep. Unrelated refactors bundled into the change, which hide the real diff.
• Insecure defaults. Disabled TLS verification “for testing”, permissive CORS, debug flags, wide database grants.

The most effective control is size. A 1,500-line AI-written PR will not be reviewed properly by anyone. Ask for small, single-purpose changes, the same as you would from a person.

What happens to AI generated code quality over time

The individual PR is rarely the problem. The trend is. Analyses of large code corpora, including GitClear’s research, have reported more duplicated and copy-pasted code and less refactoring of existing code as AI assistants have spread. The mechanism is easy to see: each change is locally reasonable, and the system as a whole gets harder to change.

Watch it with a few cheap signals: duplication reports from your static analysis, the share of PRs that touch shared modules versus adding new ones, change failure rate, and how often recently merged code is rewritten within a few weeks. If those trend the wrong way, the fix is usually review standards and conventions files, not banning the tools. More on the underlying cost in what is technical debt.

A team policy template for AI code review

Adapt this to your team. Keep it to one page and put it in the repository next to your contribution guidelines:

1. The author owns the change, however it was written. If you can’t explain a line in review, it doesn’t merge. Labeling AI-written code is optional; understanding it isn’t.
2. AI review runs first, on every PR. Authors address or dismiss each comment with a short reason before requesting human review.
3. At least one human approval is required to merge. An AI approval never counts toward it, and nothing auto-merges on an AI reviewer’s say-so.
4. Sensitive paths need a named owner. Auth, payments, migrations, infrastructure and data access go through CODEOWNERS with senior reviewers.
5. PRs stay small. A soft limit (for example, 400 changed lines excluding generated files) applies to AI-written changes too.
6. New dependencies are checked by a human for existence, maintenance and license.
7. Test changes get reviewed as hard as code changes. Loosened assertions and new skips need a stated reason.
8. Review rules live in the repo. A rules file tells the AI reviewer your conventions and what to ignore; update it when it’s noisy.
9. We measure and revisit monthly: useful-comment rate, escaped defects, review time and change failure rate.

Rolling it out without drowning the team

Start the AI reviewer in comment-only mode on one repository. For two weeks, have reviewers tag each AI comment as useful or noise. Use that to write the rules file – the categories it gets wrong, the directories to skip, the patterns your codebase uses on purpose. Then expand. If after tuning the useful-comment rate is still low, switch tools or turn it off; a reviewer that people ignore is worse than none.

AI review works best as part of a wider rollout of AI tools with shared conventions and honest measurement – covered in the guide to AI coding assistants for teams. If you’re worried that code already merged has quality or security problems, an independent code audit is the quickest way to find out. And if what you really need is a senior engineer setting review standards and holding them, that’s what I do as an embedded engineering lead.

Related

• Claude Code for teams: rolling out AI coding assistants properly
• Is vibe coding bad? Where it works, where it breaks
• A code audit that tells you what you’ve actually got
• An engineering lead for hire, embedded in your team
• What is technical debt? A practitioner’s definition
• DORA metrics for small teams: what to measure and how