The Director's Review Checklist

Module 3, Lesson 3.3 reference card · print and keep next to your editor · concept

How to use this card. Print it. Tape it to the edge of your monitor for the first month. After 30–50 directed edits the five moves will collapse into a single automatic pass — but until then, run them explicitly, every time.

You are not reading code. You are reviewing the agent's work the way a director reviews any worker's output: against what you asked for, against the shape of what you got back, by asking the worker about anything unfamiliar, and by running the result.

The rule: you accept responsibility for the change, even though the agent wrote it.

Five moves. Every change. Every time. Including one-line ones.

Before you start

Goal in one sentence, in my own words. If I cannot state the goal, I cannot review the change against it. Restate it here even if it was in the prompt.
Goal

Move 1 — Check the shape

Look at the file list and diff size before you read anything
Did the agent change only the files I expected?
Is the change roughly the size I expected? (A one-line bug fix shouldn't be 80 lines.)
Did the agent add any new files I didn't ask for?
Did the agent delete any files I didn't ask to remove?
Anything unexpected in the shape

Move 2 — Read the agent's summary

The agent's plain-English claim about what it did
Does the summary describe what I asked for?
Does it mention things I did not ask for? (Those are scope creep.)
Does it mention removing or replacing something? (That deserves a follow-up — Move 3.)
Is the summary specific? “Made the changes” is too vague — ask for specifics.

Move 3 — Ask the agent about anything unfamiliar

Use the agent itself as your diagnostic tool
For any line, file, or concept I can't tell about: “What does this part do?” / “Why did you make this change?”
“What happens if I run this on an empty input? On a really large input? On a file with weird characters?”
“Are there any cases where this fix won't work?”
“Did you remove anything that was doing real work?”
Question I asked and what the agent said

Move 4 — Run the result

Tests passing isn't the same as “the change works”
I actually ran the change on a realistic input (not just the test).
If the change is supposed to fix a bug: I reproduced the bug myself first, then ran the fix, and confirmed it's fixed.
The output matches what I asked for — not just what the test wanted.

Move 5 — Iterate (if anything in 1–4 didn't satisfy you)

Tell the agent what's still wrong — don't try to fix it yourself
Phrase the iteration specifically. The agent wrote the change; the agent fixes it.
My iteration prompt

Decision

Accept — all five moves passed; the change does what I asked.
Revise — something didn't pass; I sent the agent the iteration prompt above.
Reject — the change is too far off to fix with one revision; start over with a tighter prompt.

The four failure modes

What you noticed Failure mode How a director catches it
Fix works here but won't generalize. Misplaced change Ask: “Will this work for similar cases I haven't shown you?”
The diff touches files you didn't ask about. Scope creep Move 1 (shape). Ask: “Did you change anything I didn't ask for?”
Something is missing that used to work. Silent deletion Ask: “What did you delete and why?” Plus Move 4.
Tests pass but real input still fails. Plausible wrong Move 4 — run on real input, not just the test.

The three objections and their honest answers

“This is too slow. I'll never get anything done.”

The five moves add a small amount of time per change. The bugs they catch take hours to days to recover from later. The math is not close.

“The agent is smart enough that I can skip this on small changes.”

Small changes are exactly where silent deletions and plausible-wrongs slip in, because reviewers pay less attention. Run the five moves every time.

“If I have to review every change anyway, why am I using an agent?”

Because reviewing a change is faster than making it. The agent still does the work — locating, planning, writing, running tests. You handle the review — the last, cheapest step in a pipeline whose expensive parts the agent absorbed.

Safety norms — keep in sight

  1. You accept responsibility for the change, even though the agent wrote it.
  2. Never let an agent run a destructive command on your behalf without confirming the command first. (rm -rf, git reset --hard, git push --force, anything that deletes files or rewrites history.)

Print this page. Use it.