Plan First, Then Code
Before the agent changes a file, ask it for a plan: which files it will touch, what it will change in each, how it will test the change, and what it is unsure of. A plan takes a minute to read and a sentence to correct. The same mistake found in a diff costs a discarded run, a second run and your reading of both.
For any task bigger than a few lines, the plan is the cheapest review you will do. It is also the review people skip most often, on exactly the tasks where it would have caught the most.
Asking for a Plan
The request is short: "read the relevant files and propose a plan; change nothing yet." The answer should be a list, not code. As of 2026, several agents have a read-only planning mode that enforces "change nothing" with a permission instead of a request, the difference Chapter 3 drew between an instruction and a rule the tool checks. Use the mode where your tool has one. Where it does not, the request works most of the time, and the diff tells you when it did not.
Keep the plan in words. A plan that already contains code is a diff in disguise, and reading it costs what reading the diff would; worse, its code is easy to approve without reading because it arrived labelled as a plan. Ask for the files, the change in each described in a sentence, the tests and the open questions. If the agent sends code, ask again for a list.
Reading a Plan
A plan gets four checks. The files: is booking on the list, since the cancellation screen must change with the rule, and is pricing on it, since it is out of bounds? The approach: one shared value, or a configurable refund-policy system that nobody asked for? The tests: new ones on both sides of the boundary, or only the old ones edited to the new number? And the open questions: anything the task left unsettled should appear here, not in the diff.
Here is the plan the agent proposed for the refund task, with your three corrections beside it.
Plan: change the refund window to 12 hours Files refunds FULL_REFUND_WINDOW: 24 h → 12 h refunds tests update expectations that assume 24 h gym settings add an optional refund window per gym Approach Add a policy object that reads the gym's own window and falls back to the default, so each gym can set its own window from now on. Tests Update the existing expectations to the 12-hour values. Open questions None.
"Open questions: none" deserves a second look too. The task answered the existing-bookings question, so none is plausible here; on a task that had not answered it, "none" would be the most worrying line in the plan.
The approach check deserves the most care, because it is where an agent's habits show. A per-gym policy object is not a strange choice for a model: configurable rules are common in the code it learned from, and "make it configurable" reads as good engineering. For Cragmoor it is a product decision nobody made, per-gym refund windows, arriving as an implementation detail. The plan is the one moment when that decision is a line of text you can strike out, instead of sixty lines of code you have to find, read and remove.
Correcting It
One specific message carries all three corrections: "also booking, whose screen shows the deadline; no configuration system, one shared value in refunds; add tests on both sides of the boundary, at 11 hours 59 minutes and 12 hours 1 minute before the class." Corrections at this stage cost nothing, because no code has to be thrown away and no diff has to be read twice. The agent revises the plan, you read the revision, and only then does it touch a file.
The revised plan is shorter, which is a good sign in itself.
Files
refunds one shared window; the deadline reads it
booking the cancellation screen reads the same
deadline
refunds tests new: 11 h 59 min and 12 h 1 min before
the class; update the 23-hour and
second-zone expectations
Approach
No new types. One value, used in two places.
Open questions
None; the task settles which bookings the rule covers.
Read it against the task once more, then approve it. The next topic cuts this plan into three steps, and the plan for each step is shorter still: step three's names two files and fewer than 20 lines.
The Arithmetic
A wrong plan costs a minute of reading and one message. A wrong diff costs the agent's run, your reading of a couple of hundred changed lines, the discard, and a second run with its own reading. The ratio is large on any task, and it is largest on the changes you are tempted to skip planning for, the ones that look simple. The refund change looks like one number. Its plan is where booking, the boundary tests and the unwanted configuration system surface, each for the price of a sentence.
A Plan Is Generated Too
The plan is the agent's text about what it intends, not a guarantee of what it will do. The diff can depart from it as the agent learns things mid-run, or simply because generating the plan and generating the code are two separate passes. You compare the two in review, which is one of Chapter 6's questions. A good plan is a reason to read the diff with expectations, never a reason to read it less. Chapter 6 opens on exactly this case: an approved plan of two files and under 20 lines, and a diff of six files and about 140.
The comparison is mechanical and quick. Put the plan's file list next to the diff's file list and look at the difference in both directions: files the diff touched that the plan never named, and files the plan named that the diff never touched. Then do the same for the tests the plan promised. Most departures show up in that minute, before you read a single changed line, and each one is a question to settle before the rest of the review.
Saving the Plan
Write the agreed plan to a file. It becomes the handoff note if the session drifts (Chapter 4), your checklist when you read the diff, and the first draft of the pull request description, whose claims Chapter 13 checks against the diff. A plan that lived only in the chat is gone when the session ends, and may not survive a compaction before that.
Keep the file out of the commit unless the team wants plans in the repository; a scratch directory that git ignores is enough. What matters is that the plan exists somewhere you and the next session can read, and that it is the version you approved, not the agent's first draft.
The task is yours: what must be true when the work is done, written before the agent sees the code.
The plan is the agent's: how it intends to get there, written after reading the code. Correct the plan against the task, and if the plan shows that the task was wrong, fix the task first.
- "Planning slows the agent down." It adds a minute and removes the most expensive outcome there is: a confident diff built on the wrong approach.
- "If the plan is good, the diff will match it." The agent can depart from the plan as it learns things mid-run. The plan sets expectations to check, not a contract the agent is bound by.
- "Plans are for big tasks." The refund change looks like one line, and its plan is still where
bookingand the boundary tests surface. - "A good plan shows it understands the code." It shows the agent can write a plausible plan. Whether the files it names are the right ones is your check.
- "Reading the plan replaces reading the diff." The plan is intent. Only the diff is the change (Chapter 6).
- Ask for files, approach, tests and open questions before any change bigger than a few lines. A wrong approach is cheapest to fix before it exists.
- Use a read-only planning mode where your tool has one. "Change nothing" then holds by permission, not by request.
- Correct the plan in one specific message: name the missing file, the unwanted mechanism and the missing test.
- Save the agreed plan to a file. It is your review checklist and the handoff if the session runs long.
Knowledge Check
The agent's plan for the refund change lists refunds, its tests and a new per-gym setting. What is the most important problem?
- It misses
bookingand adds a configuration system nobody asked for - It lists the refunds tests, which should not change in a change to the rule
- It changes the window constant rather than computing the window from the timetable
- It names files rather than functions, which makes the plan too vague to check
Roughly what does a wrong approach cost if it is caught in the plan instead of in the diff?
- About the same, since the agent has to redo the reasoning either way
- A minute of reading and one message, instead of a run, a read and a discard
- More, because a correction to a plan restarts the whole session from scratch
- Nothing either way, because the tests will catch a wrong approach when they run
The plan was good and you approved it. How should that change the way you read the diff?
- You can skim it, since the plan already showed what the change would contain
- You can skip the tests in it, since the plan listed which tests would change
- You read it in full, checking it against the plan in both directions
- You read only the files the plan named, since nothing else should have changed
When is it reasonable to skip the plan?
- When the change looks like one number, such as a window going from 24 to 12
- When the agent has a good record on this codebase from earlier tasks this week
- When the change is a few lines whose diff you could read faster than a plan
- When the tool has no read-only planning mode, so a plan cannot be enforced
You got correct