The question is not which is better. They are not doing the same job.
An AI review reads a diff and applies criteria. A human review decides whether a change should exist, whether the approach is right, whether the team can maintain it, and whether the person who wrote it understood the system they were changing. Only one of those lists gets shorter as models improve.
Getting the split wrong is expensive in both directions. Teams that treat AI review as a replacement stop asking the questions that matter. Teams that treat it as worthless keep spending senior attention on missing null checks.
The short answer
Section titled “The short answer”AI review is good at coverage and consistency. It reads every line at the same standard, applies written criteria uniformly, and does not get tired at line 400.
Human review is good at judgement. Should this exist? Is this the right approach? Will the team understand it in a year? Does the author know what they changed?
The combination that works: AI handles the mechanical sweep so human attention goes to the questions only humans can answer. The combination that fails: both layers doing the mechanical sweep, and nobody asking the design questions.
What AI review catches reliably
Section titled “What AI review catches reliably”Mechanical defects. Unhandled nulls, missing error paths, resource leaks, off-by-one, unawaited promises, a copy-paste that was not fully edited. High-frequency, low-glamour, and genuinely where production defects come from.
Written standards. Anything encoded in review instructions, applied to every pull request without depending on who reviewed it.
Consistency within a diff. Three similar functions, one of which handles an edge case differently.
Coverage of the parts humans skip. The last 400 lines of a large change, the test file, and the configuration hunk at the bottom that everybody scrolls past.
Documented pattern violations where the pattern was written down somewhere it could read, which in practice means an instruction file rather than a wiki page nobody linked.
The common thread: these are properties of the code in front of it, decidable without knowing why the change is being made.
What only a human can decide
Section titled “What only a human can decide”Whether the change should exist. A well-implemented feature that should not be built gets a clean AI review. Nothing in the diff says “we agreed not to do this”.
Whether the approach is right. A model can tell you the implementation is sound. It cannot tell you that a queue would have been better than a cron job, because that requires knowing what else is planned, what broke last year, and what the team can operate.
Whether the abstraction fits the domain. Naming, boundaries, and whether a concept in the code corresponds to a concept the business actually has.
Whether the team can maintain it. A clever solution that only its author understands passes every mechanical check.
Whether the author understood the system. This is the one people forget. A review is partly a conversation, and part of its value is discovering that the author did not know about the other caller, the migration in flight, or the reason the previous approach was abandoned. That discovery does not happen in a comment thread with a model.
Whether the risk is acceptable now. Same change, different week, different answer — because a release is going out, or the on-call engineer is new, or the team is short-staffed. Context that exists nowhere in the repository.
Whether the pull request is honestly described. A description claiming a change is a refactor when it alters behaviour passes every mechanical check, and the mismatch is only visible to somebody who reads both and cares about the difference.
Whether the tests test anything. A model can see that tests exist and are structurally reasonable. A human notices that they all mock the thing that would fail.
Why the boundary is where it is
Section titled “Why the boundary is where it is”It is worth being precise about why certain judgements resist automation, because “AI cannot do judgement” is the kind of claim that ages badly and gets repeated without examination.
The distinction is not intelligence. It is where the information lives.
A review criterion is decidable when everything needed to decide it is in the diff or in the repository. Missing null check: in the diff. Import crossing a layer boundary: in the diff plus a written rule. A model reads both.
The judgements that resist automation are the ones whose deciding information is somewhere else:
In a conversation. “We agreed last month not to add more configuration flags.” Not in the repository. Not in any document. In the memory of four people who were in a meeting.
In the operational context. “This is fine, but not this week — we are mid-migration and the on-call rotation is thin.” True on Tuesday, false the following Tuesday, and nowhere in the code.
In the organisation. “The payments team owns this concept. Adding a second definition here will cost us six months.” A fact about people and ownership, not about types.
In the author’s head. “Did you know about the other caller?” The answer determines whether this pull request is fine or a serious incident, and it is not in the diff — it is in whether the person understood what they were touching.
In the future. “This works, but we are moving to event sourcing next quarter and this makes that harder.” A judgement about a system that does not exist yet.
This framing makes the boundary useful rather than mystical. Anything you write down moves across the line. A convention captured in an instruction file becomes decidable. An architectural boundary expressed as a rule becomes checkable. That is exactly the work of custom instructions, and it is why the boundary moves over time.
What does not move: judgements that depend on information that is inherently unwritten — because it is about this week, about these people, or about a decision nobody has made yet. Those are permanent, not because a model could not evaluate them, but because nobody has told it, and in most cases nobody could.
The comparison
Section titled “The comparison”| Dimension | AI review | Human review |
|---|---|---|
| Coverage of a large diff | Complete | Degrades with size |
| Consistency across pull requests | High | Varies by reviewer and day |
| Latency | Minutes | Hours to days |
| Mechanical defects | Strong | Variable |
| Written standards | Applied uniformly | Applied when remembered |
| Should this exist | No | Yes |
| Is the approach right | No | Yes |
| Team-maintainability | No | Yes |
| Organisational context | No | Yes |
| Teaching the author | No | Yes |
| Accountability for the merge | No | Yes |
The last row is the one that settles the argument. Somebody is responsible for what merges, and it is not the review tool. That is not a limitation to be engineered around; it is what review is for.
The two failure modes
Section titled “The two failure modes”Substitution. AI review is enabled, human review becomes a formality. Approvals arrive without anybody having thought about the change. The mechanical layer is strong and the judgement layer has quietly disappeared.
It is hard to detect because the metrics improve. Review latency falls. Comment volume rises. Defects found per pull request goes up. What has degraded — whether anybody asked if this was the right thing to build — is not measured anywhere.
The signal to watch for: when did somebody last reject a pull request on approach rather than implementation? If the answer is “I cannot remember”, the judgement layer is gone.
Dismissal. The team decides AI review is noise, turns it off or ignores it, and continues spending senior engineers’ attention on null checks. Usually a response to an untuned rollout, and usually correct about the rollout while wrong about the feature.
The signal: how much of your human review time goes to things a written criterion could have caught? If it is most of it, the expensive layer is doing the cheap layer’s work.
Sequencing them
Section titled “Sequencing them”Order matters more than most teams assume.
AI first, then human. The default, and right for most changes. The mechanical pass completes in minutes; the human arrives at a diff where the obvious things are already fixed or explicitly dismissed, and can spend their attention on structure.
Human first, then AI. Right when the design question is the risky part. Getting an approach approved before anybody reviews the implementation avoids a detailed mechanical review of code that is about to be rewritten.
Escalated, for high-risk changes. Some changes deserve a third pass: AI review, then the author’s team, then somebody from a team that will be affected. Migrations, changes to shared libraries, anything touching authentication. The layers are not a fixed pipeline — how many apply is a risk decision.
Both in parallel. The default in practice, because automatic review fires when the pull request opens. It works, with one cost: the human may start reading before the AI comments land, and then has to re-read. Not serious, but it is why some teams prefer review on ready-for-review rather than on open.
Neither, for some changes. A one-line configuration change reviewed by two layers is process for its own sake. Not every change needs every gate, and pretending otherwise is how gates become rituals.
Reallocating human attention
Section titled “Reallocating human attention”The point of the AI layer is not to reduce human review. It is to change what human review is about.
Before: a reviewer opens a 600-line pull request, reads carefully for 150 lines, skims, spots two missing error checks, comments on them, approves. Time spent: forty minutes. Value delivered: two error checks and a nominal approval.
After: the mechanical pass has already found the error checks, and the author has fixed them. The reviewer opens a diff where the remaining questions are structural. Time spent: twenty minutes. Value delivered: “why is this in the API layer?” — which is a question that changes the design.
The second is a better use of forty minutes even at half the duration, and the difference is entirely in what the reviewer was free to think about.
The failure is spending the recovered time on nothing — approving faster rather than reviewing deeper. That is a choice teams make without noticing they made it, and it is the substitution failure mode arriving through the side door.
The layers below both
Section titled “The layers below both”Neither layer is the first thing to look at a change, and framing the choice as “AI or human” skips the layers that are cheaper and more reliable than either.
The full stack, in the order a change encounters it:
| Layer | Catches | Cost per run |
|---|---|---|
| Compiler / type checker | Type errors, missing symbols | Seconds |
| Linter and formatter | Syntax-level rules, style | Seconds |
| Tests | Behavioural regressions | Minutes |
| Static analysis (CodeQL) | Known vulnerability patterns | Minutes |
| Dependency and secret scanning | Vulnerable packages, leaked credentials | Minutes |
| AI review | Written criteria, mechanical defects, consistency | Minutes |
| Human review | Approach, design, context, accountability | Hours |
Two things fall out of that table.
AI review sits sixth, not first. Anything the five layers above it catch, they catch deterministically and faster. An AI review finding a type error is a sign that the type checker is not running, not a sign that the review is working well.
Cost rises down the column. Every finding pushed upward is cheaper. A convention enforced by a lint rule costs nothing per pull request; the same convention enforced by a human comment costs somebody’s attention every time.
The useful operational question is therefore not “AI or human” but “what is the highest layer that could have caught this?” Ask it about the last ten defects that reached production and the answer is rarely the review layer — it is usually a test that was not written, and occasionally a type that was too loose.
This is also the honest answer to teams asking whether AI review will find their bugs. It will find some. The layers above it will find more, faster, for less, and most teams have gaps there that are cheaper to close.
Reviewing AI-authored changes
Section titled “Reviewing AI-authored changes”The split shifts when the code under review was written by a model, which is increasingly the common case.
The mechanical layer becomes less informative. Code generated with a model’s own conventions tends to pass a model’s own mechanical checks. Consistent naming, present error handling, plausible structure. A clean AI review of AI-authored code is weaker evidence than a clean AI review of human-authored code.
The judgement layer becomes more important. The questions that matter — is this the right approach, does it fit the system, did anybody verify the behaviour — are exactly the ones neither the author nor the reviewer is a human for, unless somebody deliberately makes it so.
Author accountability does not transfer. The engineer who opened the pull request owns it, regardless of how much of it they typed. This is the discipline that agent pull requests depend on, and it is the thing most at risk when volume goes up.
The practical consequence: as more code arrives from models, human review should get more attention, not less. That is the opposite of what the volume increase makes convenient, which is why it needs saying out loud.
What review is for, besides finding defects
Section titled “What review is for, besides finding defects”The defect-finding framing is incomplete, and the parts it leaves out are the parts AI review does not touch at all.
Review is how knowledge spreads. Reading somebody else’s change is the main mechanism by which a team learns its own codebase. A team that stops reviewing carefully is a team where three people understand the payments module and everyone else guesses. No amount of mechanical review coverage substitutes for that, because the value is in the reading, not in the comments.
Review is how new engineers learn the standards. Not from the style guide — from a senior engineer explaining, in a thread, why this belongs in the service layer. An AI review can state the rule. It cannot have the conversation that makes the rule make sense, and it cannot notice that this particular person has now made the same class of mistake three times and needs a different explanation.
Review is shared accountability. Two people have now looked at this and think it should merge. When it breaks, the response is “we missed it”, not “you missed it”. That distributes risk in a way that matters culturally more than technically.
Review is a checkpoint on scope. The pull request that quietly grew a second feature gets caught by a human who says “why is this here?” Nothing in a diff-reading review identifies scope creep, because the extra feature is implemented perfectly well.
These are the reasons a team that has automated its mechanical review still needs humans reading each other’s code — and the reason “the AI reviewed it” is not a coherent argument for skipping human review even in the cases where the mechanical coverage genuinely is better.
The framing worth holding: defect-finding is the most measurable thing review does, and not the most valuable. Optimising a process for its measurable output at the expense of its unmeasurable one is a familiar mistake, and this is a place it happens quietly.
Common mistakes
Section titled “Common mistakes”Treating a clean AI review as approval. It is one layer reporting no findings it was looking for.
Letting human review become a rubber stamp. The most expensive failure, and invisible on every metric.
Spending human review on mechanical defects. If most human comments are about things a written criterion could catch, write the criterion.
Dismissing the AI layer because an untuned rollout was noisy. The rollout was the problem. See custom instructions.
Reviewing AI-authored code the same way as human-authored code. The mechanical pass tells you less; the judgement pass matters more.
Applying both layers to everything. Not every change needs every gate.
Measuring review by comment volume. It measures activity. The question is whether the right things changed.
Mental model
Section titled “Mental model”Two layers, different jobs.
The mechanical layer answers: does this code do what code of this shape should do? Automatable, consistent, and cheap once tuned.
The judgement layer answers: should this exist, is this the right approach, and does the person responsible understand it? Not automatable, because it depends on context that lives in people and conversations rather than in the repository.
Improving the mechanical layer does not shrink the judgement layer. It frees attention for it — and whether that attention actually gets spent is a decision the team makes, not something the tooling decides.
What you learned
Section titled “What you learned”- AI review is strong on coverage, consistency and mechanical defects
- Human review owns whether the change should exist, whether the approach is right, and accountability
- The substitution failure mode improves every metric while removing the layer that matters
- The dismissal failure mode is usually a correct reaction to an untuned rollout
- The point of the AI layer is to change what human review is about, not to reduce it
- AI-authored code needs more human judgement, not less
Exercise
Section titled “Exercise”Use a repository with recent merged pull requests.
-
Pick five merged pull requests. Read every human review comment on them.
-
Classify each comment: mechanical (a written criterion could catch it) or judgement (it required context).
-
Count the split. Predict: what proportion of your senior review time is mechanical?
-
For each mechanical comment, write the criterion that would have caught it. You now have the start of an instruction file.
-
Find the most recent pull request rejected on approach rather than implementation. Note how long ago it was.
-
Take one AI-authored change and one human-authored change of similar size. Compare what an AI review found in each. Predict: which produced fewer findings?