The acceptance checklist

in what order to look at a change

What it is

Article 2.14 lists what to look for in code. This one is about the order: in what sequence to look at a change so you neither drown nor miss the main thing.

Order matters because attention runs out. Start with the small stuff and there will be none left for the serious parts.

Six steps in order

1. The size of the change

git diff --stat

Does it match your expectation? One line where you expected one — carry on. Seven files where you expected one — stop and work out why before reading the contents (article 3.13).

2. What was removed

Look at the - lines before the + lines. Removal is more dangerous than addition: added code is visible, a vanished check is not.

Typical losses: if not data: return, length checks, edge handling.

3. Behaviour in the unhappy case

One question: what happens if the data isn't what was expected? If the change introduced .get() with a default, an except, or substituted values, check whether the error is being hidden rather than fixed (articles 2.8, 2.14).

4. Boundaries

Does the change do what was asked and nothing beyond? Logging, caching, retries nobody ordered are unchecked code in your project.

5. Run it

The case the whole thing was for, plus one unhappy one. If there are tests, run them (article 4.6).

6. Explanation

Can you explain the change in two sentences? If not, go back to reading, or ask (article 3.7).

What to tell the AI

The checklist can be handed to the AI too, with a caveat: about its own code it is lenient (article 3.8). So — in a clean session:

Here is a diff. I didn't write it; I need an acceptance review.
Go in order:
1. What was removed and why that might have mattered
2. What happens on unexpected data
3. What in the change goes beyond the stated task

The task was: <what was asked>.
If there are no problems, say so plainly.

For yourself, something else is useful — recording what you checked:

Turn this change into a list of what I should check by hand.
Short, as bullet points, so I can tick them off.

What not to check

So that attention is left for what matters, some things are worth deliberately leaving alone:

The last point matters most. Arguing with an AI about taste is wasted time: it will yield and the code will be no better.

What to look for

Checking that starts with the contents rather than the size. You read two hundred lines carefully when you should have stopped at --stat and asked a question.

Removed lines scrolled past. The most common way to miss a real problem.

The checklist turned into a ritual. Six steps in a row with no questions means you are looking without seeing. A proper acceptance includes at least one question.

Acceptance postponed. Five changes, then an examination of everything at once. Now go and find which of the five.

Cheat sheet