A reviewer staring at 400 lines of AI-generated code has, at most, twenty minutes of real attention. Reading it left-to-right burns that budget on syntax that is already known to compile. The senior reviewers we shadow do not read AI code that way. They pick one of three mental models before they start, and they switch when the situation changes. This post names the three, shows when each one wins, and explains why the answer is almost never "read carefully."
Why this matters
AI-generated code is harder to review than human code, not easier. It compiles. It uses idioms. It looks confident. The signals that used to tell a reviewer "slow down here" — awkward variable names, inconsistent style, partial implementations — have been smoothed away by the model. The reviewer's pattern-match for "this looks wrong" no longer fires. Reviewers who do not adapt end up rubber-stamping AI changes and catching bugs only after they land in production. The three models below give the reviewer back a place to stand.
What does each mental model actually look like in practice?
The plausibility-first model asks one question on every page: is this the kind of code someone with a reason would write. Not "is it correct" — is it shaped like a decision. AI overreach has tells. A retry budget set to 5 with no comment, a cache TTL of 60 * 60 * 24, an error message that is a perfect paraphrase of the docstring above it. None of these are bugs in a strict sense. All of them are signs the model filled a slot without a constraint. The plausibility-first reviewer flags those slots and asks the engineer to defend them. Half the time the engineer cannot, and the slot becomes a real review comment.
The invariant-first model ignores the surface and asks one question: what invariant does this code protect, and did the change preserve it or break it. Invariants are the things that must remain true for the system to function — "every order belongs to exactly one tenant," "no two callers see different values for the same idempotency key," "background jobs never observe a write before its transaction commits." A senior reviewer using this model reads the diff as evidence about invariants, not as code. They will spend twelve minutes on three lines and skim the other 397. This is the model that catches the bugs that take down production.
The diff-first model is the narrowest and the fastest. It asks: what specifically changed in this diff, and does that change match the stated intent of the PR. It is the model for a focused bugfix or a tight refactor with a one-sentence description. The reviewer reads the PR description, reads only the changed lines, and asks whether the description and the lines tell the same story. When they do not, the PR is wrong even if the code is correct.
The decision tree below shows how senior reviewers actually pick.
When does the plausibility-first model fail?
Plausibility-first works because AI-generated code has stylistic tells. It stops working when the code has been edited enough times that the tells are gone. By round three of revisions, the model has been steered hard enough that the output looks like the reviewer's own taste. Plausibility-first reviewers at that point report "looks fine" and miss the invariant violation that lives one level below taste.
The other failure mode is reviewer drift. Engineers who use plausibility-first too often start treating their own taste as the rubric. A reviewer who has seen 200 AI PRs in a quarter develops strong opinions about what AI code "feels like." Some of those opinions are useful pattern-match. Some are folklore. The model that helps a junior reviewer in week one can hurt a senior reviewer in month six, when their threshold for "implausible" has crept upward and they stop reading carefully.
The chart below shows how often each model gets used by senior engineers across five common review situations. The point is not that any model is universally best. It is that each one dominates a specific kind of PR, and senior reviewers switch fluidly between them.
The shape of this chart is the entire argument. Refactors and security fixes lean invariant-first because the cost of a missed invariant is high. Bugfixes lean diff-first because the change is small and the description is the contract. New files lean plausibility-first because there is no prior shape to compare against. A reviewer who uses the wrong model for the situation works harder and finds less.
Why do senior engineers reach for invariant-first more than juniors?
Junior reviewers default to plausibility-first because it is the easiest model to run. You read the code, you check that it looks right, you trust your eye. Senior reviewers default to invariant-first because they have been on-call long enough to know that the bugs that wake them up at 3am are never the implausible-looking ones. They are the plausible-looking ones that quietly violate an invariant nobody wrote down.
The transition from junior to senior reviewer often looks like learning to name invariants. A junior reviewer says "this looks fine, ship it." A senior reviewer says "what invariant does this code rely on, and where is that invariant enforced." The two questions sound similar. They produce different reviews. The senior reviewer's question survives the code being rewritten by a model that knows nothing about the system's history; the junior reviewer's question does not.
The mapping below shows which model fits which review situation best, with notes on the failure mode of each pairing.
| Situation | Plausibility-first | Invariant-first | Diff-first |
|---|---|---|---|
| New file, greenfield | Best fit. Catches model overreach early. | Useful, but the invariants are still being chosen. | Weak. There is no prior diff to compare against. |
| Refactor of working code | Risky. The refactor will look plausible because the model copied the style. | Best fit. The refactor is judged on what it preserved. | Useful, but only if the PR is small. |
| Bugfix with narrow scope | Wastes attention on code that did not change. | Useful for the surrounding invariant; do not overspend. | Best fit. Read the changed lines against the stated bug. |
| Security or auth change | Dangerous. Plausibility cannot tell you whether the boundary held. | Best fit. Auth boundaries are invariants. | Useful as a follow-up pass after invariant-first. |
| Test-only update | Useful — a sane test reads like a sentence. | Use this to check the test still protects the original invariant. | Best fit if the test was just renamed or moved. |
How do you teach this to someone who hasn't done a lot of code review?
Have them name the model out loud before they open the PR. Ten seconds. "This is a refactor; I'm going invariant-first." It feels silly for a week and stops feeling silly when they catch their first real bug because they spent twelve minutes on three lines instead of two minutes on three hundred.
Pair the naming habit with one question per model, kept short enough to remember. Plausibility-first: where would I push back if the engineer were here right now. Invariant-first: what would have to be true for this change to be wrong. Diff-first: do the diff and the description tell the same story. Three questions, one per model, asked aloud before the review starts. Reviewers who do this consistently report finding 30 to 50 percent more real defects per hour of review time. It is one of the cheapest training interventions we know.
The bug taxonomy each mental model is best at catching.
From Codritium Research
Where the AI Pair Fails
A taxonomy of the 1,876 bugs AI-assisted engineers shipped during our 2026 benchmark. Twelve bug classes, ranked, with the code patterns each one travels on.
Common questions
Aren't these just different code-review approaches?
They are, and that is the point. The reason it helps to name them is that AI-generated code makes the choice of approach more consequential than it used to be. With human-written code, plausibility-first usually catches what diff-first or invariant-first would have caught, because the human's mistakes show up as surface tells. With AI-written code, the surface tells are gone and the choice of model determines what you find.
Do you switch models mid-review?
Yes, often. A common flow is invariant-first for the first ten minutes to confirm nothing structural is wrong, then diff-first for the last five to check that the description matches the change. Switching is fine; switching without naming the switch is where reviews go wrong, because the reviewer ends up running a fourth, undeclared model: read randomly and stop when tired.
Does the model depend on the language?
Less than you would expect. The three models map to the kind of change, not the syntax. The one language-specific note: in dynamically typed languages, plausibility-first carries more weight because the model is more likely to fabricate plausible-looking method names that do not exist. In statically typed languages, the compiler catches that and the reviewer can lean harder on invariants.
How do AI-rejection-rate scores relate to this?
AI-rejection rate measures how often an engineer rejects model suggestions on principled grounds. The three models are the principles. An engineer who can name which model justified each rejection scores higher on the rubric than one who rejects on vibes. The models are the explicit version of the senior reviewer's gut.
Can AI itself use these models?
Partially. We have had good results asking models to run invariant-first on a diff: 'list the invariants this change relies on and say which lines enforce them.' We have had worse results asking models to run plausibility-first on their own output — the model defends what it generated, which is not the same as judging it. Models do not yet review themselves well.
Is one model better than the others?
Invariant-first finds the most expensive bugs, but only if the reviewer can name invariants. Plausibility-first is the fastest. Diff-first is the cheapest to teach. There is no winner. The senior-reviewer skill is matching the model to the situation, not picking a favorite.
Where to go next
- Where the AI Pair Fails — the bug taxonomy and which model catches each class
- Defensibility: The Engineering Skill AI Cannot Replace — the rubric behind reviewer calibration
- Codritium challenges — code-review tasks scored on AI-rejection rate