Using AI in code review without lowering the bar

As a team lead, a big part of my week is code review for a team of seven-plus engineers. AI in code review is now part of that loop, and it is genuinely useful. It is also the easiest way I know to let standards slide without anyone deciding they should. A pull request that has "already been reviewed by the bot" gets approved faster, and faster approval is exactly where bugs sneak through.

This is how I think about using AI review tools while keeping the bar where it was.

What an AI reviewer is good at

An AI reviewer is a tireless first pass. It reads every line, it never gets bored on file 14 of a large diff, and it is good at the mechanical layer of review:

• Spotting unhandled promise rejections, missing await, and swallowed errors.
• Flagging inconsistent naming, dead code, and leftover debug logging.
• Noticing an obvious null path or an unchecked array index.
• Pointing out where a function grew too long or duplicated logic that already exists two files over.
• Summarising a large diff so the human reviewer knows where to look first.

That last point is underrated. A short, accurate summary of what changed lets me spend my attention on the risky parts instead of reconstructing intent from scratch.

What it cannot judge

The things that make review valuable are mostly outside what a model can see in a diff.

Intent. The model does not know what the feature was supposed to do. It can tell you the code is internally consistent. It cannot tell you the code solves the wrong problem. This is why my team writes the spec first; with Spec-Driven Development, the reviewer checks the change against an agreed document, and that comparison is the part I keep human.

System context. A diff shows the lines that changed. It hides the cron job that also writes to this table, the mobile client still on the old response shape, and the migration that will lock a large table during peak hours. An experienced reviewer carries that context. A model reviewing a diff mostly does not.

Tradeoffs. Should this be a background job? Is this cache worth the invalidation pain? Is this the moment to pay down the debt or ship and come back? These are judgement calls tied to the business, and I want a person making them.

Security and data handling. A model will catch some injection patterns. I still want a human looking at anything touching auth, permissions, payments, or personal data, because the cost of a miss there is far higher than the cost of a slow review.

How I set it up on a team

The rule I use: the AI review runs first and its comments are suggestions. A human approval is still required, and that human owns the merge.

A few practices make this hold up:

1. The author resolves bot comments before requesting human review. Either fix it or reply with why it does not apply. This keeps the human reviewer from wading through noise.
2. Bot comments never count as approval. The branch protection rule requires a person. No exceptions for "small" changes, because small changes are where people stop looking.
3. Feed it your conventions. Generic advice produces generic comments. My team's conventions are served to AI coding agents from a conventions server (an MCP server), grouped by platform: backend, frontend, Flutter, integrations and shared. It covers spec-first development, branch-per-spec naming, the PR workflow and comment style. An agent that reads those rules before it writes or reviews code produces comments about our standards instead of generic style advice. I wrote more about that in making team conventions machine-readable for AI agents.
4. Track what it misses. When a bug reaches production, check whether the AI review saw the relevant lines and what it said. That tells you where its blind spots are on your codebase specifically.

Keeping the human review honest

The real risk is reviewer complacency. When a tool has already left ten comments, the human feels like the review is done. To counter that, I ask reviewers to answer a few questions the bot cannot:

• Does this change do what the spec says, including the edge cases listed there?
• What else in the system touches this data or this endpoint?
• What happens when this fails halfway? Is anything left in a broken state?
• Would I be comfortable being paged for this at 3am?

If a reviewer cannot answer those, the PR is not reviewed yet, regardless of how many automated comments it has.

AI-written code needs more review, with a different focus

More and more of the code in a pull request was drafted by an AI assistant. That changes what I look for. Generated code tends to be plausible and tidy, which makes it easy to skim. The failure modes are different from a tired human's:

• It invents helpers or config keys that do not exist in the repo.
• It handles the happy path well and quietly ignores the error path.
• It writes tests that pass because they assert whatever the code currently does.

That last one deserves its own checklist, which I covered in reviewing AI-generated tests. The short version: generated code gets the same approval requirement as hand-written code, and the reviewer reads it line by line instead of trusting the shape.

A simple review split

Here is the division of labour I default to:

• CI: formatting, lint, type checks.
• AI reviewer: mechanical bugs, obvious smells, a summary of the diff.
• Human reviewer: matches the spec, edge cases, failure modes.
• Senior human reviewer: architecture, data model changes, security-sensitive paths.

Every layer still runs. The AI layer makes the human layers faster because the reviewer starts with the noise already cleared.

The short version

Use AI in code review as a fast, thorough first pass and keep the approval human. Give the model your conventions so its comments are specific, make authors resolve bot comments before a person looks, and ask reviewers questions only they can answer. The bar stays where it is, and reviewers spend their time on the parts that actually need a senior engineer.