How to Review AI-Generated Code Before Merging: A Four-Step Method Stricter Than Human Review

A counterintuitive conclusion first: AI-generated code deserves stricter review, not looser review

Many people hold a gentle misconception about AI-generated code: since a model wrote it and the tests pass, it must be less error-prone than hand-written code. That misconception fails in two places. First, a model writes code by assembling the most probable-looking correct code, not by deriving correct code from understanding — it can hide a completely wrong business assumption inside perfectly correct syntax, and that assumption will look entirely reasonable. Second, models are best at making code look runnable: clean names, thoughtful comments, tidy structure. Those signals push a reviewer's brain into "looks fine" mode at exactly the moment it should be most alert.

So this guide's position is explicit: review of AI-generated code before merge should be stricter, slower, and less trusting of "looks fine" than review of human-written code. Not because models are bad, but because their failure mode is different. Human errors are usually carelessness, typos, missed edge cases. Model errors are usually "confidently treating a false premise as fact" — calling an interface that does not exist, assuming a field that does not exist, confusing two similar but different business concepts. These errors are hard to catch by skimming; they have to be forced out by a fixed set of review actions.

Boundary: what this guide is not

Before the main text, let us draw the boundary with neighbouring content on this site, so you do not use the wrong document for the wrong problem. This guide covers "the code is already written and about to be merged — how should a human review it?" The object under review is the diff already written; the actions are reading, running, checking, and asking; the endpoint is a merge-or-not decision. It is not the agent permission contract guide: a permission contract governs what an agent is allowed to do before it acts — prior authorization and isolation. This guide governs post-hoc review and gatekeeping. One comes before, one after, and neither substitutes for the other — even the tightest permissions cannot stop a wrong implementation inside the authorized scope, and the finest review cannot undo damage from an out-of-scope action.

Nor is it an introduction to review tools such as Claude Code Review: a tool can surface a diff and flag suspicious points, but judgments like "is this business assumption right?" or "should this edge case be handled this way?" cannot come from a tool — only from someone who knows the business. Nor is it a task acceptance checklist: an acceptance checklist answers "is this task done?" (features, documentation, tests, release steps complete), while this guide answers "can this code enter the main branch?" (logic correct, no security holes, no future landmines). A task can pass acceptance while its code still should not merge — for example, every feature works, but the implementation hides a branch that only triggers on specific data. Reviewing code and accepting a task are two different gates, and both must be passed. Finally, it differs from this site's October 2 checklist guide, "AI Code Review Checklist: 12 Checkpoints": that piece lists checkpoints, while this guide is a four-step method in review order (read the diff, run uncovered paths, check security and privacy, ask future questions), plus review rhythm, records, and a PR template — the checklist tells you what to check, this guide tells you in what order to act and what counts as done before you merge.

Step 1: read the diff first, not the explanation

The most common mistake in reviewing AI code is reading the model's explanation first and then looking at the code. The better the explanation reads, the more likely you are to approach the code already convinced "it has thought this through," and then to explain away every suspicious point automatically. The correct order is reversed: open the diff, read it from first line to last, form your own judgment, and only then look at the explanation — the explanation may answer questions you already have; it must not form your judgment for you.

When reading the diff, check three specific things. First, every newly introduced assumption: newly called functions, new fields, new libraries, newly assumed data formats — for each, ask "does this thing really exist? Is this really its semantics?" The model's most common error is inventing a plausible-looking interface or using one system's field name in another system. The countermeasure is simple: for every call you do not recognize, spend ten seconds searching the codebase for its definition; if you cannot find it, that is a red light. Second, what was deleted: when refactoring, a model often quietly removes an edge-case handler, an error branch, or a validation that looks useless — either because it judged it useless or because it never noticed it. Every deleted line needs an explicit reason, and the only acceptable reason is "this logic moved to such-and-such place," never "it looked useless." Third, the scope of the change: a task that should touch three files shows a diff touching a fifth file — the extra change is usually something the model did "on the side," and side changes are the least thought-through changes of all.

Step 2: run it — and run the paths it never ran

Passing tests do not mean the code is correct. That holds for human-written code and especially for AI code, because a model that generates code often generates the tests too, and the tests and the implementation can share the same wrong assumption: the implementation assumes field A is a string, the test asserts on a string, everything goes green, everything is wrong. In review you must run "the paths the model never ran": inputs it never saw, branches it never covered, boundary values pushed to extremes.

Four concrete moves. First, hand-build a counterexample: find a case the model claims to handle but you doubt it handles, run it yourself, and see whether the result matches your expectation. Second, change one input and run again: if changing one number, one string, or one null makes the program behave inexplicably, the implementation hides an implicit assumption about input formats. Third, look at error paths: deliberately break a dependency (database unreachable, API returning an error code) and see whether the program degrades gracefully or crashes outright — models are most likely to cut corners on error paths, because the happy path tests always pass first. Fourth, check performance traps: querying the database inside a loop, recomputing full datasets on every request, unbounded recursion — invisible in small test data, explosive at real data volumes.

One point reviewers often miss: the tests themselves need review. A model-generated test that merely restates the implementation's behavior is not a test; it is a synonym for the implementation. Good tests come from requirements, not from implementation: start from the task description or requirements document, ask "what should this feature output under what conditions," and then check whether the test asserts that. If a test only asserts "the implementation did what it did," its passing or failing cannot justify a merge.

Step 3: check security and privacy — the least negotiable part

