How does AI code review actually work?

Most of the work is not the model. The tool clones your repo, maps which files and functions touch your change, scans the git history, and runs 40-plus deterministic linters and scanners. Only at the end does a language model read that assembled case file and comment in plain English. The model is the last stage, not the reviewer.

What bugs can AI code review not catch?

Anything that looks fine on its own and is only wrong in context. Business-rule flaws, race conditions that need two things firing at once, and logic smeared across several services. The bot reads your code but does not run it, so bugs that live in the gap between the lines and an unwritten rule slip straight past it.

Is AI code review better than a human reviewer?

No, it is a different tool. AI is a fast, tireless first pass that catches dumb mistakes on every pull request in seconds. A human reasons about intent, business rules, and consequences, and can be held accountable for a bad merge. The strongest setup uses the bot to clear noise so humans spend attention where it counts.

Can GitHub Copilot code review block a bad merge?

Not on its own. Per GitHub's own docs, Copilot code review only leaves a Comment review, which does not count as an approval and cannot require changes. To make AI findings actually stop a merge, you wire up a separate required status check yourself. By default the bot only ever comments.

Why does AI code review flag bugs that are not real?

Language models are trained to always produce an answer, and saying "I am not sure" scores no points. So the model guesses, confidently, the way a student does on an exam they did not study for. In review that shows up as false flags, sometimes hundreds a week, which slowly trains the team to ignore every comment.

AI Code Review: The One Bug It Can Never Catch

In January 2026, the CEO of an AI code review company called the whole category a bubble. That is a strange thing to publish about your own market, and he was not wrong. These review bots promise thoroughly reviewed pull requests and hardened codebases. In reality they are very good at one specific job and dangerously weak at another, and you tend to find out which is which only after something breaks.

This article covers what an AI reviewer is actually doing under the hood, the one class of bug it can never catch no matter how good the model gets, and how to wire one into your team without rotting everyone’s judgment.

Is AI code review actually a bubble?

The hype is a bubble; the tool underneath is real. AI code review is software that reads a pull request and leaves comments the way a colleague would, flagging likely bugs, security holes, and sloppy patterns. The CEO who called the category a bubble, Daksh Gupta of Greptile, was pointing at the dozens of near-identical startups, not at the technology. Half of them probably will not exist in two years. That says nothing about whether the underlying tool works.

It does work, for a narrow job. The trouble is that the marketing sells it as a senior engineer in a box, and it is nothing of the kind. Once you see how one is built, you can predict exactly which bugs it catches and which it will sail past every single time.

How does an AI code reviewer actually work?

Most people picture a senior engineer who read the whole codebase and formed an opinion. It is not that. Picture a triage desk assembling a case file. Before the model says a word, the tool clones your repo, maps which files and functions touch the code you changed, digs through your git history for the things that tend to break together, and runs 40-plus old, boring scanners and linters.

The language model is the last person in the room. It gets handed the finished folder and asked what it thinks. CodeRabbit’s own writeup describes this build-the-context-first pipeline directly, and the better tools will tell you that the large majority of the work happens before the model is involved. So the whole game is what lands in that folder.

01 Clone the repo Pull the whole codebase, not just the diff

02 Map files & functions What calls what, what your change touches

03 Dig the git history The stuff that tends to break together

04 Run 40+ scanners Linters and analyzers, deterministic

05 The model speaks Last stage. Handed the finished folder LLM

~85% of the work happens here, before the model has thought about a thing. The language model is the last guy in the room.

Fig. 1 The case-file pipeline. Four deterministic stages build the folder; the model is the last one to read it. The expensive tools gather the whole house before the model speaks.

That is also where the quality gap between tools opens up. A cheap bot that reads only the diff, just the lines you changed with nothing around them, is reviewing your code through a keyhole. It cannot see what calls the function you rewrote, or what breaks three files over. A codebase-aware tool goes and gets the rest of the house first, which is most of why one review is sharp and another is noise.

It is mostly rebranded linting with a model on top

None of the scanner work is new. The first such tool, lint, came out of Bell Labs back in 1978, and your linter has been catching unused variables and type mismatches since before most of us were born. The word that matters is deterministic: same code in, same answer out, every time, and every complaint points at an exact rule you can go read. A security scanner can even prove things, tracing a piece of user input all the way down to a database to show there is an injection hole sitting right there. That is a proof, not a vibe.

