What Is AI Code Review and How Does It Work?

AI code review is an automated pass over a pull request by a language model that comments on the code the way a human reviewer would. It reads the change, plus however much of the surrounding repository the tool can see, then flags bugs, convention breaks, and risks before a person opens the diff.

How much of the repository it can see is the variable. It decides what the tool is capable of finding, and it is the thing to compare when you evaluate one.

How it works

Four stages, and every tool worth using runs all four.

1. Trigger. A webhook fires when a pull request opens or receives new commits. Nothing runs on a schedule.
2. Context. The tool pulls the diff. Depending on the product it also retrieves related files: the modules the change imports, the conventions it derived at onboarding, sometimes the linked ticket.
3. Reasoning. A model reads the change against that context and produces candidate findings, usually with a confidence score attached to each one.
4. Filtering and posting. Weak findings are dropped and the rest go up as inline comments plus a summary on the pull request.

Stage 2 is where products diverge, and stage 4 is where they earn or lose the team's attention. A tool that skips the filtering step posts everything it thought of, which is how review bots end up muted.

What it catches

Mechanical defects, applied uniformly to every diff: a missing null guard, a retry loop with no backoff, an error swallowed instead of handled, an endpoint that skips the permission check every other endpoint in the module performs.

The strongest category is convention drift. Code that compiles, passes tests, and quietly solves a problem differently from the way the rest of the repo solves it.

That kind of finding is why AI review sits alongside linters rather than replacing them. A linter enforces rules someone wrote down. An AI reviewer works from conventions nobody ever documented, which is most of them.

What it doesn't

It does not decide whether the feature should have been built, whether this quarter's deadline justifies the shortcut, or whether the team can maintain the abstraction after its author leaves.

Those depend on context that lives in people, not in the repository, so a bigger model does not move them. We covered that boundary in Is AI Code Review the New Standard, or Just Hype?

Diff-based and repo-aware

A diff-based reviewer reads the files a pull request touches. Fast, cheap, no setup. Anything outside the diff does not exist to it.

A repo-aware reviewer reads the change against the shared helpers, the internal frameworks, and the decisions already made elsewhere, so it can ask whether a change fits the system it is joining instead of only whether it is valid alone.

The gap shows up in specific places: an abstraction reimplemented three services over, a new endpoint that bypasses the shared authorization middleware, a query that skips the index every comparable query uses. Worked examples are in Repo-Aware AI Code Review vs. Diff-Based Review.

How to evaluate one

Feature tables are useless here, because every vendor claims the same things. Three questions cut through:

1. What is your signal rate? Of the comments it posts, what share does a team act on? A vendor without this number has not measured it. Ours is 70% across 216 comments on 200 pull requests.
2. How much context do I get on my plan? Repository awareness is often gated behind the top tier, so the demo and the plan you buy can behave differently.
3. What happens after merge? A tool that scans once at onboarding reviews against the standard your repo had on setup day. Ask how its rules update.

Then run it against a pull request you already reviewed. Did it find what you found, and did it invent anything? We ran that comparison against the category leader in Revix vs CodeRabbit.

Revix is the repo-aware kind. Connect a repo and read the first review: userevix.com. Every team starts with a 14 day free trial, no card required.