Module 02

Review Discipline

Rebuild review for work produced by something that cannot explain what it meant.

Review was a check on a colleague who understood the system. It is now the primary control on work from something that cannot explain itself.

Movement II — Redesign the four decisions. Delegation, review, legibility and permission. Each is already decided by default; this is where the decision becomes deliberate and gets written down.

What review used to rest on

Reviewing a colleague's change, you were not verifying it from first principles. You were sampling. The sampling worked because a person with context wrote it, that person could be asked what they intended, and they carried the consequences of being wrong. Those three supports did most of the work, and none of them survive the switch.

An agent has context that is broad and shallow, cannot be asked what it intended in any load-bearing sense, and carries nothing. The same sampling habit applied to its output is not a lighter version of the old review. It is a different activity with the same name.

Read for intent, not correctness

Agent output fails in a characteristic way: it is locally correct and globally wrong. The function does what it says. It should not exist, or it duplicates one three directories away, or it solves the request rather than the problem. Line-by-line reading is poorly suited to catching this, because line by line it is all fine.

So the first pass is not the diff. It is the question: what did this change assume about the system, and is that assumption true? Then: what should have changed and did not?

The practical test is explain-back. Close the diff and describe what the change does and why, in your own words. If you cannot, you have not reviewed it — you have watched it go past. The volume problem is real, but the answer is a narrower boundary from module 01, not a faster skim.

Method

01Before reading the diff, state what you expected the change to touch.
02Read for scope first: what changed that you did not expect, and what did not change that you did.
03Check the assumptions the change makes about the rest of the system, especially anything it did not read.
04Treat agent-written tests as part of the claim under review, not as evidence for it.
05Explain the change back without looking. If you cannot, reject or re-read — do not accept.

How this goes wrong

Reviewing the diff instead of the behaviour
The diff shows what changed, not what is now true. Locally correct and globally wrong survives diff review intact.
Accepting tests as verification
Tests written by the thing under review encode the same misunderstanding. They demonstrate internal consistency, which is not the property you were checking.
Volume-induced acceptance
Past a certain rate everyone rubber-stamps. This is a boundary failure, not a discipline failure — go back to module 01 and delegate less, rather than reviewing worse.

The exercise

Take three recent agent-authored changes you accepted.
For each, write what you actually checked, then what you should have checked.
Derive a protocol from the gap: the checks you will perform every time, in order.
Include your own stopping rule — the volume at which you stop accepting rather than start skimming.

Review protocol

The sections your artifact contains:

What I verify before accepting, in order
What I check that the tests cannot tell me
My explain-back rule
My stopping rule — the volume at which I stop, not skim