Security is the highest-weighted category in AI code review because its costs are asymmetric: a logic bug may affect one feature; a security hole may affect the whole system. And models have a systematic weakness here: they tend to write code that runs, not code that is safe — directly concatenating SQL, building commands from user input, logging sensitive data, exposing fields on the frontend that should never leave the server. All of these pass functional tests; all of them are red lights in security review.

Review against a fixed checklist, not by feel. Input side: has every external input (user input, API parameters, file contents, environment variables) been validated and escaped? Is anything concatenated directly into SQL, commands, templates, or regular expressions? Output side: does data returned to the frontend or third parties contain fields that should not appear (password hashes, internal IDs, other people's data)? Do logs contain sensitive information (tokens, passwords, personal identifiers)? Permission side: does this endpoint check permissions, or does it assume "callable means visible"? Has a new endpoint been wrongly exposed to all users? Dependency side: is a newly introduced library from a trustworthy source, at a version with no known vulnerabilities, and is a heavyweight dependency being pulled in for a single small function?

Privacy deserves its own category: does the new code collect data beyond what the requirement asks for? Does it write user data where it should not go (logs, caches, third-party services)? Does it silently change data retention periods? None of these are visible functionally; a reviewer must ask them one by one against the requirements. My recommendation: security and privacy findings are veto-grade — if any one of them is unexplained, do not merge, no matter how beautiful the feature looks. Fixing a security problem after merge always costs an order of magnitude more than before merge.

Step 4: ask three "will we regret this later?" questions

The first three steps check "is it right now"; this step checks "will we regret it later." AI code tends toward implementations that work right now, with little thought for whoever maintains them later. The reviewer should ask three questions on the future maintainer's behalf. First, readability: can a newcomer understand what this code does within ten minutes six months from now? If the answer is "only by reading the model's original conversation," the code fails — code is read by humans, not by the model's original context window. Second, modifiability: if requirements shift slightly, how many places must change? If changing one field touches five files, the abstraction is wrong — the model scattered something that should have been centralized. Third, deletability: if this feature is later dropped, can it be removed cleanly? If removing it requires changing ten other places, the coupling is too deep, and it should be refactored now rather than on the day it actually needs deleting.

No automated tool can answer these three questions; only a reviewer who knows the codebase can. That leads to an organizational conclusion: the reviewer of AI code cannot be "whoever happens to be free." It must be someone familiar with this business area and this code. An unfamiliar reviewer can catch syntax problems but not wrong business assumptions or maintainability problems. When scheduling reviews, put familiarity ahead of availability — better to wait for the familiar person than to let an unfamiliar person wave it through.

Rhythm and records: slow review, fast feedback, leave a trace

On rhythm, I advocate "slow review, fast feedback." Slow review means: do not merge within five minutes of the model delivering code; give yourself at least one "put it down and look again" pass — many errors only appear on the second read, because on the first read you are still immersed in the model's explanation. Fast feedback means: once you find a problem, report it immediately and specifically to the model or author — do not save up ten comments for the end. The more specific the feedback (file, line number, wrong assumption), the better the next fix; the vaguer the feedback ("something is off here"), the more likely the next round introduces new problems.

Records matter equally. Every review conclusion (approve, conditional approve, request changes) and the reasons for rejection should stay in the pull request, not only in chat logs. Reasons should be written at the granularity of assumptions: not "this is wrong" but "this assumes a user ID always exists, but anonymous users have no ID, so the anonymous flow will crash." Such records have two benefits: first, the next similar problem can cite them directly; second, they form the team's review knowledge base — a newcomer learns "what this team cares about" faster from past review records than from ten guides.

One more check reviewers most often miss: look for "extra features the model added that the task never asked for." Models often do a little extra on the side — an extra configuration option, an extra endpoint, an extra "just in case" compatibility branch. These extras have no requirements backing, no test coverage, and nobody committed to maintaining them; merging them is future burden. Be especially wary of out-of-task additions in review: either the author proves they are genuinely necessary and adds tests and documentation, or they get removed. How clean a codebase stays often comes down to whether these "helpful extras" are tolerated or rejected.

Appendix: a review checklist to paste into your PR template

Reading the diff: did you read the diff before the explanation? Has every new call been confirmed in the codebase to exist with the right semantics? Does every deleted line have an explicit destination? Is the change scope within the task? Running it: did you run inputs and branches the model never ran? Did you hand-build a counterexample? Do error paths degrade gracefully rather than crash? Are there performance traps at real data volumes? Do the tests come from requirements rather than restating the implementation? Security: is external input validated and escaped? Is anything concatenated into SQL, commands, or templates? Does returned data contain fields that should not appear? Do logs contain sensitive information? Are endpoint permissions checked? Are new dependencies trustworthy and necessary? Looking ahead: can a newcomer understand it in ten minutes? How many places change when requirements shift slightly? Can the feature be removed cleanly? Is the reviewer familiar with this business area and code? Conclusion and records: is the conclusion approve, conditional approve, or request changes? Are rejection reasons written at assumption granularity and left in the PR? Paste this list into your PR template and check items off each time — not for formality, but to turn "being careful" into a repeatable action rather than depending on one person's state on a given day.

One final organizational point: do not treat AI code review as "finding the model's mistakes." Treat it as the team's last gate for code quality. Models will change, tools will change, prompts will change — but the gate "someone read it carefully, ran it, and checked it before merge" cannot change. Once that gate loosens, the codebase quietly accumulates code that "looks runnable but hides wrong assumptions," and the bill for that code always comes due at the least convenient moment. And a last reminder: review approval is not the end. In the first week after merge, watch error logs and user feedback for the affected features — problems review missed often surface only under real traffic, and catching them early keeps rollback cheap.