AI for code review: what it catches and misses

Code review is one of the most natural homes for a language model. The input is text, the task is reading carefully, and the bar set by tired human reviewers at the end of a long day is not impossibly high. Drop a model on a pull request and it will produce comments that look exactly like the ones a thoughtful engineer would leave. The question is not whether AI review feels useful — it does — but whether it catches the things that matter and whether the comments it leaves are worth the time spent reading them. This piece walks through what AI review reliably catches, where it quietly fails, and how to fit it into a real workflow.

What an AI reviewer actually catches

The strongest area for AI review is the local, mechanical layer that humans find boring and therefore skim. Off-by-one errors, unhandled null cases, swapped arguments, missing error handling on a call that can fail, a loop that does not close a resource, a typo in a variable name that the compiler will not catch — these are squarely in range. A model reads every line with the same patience on comment two hundred as on comment one, which is exactly where human attention fades.

It is also good at surface consistency: naming that does not match the surrounding code, a function that does one thing in two different ways, a comment that no longer matches the code beneath it. These are real improvements, and they arrive faster and more uniformly than human reviewers deliver them.

Where it quietly fails

The failures are more interesting than the successes because they are not obvious from the output. The most important one is architectural judgment. An AI reviewer reads the diff, not the system. It does not know that this module is being deprecated next quarter, that this pattern was chosen deliberately to match an external constraint, or that the "clever" simplification it suggests would break an assumption three files away. It evaluates the change in front of it, and a great deal of real review is about whether the change should exist at all.

The second quiet failure is intent. A reviewer who understands what the code is supposed to do can spot when it does something subtly different. A model can only infer intent from the code and the description, so a change that is internally consistent but solves the wrong problem will sail through. The code is correct; it is correct about the wrong thing.

The confident-but-wrong comment

The failure mode that erodes trust fastest is the confidently incorrect comment. A model will flag a "bug" that is not one, suggest a "fix" that introduces a real bug, or insist a perfectly safe pattern is dangerous. Each of these reads exactly as authoritative as a correct comment, because fluency is not correlated with accuracy. A junior engineer who trusts the tool may dutifully "fix" working code; a senior one learns to discount the tool, which slowly turns its correct comments into noise too.

The practical defense is framing. Treat AI comments as suggestions to evaluate, never as verdicts to obey. The author stays responsible for the code. A comment the author can dismiss in two seconds is cheap; a comment that triggers an unnecessary change is expensive. Tuning the tool toward fewer, higher-confidence comments usually beats tuning it toward catching everything.

The signal-to-noise problem

The single biggest determinant of whether AI review survives in a team is volume. A reviewer that leaves forty comments on a pull request, most of them trivial style notes, trains everyone to collapse the whole thread unread — including the two comments that mattered. Noise does not just waste time; it actively hides signal. The instinct to "catch more" is the instinct that kills the tool.

The teams that succeed are ruthless about scope. They point the AI reviewer at the categories where it is strong and reliable — correctness, error handling, obvious security mistakes — and explicitly suppress the categories where it is noisy or where an existing tool already does the job better. A linter catches formatting; an AI reviewer commenting on formatting is just a slower, less predictable linter.

What it does to the human reviewer

There is a subtler effect worth naming: an AI reviewer changes what humans pay attention to. If everyone assumes the model caught the mechanical bugs, human reviewers drift toward higher-level concerns — design, intent, fit. That is mostly good, because that is exactly where humans add the most value and the model adds the least. But it depends on the model actually catching the mechanical layer reliably, and on people not over-trusting it. The risk is a gap where the human assumes the AI checked and the AI's check was shallow.

This is the same lesson that risk frameworks such as the NIST AI Risk Management Framework keep returning to: be explicit about what each part of the system is responsible for, and match the level of human oversight to the consequences of being wrong. A typo slipping through is cheap; a flawed authorization change slipping through because everyone assumed it was covered is not.

How to use it well

The deployments that work treat AI review as a first pass, not the review. It runs before a human looks, clears out the mechanical issues, and hands the human a cleaner diff to think about. It is scoped to its strengths, tuned for few high-confidence comments, and framed so authors feel free to dismiss it. Nobody merges on the strength of an AI approval alone, and nobody treats an AI comment as the last word.

Crucially, the human review does not go away. The model handles the layer that benefits from tireless attention; the human handles the layer that benefits from understanding the system, the intent, and the trade-offs. Used that way, the two are complementary rather than redundant. Used as a replacement for human judgment, AI review quietly lowers the bar while appearing to raise it.

The takeaway

AI code review is genuinely useful at the local, mechanical layer — null checks, error handling, obvious mistakes — and genuinely weak at architecture, intent, and knowing whether a change should exist at all. Its most dangerous output is the confident, wrong comment, and its most common failure is drowning real signal in trivial noise. Scope it to its strengths, tune it for few high-confidence comments, frame it as a suggestion rather than a verdict, and keep human review for the judgment the model cannot supply. Do that, and it makes reviews faster and catches things tired humans miss. Skip it, and you will spend more time arguing with the tool than it ever saves.