Effort follows familiarity, not size

Most review advice scales effort to the size of the change. A big diff gets a hard look, a one-line fix gets a glance. This scales it to something else: how well the change is already understood.

  • Low. Code the reviewing model directed and watched as it was written. Re-read the change directly, no helpers.
  • Medium. Code new to everyone, a dependency bump or old code revisited, or anything that touches money math, writes files, or migrates data. A reader who did not write it takes a fresh pass.
  • High. On request, when the person asks for it by name.

The default is the part that bites. A review with no level set quietly becomes a high one that spawns its own helpers and fans out, which is the exact cost the levels exist to avoid. So a level is always chosen on purpose, never left to fall through.

Two passes, two jobs

One pass asks whether the change is correct: does the logic hold, are the edges handled, does it break something nearby. The other asks a different question entirely: is this the change that was actually asked for. A change can be flawless and still solve the wrong problem, and a single reader carrying both questions tends to answer the first and assume the second.

So they are kept apart. The correctness pass hunts for bugs. The intent pass compares the finished work against the original request and does nothing else. A bug hunter will not notice a missing requirement, and an intent checker will not catch an off-by-one, which is why neither pass covers for the other.

Why self-review is not enough

When the same model writes the instructions for a change and then reviews the result, it has a blind spot it cannot see past. A wrong instruction produces work that matches the instruction, and matching work reads as correct. The mistake is upstream of everything the reviewer looks at, so re-reading the change harder never surfaces it.

That is the whole reason the intent pass is a separate reviewer. It is handed the original request in the person's own words and is deliberately not shown the instructions the first model wrote. A misunderstanding cannot launder itself through a plan the checker never reads. Give the checker the plan and it would grade the work against the same wrong idea that produced it.

The disagreement loop has a floor

Re-review is capped at two passes after the first report. Every pass has to add something concrete: a change made, a check that can be reproduced, or a quoted source. Restating the same objection in new words does not count as a pass.

A point that survives a round with no new evidence on either side is not argued a third time. Both positions go to the person as a decision. This stops the familiar failure where a model relitigates the same objection until someone gives up, and it draws a clear line between a disagreement that is still moving and one that has stalled and needs a human call.

An unclear result is not a pass

A check that errors, times out, or comes back ambiguous is reported as unverified, never counted as passing. Silence is not a clean result. The temptation is to read no news as good news and move on, which turns a broken test into a green one on the page. Naming it unverified keeps the gap visible instead of hiding it inside a pass.