The language model adds the fuzzy stuff the rules cannot touch. It reads your PR description and your ticket and says “hold on, this does not do what you said.” It writes the plain-English summary. It flags weird things nobody wrote a rule for. That part is new, and it earns its place.

The LLM layer · new

Reads your PR and ticket, says "this isn't what you described"
Writes the plain-English summary
Flags odd things no rule was ever written for

Can't prove anything. Ask twice, get two answers. Non-deterministic.

rides on top of ↓

The deterministic base · since 1978

Linters and scanners: unused vars, type mismatches, dead code
Security taint analysis traces user input to a database sink
Every complaint points at an exact rule you can go read

Same code in, same answer out. Every time. That's a proof, not a vibe.

Fig. 2 Two layers, two jobs. The deterministic base is provable and repeatable. The model adds reading the rules cannot do, but it cannot prove a thing and may answer differently run to run.

The catch the marketing skips is that the model cannot prove anything. Ask it the same question twice and you might get two different answers. So when a tool brags that it caught a bug, often the boring scanner did the catching and the model just reworded it in a friendlier voice. The model rides on top of your linter. It was never going to replace it.

The one bug AI code review can never catch

The fatal limit is simple: the bot reads your code, it does not run it. A large share of real bugs do not live in the lines you changed at all. They live in the gap between your change and a rule nobody bothered to write down.

A security team pointed an AI reviewer at a banking app. A user could dispute a small charge, get it refunded, then refund a much larger amount on top. Free money. Not one line of that code looks wrong, and there is no broken function to circle. The bug is a business rule, the kind that lives in someone’s head or a forgotten ticket, and the only way to catch it is to reason through the whole dispute-and-refund dance and then run it. The bot did neither.

Business rules

A user disputes a $5 charge, gets refunded, then refunds $500 on top. No line looks wrong. The bug is a rule in someone’s head.

Race conditions

Two things fire at once and corrupt each other. Read the code line by line and every line is fine. Only running it reveals the crash.

Logic across services

The change is correct in this file and breaks something three services over. The bot was handed one chapter and asked to review the plot.

Fig. 3 The blind spot, and it is wide. Each of these looks fine line by line and is only wrong in context. The model was handed one chapter and asked to review the plot.

This is not a grudge. An independent benchmark, the first one not published by a tool trying to win it, put these reviewers against bugs already known to be in the code. Martian’s Code Review Bench is an early v0 its authors call directional rather than final, and even on that generous footing the front-runner caught only about half the known bugs. The best one. So treat it as a fast first pass, not the thing standing between you and a broken production deploy.

Why does it flag bugs that were never there?

The same model that misses real bugs also invents fake ones. Language models are trained to always produce an answer, and an OpenAI paper on why models hallucinate makes the mechanism plain: scoring rewards a confident guess over an honest “I am not sure.” So the model does what a student does on an exam they did not study for. It guesses, confidently. In review that means flagging problems that were never there.

Some of these are pure comedy. One reviewer flagged “Python 3.14 does not exist yet” as a logic error, except Python 3.14 shipped in October 2025. Another time a developer pushed back on a comment and the bot replied “you’re absolutely right, remove the try-catch,” apologizing for a try-catch the developer says was never there.

A good human reviewer

1 comment that matters. The other 40 dropped on purpose.

The bot

41 comments, all lit. You learn to skim, then stop reading.

Fig. 4 More comments is not more review. A good human drops 40 nitpicks and says the one thing that matters. The bot says all 41, and the noise teaches you to stop reading.

On its own a dumb comment is harmless. The damage is cumulative. On some teams the bot drops hundreds of comments a week and nearly all get ignored, and the noise trains you: you learn the bot is usually wrong, so you skim, then you stop opening its comments. That reflex does not stay pointed at the bot. You start skimming the human comments too. The entire reason review exists, one person understanding what another changed, quietly decays into a habit of not thinking.

Why is reviewing AI-written code harder?

