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.

• 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; the PR description and any model-written summary are both 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. If the PR has no such list, 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 and ignores the codebase around it.When: a new module, or a change that crosses boundaries
• Verify independently of the model's memoryThat self-report comes from the same session that dropped 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 and said nothing about deploying it.When: schema, config or infra is touched

Standing rule — read the end of a long generated file harder than the start. Quality drifts as the model runs out of attention: error handling that was careful in the first function and half-hearted 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

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

Treat this as a menu: 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.

• Try the edges: how many, what's in them, and whenCount: 0, 1, 2, max, max+1, duplicates, page edges — generated tests reach for n=3, the one size that exercises nothing. Values: unicode, RTL, apostrophes, leading zeros, null vs "" vs an absent key, float limits. Clock: DST, leap day, midnight, negative offsets, now() twice in one request.When: it takes a collection, user input, or a clock reading
• 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: adding an item must never lower the total. A property tool then generates thousands of inputs you'd never pick.When: pure logic, parsers, encoders, calculations
• 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

Asking a model to review a diff gets a summary of the diff. Asking it one hostile question at a time gets findings. Paste a prompt into your coding assistant with the diff in front of it, one angle per run.

• Name the assumptions nothing enforcesMost bugs are a broken assumption no one wrote down. Make them explicit and check what actually enforces them.When: any change with callers or inputs you don't control

  List every implicit assumption this change makes about its inputs, callers and environment. For each, state what breaks if the assumption is false, and whether anything in the code enforces it.

• Walk every way it can fail halfwayHappy-path code is easy; the failure paths are where state corrupts and resources leak.When: I/O, network, parsing or external calls

  Enumerate every operation in this change that can fail: I/O, network, parsing, allocation, external calls. For each, show the failure behaviour: swallowed error, wrong state, resource leak or crash. Flag any path that leaves the system inconsistent.

• Feed it hostile inputEvery attacker-controllable value is a potential injection or bypass. Demand a concrete exploit input for each.When: it handles input from users, files or the network

  Trace every attacker-controllable input into this change. Identify injection (SQL, shell, path, template), missing validation or sanitisation, and unsafe deserialization. Give a concrete malicious input and its impact for each.

• Check who may do this, and where the keys liveFlag missing checks and leaked credentials.When: auth, permissions or credentials are touched

  Find every authorization check and every secret or credential in this change. Flag missing, bypassable or over-broad access control, and any secret exposed in code, logs, error messages or responses.

• Question the dependencies it pulls inCode you didn't write but ship anyway: trust, versions and licences.When: a dependency is added or bumped

  List the external dependencies this change relies on. Flag unpinned versions, known-vulnerable surface, surprising transitive pulls, licence risk, and any place their output is trusted without validation.

• Find where it gets expensive at scaleCost that's invisible at test scale and fatal in production.When: hot paths, loops over data, queries

  Find where this change gets expensive at scale: N+1 queries, unbounded loops or allocations, blocking calls on hot paths, missing pagination or caching. Say where it falls over under production load.

• Break the invariants the data depends onThe invariants that must always hold, and the sequences that quietly violate them.When: schema, stored state or migrations

  List the data invariants this change must preserve. Find code paths that can violate them, plus nullability, migration and rollback hazards. Give a sequence of operations that leaves data corrupt or orphaned.

• Name every caller it breaksWhat existing callers depend on: the breakage that won't show up in this file's own tests, and the blast radius outside the diff.When: a public interface, format or default changes

  Compare this change against the contract its callers rely on. Flag breaking changes to signatures, return shapes, defaults, error codes or serialized formats, and everything downstream that depends on the old behaviour. Rank by likelihood of silent breakage.

• Spot the traps for the next maintainerMisleading names and stale comments set up the next person's bug.When: the code will be maintained by someone else

  Point out where this change is easy to misread or misuse: misleading names, hidden side effects, surprising defaults, silent type coercions, dead code, and comments that no longer match the code.

Standing rule — models invent plausible bugs. Reproduce each finding with a failing test or a manual repro before you raise it, drop the ones you can't, and rerun the prompts after the fixes land.