Reviewing a PR where most of the code came from an AI is not the same job as reviewing a PR where a colleague wrote every line. The questions are different. The risks sit in different places. The polite comment in the old world is the wrong comment in the new one. Teams that have not updated their review etiquette ship two failure modes: reviewers who rubber-stamp because the code reads cleanly, and reviewers who pile on micro-comments that punish the author for collaborating with the tool they were asked to use. Both miss the actual job.
Why this matters
A code review is a trust transaction. In the pre-AI world the trust was between two engineers. In the AI world the trust is between you and the author's process — the prompts they chose, the suggestions they accepted, the replay they can defend. Reviewing the code alone misses what you are actually grading. Reviewing the process changes which comments help and which ones make you the reviewer everyone avoids. The patterns below are the ones we see separate useful AI-code reviewers from hated ones.
What is actually different about reviewing AI code?
Three things. First, style is no longer signal. The code lints, formats, and reads cleanly almost regardless of how good the underlying decision was. A pre-AI review could use style as a proxy for care; that proxy is broken now. Second, the failure modes have shifted. The bugs in AI code are rarely typos; they are missed invariants, stale context, and over-abstractions that look like good code from the outside. Third, the author is two entities — the human who pressed merge and the model that drafted the change. The human owns the decision; the model owns the draft. Your review needs to address the decision.
The pipeline below is the review flow we recommend for AI-authored PRs. It is five stages, and the order matters: the human reads the replay before the diff, not after.
Two of those stages are new for AI PRs. The replay step — reading the conversation that produced the change — is the one most teams skip and the one that catches the most material issues. The defense step — asking the author to explain a specific decision, not the change as a whole — is the one that separates a reviewer who tests the process from a reviewer who tests the syntax.
Which comments make reviewers useful, and which make them hated?
The fastest way to become a hated reviewer in 2026 is to leave the same comments on an AI PR that you would have left on a hand-written one in 2022. Comments about variable naming, about the precise shape of a loop, about whether a helper should be inlined — those are the comments AI already optimized for. They are also the comments authors find most insulting on AI code, because the implicit message is "you didn't prompt hard enough." That is not the conversation you want.
The useful comments share a property: they ask the author to defend a decision, not to redo a typing task. "Why this invariant here?" is useful. "Why not the alternative library?" is useful. "Walk me through what happens when this queue saturates" is useful. The comments that make reviewers hated share a different property: they are easy to satisfy by re-prompting and producing a slightly different draft. If a comment can be addressed by editing the prompt and pasting the new output, the comment was not testing anything.
| Scenario | Bad comment | Good comment | Why |
|---|---|---|---|
| AI-introduced abstraction | This abstraction is over-engineered. | What concrete second caller did you have in mind when adding this abstraction? | The bad comment is taste. The good comment makes the author defend the design choice or remove the abstraction. |
| Missing test for an edge case | Please add a test. | What happens when the input list is empty? I don't see that covered. | Naming the missing case forces the author to either add the test or explain why the case can't occur. 'Please add a test' invites a generic one. |
| Silent error handling | Don't swallow this error. | What is the recovery path when this fails? If there isn't one, the catch should surface and abort. | The good comment frames the question as policy. It's also harder to satisfy by re-prompting. |
| Unfamiliar helper introduced | Use the existing utility instead. | We already have <code>parseRequest</code> in the same file. Was this written without checking? | The good comment surfaces whether the author read the surrounding code, which is the real issue. |
| Stale-context bug | This API call is wrong. | Our <code>getUser</code> signature was changed two weeks ago. Did you re-read it before the prompt? | The bad comment is about the line. The good comment is about the process that produced the line. |
| Style nit on AI code | Variable should be camelCase. | (don't leave this comment — the linter will catch it) | Style comments on AI code are universally hated and add no signal. Let the linter own them. |
When should you reject a PR for the replay, not the code?
When the code passes review and the author cannot defend a load-bearing decision in it. This is the rejection that protects the codebase from the failure mode AI is best at producing: a clean PR that the author would not have written if they had been thinking, and that they cannot defend now that they have to. The replay — the conversation that produced the change — tells you whether the author thought. The code tells you what got typed.
A replay-shaped rejection sounds different from a code-shaped one. It does not list line numbers. It picks one decision and asks the author to defend it without re-running the prompt. If the defense is generic, the rejection stands. If the defense is specific to the system, the PR usually merges with a comment naming the why for the next reviewer.
The donut chart below is from our 2026 panel of reviewer-blocked AI PRs. The classes are the reasons reviewers gave for the block.
Three of the five — missed invariant, no replay, over-abstraction — are not visible on the line-by-line diff. They are visible in the surrounding code, the conversation, and the absence of a defense. A reviewer who only reads the diff catches the other two and misses these three, which together are 61% of the meaningful rejections.
How do you tell the author what they need to change without telling AI?
This is the etiquette question that has no equivalent in pre-AI review. If your comment is shaped like a prompt — "make this function shorter," "rename X to Y," "add error handling" — the author will paste it into the AI and you will get the same code with the change applied. That is not what the comment was supposed to produce. The comment was supposed to produce thinking, which the next prompt will not contain.
The way out is to write comments that require the author to make a judgment before they can write a prompt. "What would change if we needed to support a second caller here?" cannot be productively pasted into AI; the author has to answer it before they can prompt for anything useful. "Why this error class instead of the one we use in the rest of this module?" forces a comparison the author has to make first. The general rule: write comments your AI cannot directly act on. Those are the comments that test the human.
The pattern study showing which authoring prompts correlate with which reviewer experiences.
From Codritium Research
The Prompt Pattern Library, 2026
Twenty-four prompt patterns, A/B-tested against the rubric. Which framings move correctness, regression, and defensibility — and which don't. Effect sizes with confidence intervals, paired results, and adoption rates.
Common questions
Should reviewers run the code themselves?
On AI PRs, more often than on hand-written ones. The bugs in AI code are weighted toward classes the type checker won't catch — wrong invariants, swallowed errors, off-by-one in conditions that look right. Running the code on the boundary cases is cheaper than asking the author to explain why each case is safe.
Is it rude to ask 'did you write this'?
Yes, in 2026 it is. The question is a relic of an etiquette where AI involvement implied lower-effort work. That is no longer the operating assumption. Replace it with 'walk me through this decision' — which gets the information the original question was fishing for without the implication.
How do you handle a PR where AI clearly did most of the work?
The same way you handle any PR — by testing whether the author can defend the choices. If they can, the share AI did is irrelevant. If they cannot, the share AI did is also irrelevant; the rejection is about the missing defense, not the tool that produced the draft.
What if the author can't defend a decision?
Block the PR and ask them to come back with the defense, not with a different draft. The failure mode to prevent is the author re-prompting and shipping a new version they also cannot defend. The defense is what you are reviewing for; produce that first.
Do you review tests differently for AI code?
Yes. AI tends to write tests that exercise the happy path the production code also exercises, so the tests pass without testing anything new. On AI PRs, read the tests for whether they would have caught a plausible-nonsense version of the code. If they would not have, the test coverage is decorative.
Where to go next
- The Prompt Pattern Library 2026 — which authoring prompts produce reviewable code
- Platform challenges — practice defending AI-drafted changes
- AI pair programming patterns that actually work