A lot of the code these bots review now was not written by a person. Another AI wrote it, and reviewing AI code is harder than reviewing the human kind for a reason that sounds backwards: it looks too good. There is an old line, often traced to Kernighan in the 1970s, that debugging is harder than writing. AI cranks that up. The code it produces is clean and well formatted with sensible names, and underneath it is often built in ways no human would choose, with subtle bugs hiding behind the polish. A 2026 Sonar survey found 61% of developers say AI code often looks correct but is not reliable.

Cost to write code

fell off a cliff

Cost to understand it

didn't move an inch

AI code looks clean: sensible names, tidy formatting, like a careful engineer wrote it on a good day. Underneath it can be built in ways no human would choose, with subtle bugs behind the polish. Your eyes slide right over it. So does the bot's, especially when the same model wrote it.

Fig. 5 The trade that breaks review. AI made writing code almost free; understanding it costs exactly what it always did. When the same model writes and reviews, both share the same blind spot.

One developer audited six months of pull requests after his team went all in on AI. No single PR was a disaster; each looked reasonable, got a thumbs up, got merged. But across six months the codebase had quietly rotted into something nobody would have designed on purpose: over-abstracted, strangely uniform, like it was written by a very polite stranger. The kicker is that the point of no return had probably already passed and they could not see it, because the tests still passed. Point the same family of model at writing the code and reviewing it, and author and reviewer make the identical mistake and nod at each other.

How should you actually use AI code review?

None of this means switch it off. Used right it is a great first pass, and the job is to keep it a first pass and never let it get promoted to final word. A handful of moves do that, and all of them work today.

Don't let it block

Comments, not a failed build, until the team trusts it. GitHub’s own reviewer only leaves a comment anyway; to gate a merge you wire a separate required check yourself.

Give it a lane

Kill the style nitpicks, your linter owns those and does them better. Point the model at logic, security, and intent. Three sharp things beat forty chatty ones.

Keep pull requests small

The single biggest lever. The model loses the plot on big diffs; bugs slip into the middle where its attention runs thinnest. A small PR is one it can hold in its head.

Gate on tests and humans

Treat it as a static analysis tool that happens to speak English. It runs in CI and points at things. Your deterministic checks and a human approval gate the merge, every time.

Fig. 6 Four moves that keep an AI reviewer a fast first pass and never the final word. None are hard, and all work today.

The framing that ties it together comes from the people running these every day: do not think of it as another reviewer, think of it as a static analysis tool that happens to speak English. That reframe also sets the right division of labor, because the bot and a human are good at almost opposite things.

Dimension	AI reviewer	Human reviewer
Speed	Seconds on every PR, tireless	Hours to days, limited attention
Style and lint nits	Instant (but your linter already wins here)	A waste of human time
Business logic	Blind; cannot reason about intent	The entire point of human review
Race conditions and runtime bugs	Misses; reads code, never runs it	Can reason through and actually run it
Can it prove a finding?	No; may differ run to run	Can verify by running and testing
Accountability for a bad merge	None; cannot be paged	Owns the outcome

One detail trips teams up. If you want AI findings to stop a bad merge, you have to build that yourself. Per GitHub’s own docs, Copilot code review only leaves a Comment review, which does not count as an approval and cannot require changes. By default the bot just comments, so a separate required status check is what actually gates anything.

A clean AI review proves nothing

Here is the line to staple to the wall. A clean AI review does not mean your code is correct. It means nothing got flagged, and that includes everything the bot is blind to: the business logic, the race condition, the bug three services over. Silence from the bot is not a green light. It is just silence.

AI review: clean 0 issues flagged

does not mean

Still in the code, unseen

Business logicRace conditionBug 3 services over

Fig. 7 Clean does not mean correct. A zero-issue review only says nothing tripped a rule the bot can check, while the bugs it cannot see sit untouched underneath.

And when AI-approved code breaks production at 2am, the bot does not get paged. It does not get the angry Slack message. It cannot own the outage, because you cannot fire a model. The person who wrote the code and the person who approved it are still holding the bag, exactly as before. So use the thing. It is a fast, tireless first reader that catches the dumb stuff so your humans can spend attention where it counts. Just never let “the bot approved it” become a sentence anyone says out loud. It read the diff. It did not understand your software. That part is still your job.

For the animated version, with the case-file pipeline, the banking exploit, and the full playbook on screen, watch the breakdown on YouTube.

Watch the explainer