Reviewing code that no human wrote. You still own it.

Four preconditions. A no on any of them means the review can't reach a real verdict, and the fix belongs upstream of you rather than in your comments.

• Is the diff small enough to hold in your head?A few thousand lines can't be reviewed by any technique — skimming and approving is a rubber stamp with extra steps. Send it back to be split.
• Can the author defend every decision in it?They answer for this code as if they had typed it. "The model wrote it" is not an answer, and if it comes up the review is over.
• Do you have a requirement, from outside the diff, specific enough to fail the code?A ticket nearly always exists, so existence isn't the test. Every line must be answerable yes or no about this diff. If yours isn't, write that list before you read, and post it as the acceptance criteria.
• Does it build, run, and reference things that exist?A green build catches most invented signatures; config keys, env vars and dynamic calls survive it, so check those by hand. Evidence means a pipeline green on this head commit, or the author saying what they ran and saw.

Standing rule — leave the line-level nitpicks alone. Linters and the model already handle style, and every comment you spend there is attention not spent where tools can't reach. And when reading can't settle a question, run that one path rather than debating it in comments.

Absence is invisible when reading — you can't notice a line that was never written, or a convention the model didn't know to follow. Every check here replaces reading with something mechanical.

• Walk the stage-00 requirement, line by lineMark each line hit, partial or absent. Use the requirement you had before reading — not the PR description or a model-written summary, since both are derived from the diff.
• Did it arrive with a list of what was left out?Only the generating session knows what it chose not to do, and you don't have it — so producing this can't be your job. The set-up rule at the top of this sheet makes the author close with assumptions, stubs and deferrals. No such list on the PR? Ask for one before reading on.
• Does it fit the system it's landing in?Existing patterns, data model, module boundaries, and what breaks downstream. Generated code optimises for the task in front of it, not the codebase around it.When: a new module, or a change that crosses boundaries
• Verify independently of the model's memoryThat self-report came from the same context that lost the thing. Grep pairs that must match: endpoints against authz checks, tables against migrations, state values against where each is assigned. Or question a clean session given only spec and code.When: diff over ~400 lines, or a new module
• Look for the operational half nobody asked forMigration, rollback path, feature flag, monitoring, resource cleanup. These get skipped because the prompt described a feature, not a deployment.When: schema, config or infra is touched

Standing rule — read the end of a long generated file harder than the start. Dilution shows up as drift: error handling careful in the first handler and perfunctory by the eighth, validation that quietly stops appearing, stubs marked "similar to above".

Ignore the model's own verdict on its tests. "These are thorough" and "these are only for coverage" are both guesses, and neither is evidence.

• Take the riskiest test: would it fail if the code were wrong?Either its assertion pins down real behaviour or it just restates the implementation. Ask what the tests were written from — tests generated from the code can only echo it, bugs included.
• Mutate the code and watch the suiteFlip a conditional, return null, delete a statement, then rerun. Still green = a survivor: a line no assertion covers. Three by hand takes two minutes; a mutation tool scoped to the new module does it exhaustively.When: money, auth, permissions, or possible data loss
  Stryker JS/TS · C#mutmut Pythoncosmic-ray PythonPIT JVMcargo-mutants Rustinfection PHPgo-mutesting Go

Standing rule — manual testing never substitutes for a test. It doesn't run tomorrow, when someone else edits this.

A menu, not a list — pick the one or two lines that describe this code and ignore the rest. A pure function has no concurrency; a CRUD endpoint has no float precision. Each one names an assumption the happy path depends on and never states.

• Vary the input: how many, and what's in themCount: 0, 1, 2, max, max+1, duplicates, all-identical, page edges — generated tests reach for n=3, the one size that exercises nothing. Values: unicode, emoji, RTL, apostrophes in names, leading zeros, null vs "" vs an absent key, float precision limits.When: it takes a collection, or user input crosses this boundary
  Big List of Naughty StringsFaker with locales
• Assert relationships instead of exact outputsRound-trip, idempotence, conserved totals, order independence — or weaker ones when you can't state the right answer at all. A property tool then generates thousands of inputs you'd never pick.When: pure logic, parsers, encoders, calculations
• Break time and localeDST transitions, leap day, midnight, year boundary, negative UTC offsets, and now() called twice inside one request.When: dates, scheduling, expiry, durations
• Disturb the order and the dependenciesRetry after a timeout, two writers on one row, cancel halfway, replay out of order — and dependencies that succeed badly: slow, empty, stale from a replica, cold cache. Every individual step succeeds, which is why these hide.When: retries, queues, jobs, concurrent writers, network or DB calls
  Toxiproxy latency, dropsWireMock slow / emptyTestcontainers real, killable DBgo test -raceThreadSanitizer