The uncomfortable fact about coding agents in 2026 is that their output quality has outrun most teams’ review habits. Human review evolved to catch human mistakes: typos, off-by-ones, the shortcut taken at 6 p.m. AI-generated code fails differently. It compiles, reads idiomatically, handles the obvious edge cases — and can still be confidently wrong about what you actually asked for. Reviewing it with human-calibrated instincts is how plausible-but-wrong code reaches production.
Here is the review method we use on our own agent-written changes. It is ordered by where AI code actually fails, most common failure first.
Start with the spec, not the diff
The single most common failure mode of agent-written code is not a bug — it is a correct implementation of a misreading. The agent solved a problem adjacent to yours: handled the singular case when you meant the plural, optimized the function you named instead of the path that was slow, added the validation to the endpoint you mentioned rather than everywhere the data enters.
So before reading a line of the diff, re-read the task you gave. Then ask of the diff exactly one question: is this the right shape of solution for that task? Not “is this code good” — is it the right code to have written. Check this at the file list level first: are the files you expected to change the ones that changed? A diff that touches surprising files either found something you missed or misunderstood the assignment, and you need to know which before details matter. If the shape is wrong, stop reviewing and rewrite the instruction instead — line comments on a misdirected diff are wasted effort.
Hunt the confident middle
Human reviewers instinctively scrutinize the parts that look hard and skim the parts that look routine. Invert that for AI code. The genuinely tricky sections got the model’s full attention and are usually right. The failures hide in the confident middle: the boilerplate-looking loop with a subtly wrong boundary, the error handler that swallows the one exception that mattered, the cache key missing one dimension of the input.
Three specific patterns earn a close read every time. Silent fallbacks: agents like writing except: return default — code that converts crashes into quiet wrongness, which is strictly worse in production. Ask of every fallback: when this fires, will anyone know? Plausible constants: timeouts, batch sizes, retry counts, and limits arrive looking authoritative and are usually invented. Every unexplained number in an AI diff is a question. Phantom conventions: the model writes to the conventions of the median public codebase, not yours. It will import the popular library where your team uses an internal one, or add a config knob where your codebase resolves things at startup. Each phantom is small; merged steadily, they dissolve a codebase’s coherence.
Interrogate the tests it wrote
Agent-written tests pass. That is nearly all you can assume, because the model that wrote the code also wrote the tests, from the same understanding — if it misread the task, the tests encode the same misreading and pass beautifully. Treat green checks as evidence the code matches the model’s understanding, not yours.
Two cheap probes cut through. First, read only the test names and ask whether the case you most worry about appears; agents test the happy path and the obvious errors, and skip the weird middle — the empty list, the duplicate entry, the two operations racing. Second, pick the most important assertion and mentally break the code it guards: would this test actually fail? Assertion-free tests that merely execute code are an agent specialty. Anything that survives execution counts as passing.
If the change matters, add one test the agent did not write, targeting the scenario from your understanding of the task. It is the cheapest possible check on spec drift — and doubles as documentation of intent that survives the next agent session. When you lack time for even that, say so in the review record: “merged on agent tests only” is honest state you will want visible later.
Run it, and calibrate over time
For any change with observable behavior, spend two minutes exercising it end to end: hit the endpoint, click the flow, run the command against real input. This feels beneath the dignity of a reviewer with a green CI run in front of them. Do it anyway — it catches an embarrassing fraction of everything above, because behavior is where misreadings become visible.
Then close the loop, because review is also where you learn to write better instructions. Every real catch is feedback about the prompt, and the fix belongs in your instruction files — the conventions the agent violated, the fallback policy it should have known, the edge cases your team always cares about. Teams that route review findings back into instructions watch their catch rate fall month over month. Teams that only fix the diff meet the same failures forever, one plausible merge at a time.
One calibration note: not every diff deserves the full method. Scale the depth to the blast radius — a doc fix gets the spec check and nothing else, while anything touching money, auth, or data deletion gets every step plus a second pair of eyes.
The method above adds perhaps ten minutes to a mid-sized change. Whether that is expensive depends on what you compare it to: it is slower than rubber-stamping, and far cheaper than the production incident whose root cause reads “the tests were green.” Review is not the tax you pay to use coding agents — it is the mechanism that lets you keep raising how much you safely delegate to them, which is the entire economic point.