When not to plan: the one-sentence-diff test

Lesson 4.2 gave you four ways into plan mode and 4.3 taught you to read the plan that comes out, and the predictable next move is to adopt it as a policy: every change goes through a plan now, because planning is careful and careful is good. Then you use it to add a log line, and watch Claude read six files, write four hundred words about them, and propose the one-line edit you had already typed into the prompt.

Knowing how to gate a change behind a plan is worth nothing without knowing which changes deserve the gate.

Planning is not free caution

The documentation does not present plan mode as strictly better. It presents it as a trade, in one sentence:

Plan mode is useful, but also adds overhead. — Best practices

Name the overhead concretely, because "overhead" is easy to nod at and ignore. Planning is an exploration phase you have deliberately extended: Claude reads files, runs commands to look around, and writes a document. Every message, every file read and every command output lands in the same window the implementation is about to run in — that was Lesson 3.1's whole argument. You do not have to take the cost on faith, either: Claude Code ships a setting, showClearContextOnPlanAccept, whose documented reason for existing is that planning is expensive.

Planning can use a lot of context, so this key adds a first option to that menu, Yes, clear context and …, that approves the plan, clears the conversation context, and starts implementing from the plan alone. — Settings reference

Lesson 4.3 covered that option as a plan-approval decision. Read it here as evidence about the thing being approved: a feature exists to throw away the context planning produced, because on a real task there is enough of it to be worth throwing away. So the question is never "would a plan help?" — a plan nearly always helps a little. It is whether it helps more than the window it spends.

The test: could you describe the diff in one sentence?

The docs give a rule and a threshold in the same breath:

Planning is most useful when you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified. If you could describe the diff in one sentence, skip the plan. — Best practices

The trap is in the word diff. It is not "could you describe the task in one sentence" — almost every task is one sentence, which is why people apply this test and conclude they should always plan.

"Fix the login bug" — the request Lesson 2.4 rewrote into a symptom, a location and a failing test — is one sentence; its diff is not, because you do not yet know which file, which function, or whether the fix is a null check or a token refresh you have to design. "Rename getUserById to findUserById everywhere" is one sentence and so is its diff — every changed line is the same change, and a plan for it would be a document describing a rename.

The docs name the easy end of that scale explicitly:

For tasks where the scope is clear and the fix is small (like fixing a typo, adding a log line, or renaming a variable) ask Claude to do it directly. — Best practices

The three signals that a plan pays

Two of the three documented signals are facts about the world you can check in seconds. The third is a fact about you.

The docs join these with or, not and, so one signal is enough to qualify a task — but note what they do not say: that one signal settles it. Planning is most useful when a signal is present, and the same passage tells you to skip anyway if the diff is one sentence. Of the three, the first is the only one Claude cannot help you with; the other two are questions about a repository, exactly the kind Lesson 4.1 said to hand over. In practice, asking "which files would this touch?" in default mode — labelled Manual from v2.1.200, above this course's pin (Lesson 1.3) — is a smaller request than a planning cycle, and its answer tells you whether to start one.

The cheap alternative: try it, then rewind

On a small, reversible change there is a second gate, and it costs nothing to set up because it is already there:

Instead of carefully planning every move, you can tell Claude to try something risky. If it doesn't work, rewind and try a different approach. — Best practices

The gate is already in place before you decide anything, because every user prompt creates a new checkpoint (Checkpointing). That inverts the order of operations from Lesson 4.2: instead of spending context to find out what a change would look like, you spend one attempt to see the change itself — a real diff instead of a description of one — and throw it away if you dislike it. Lesson 3.4 taught the rewind menu; this is the case where you reach for it on purpose rather than in recovery.

It is a bounded net, and one bound decides which changes it suits: a rewind does not cover files a Bash command wrote — a migration script, a code generator, a formatter run — nor a subagent's edits. So try-then-rewind is a gate only when the attempt runs through Claude's own file tools; when it does not, commit before the bulk operation instead. Lesson 3.4 lists what a checkpoint leaves out, Lesson 11.4 builds the full channel table, and Lesson 4.5 says what covers the rest.

So the rule of thumb this suggests, in the product's voice rather than the docs': try-then-rewind is the gate when the change is cheap to make and cheap to judge; a plan is the gate when the change is expensive to make or expensive to judge. A rename is cheap on both counts. A change to how sessions are stored is expensive on both.

The exploratory case, where a plan is the wrong instrument

There is a third category, and it is not "too small to plan" — it is too undefined to plan:

Sometimes you should skip planning and let Claude figure it out because the task is exploratory. — Best practices

A plan commits to an approach. When the point of the work is to discover which approaches exist, committing early is the failure, not the safeguard — and the under-specified prompt becomes a documented technique rather than a lapse:

Vague prompts can be useful when you're exploring and can afford to course-correct. — Best practices

Read the condition on the end of that sentence. Can afford to course-correct — the cost of a wrong direction has to be a rewind and a re-prompt, not a half-migrated database.

The clearest evidence that planning is not the default is the documented recipe for the most common task there is. Fixing a bug in Common workflows is three conversational steps and no planning phase at all: share the error (I'm seeing an error when I run npm test), ask for fix recommendations, then apply the one you picked. Your judgement is exercised at step two — the same gate a plan gives you, arrived at through a conversation instead of a mode.

A worked comparison

Same repository, same afternoon, five requests.

Row two is the one worth arguing about, and it is where the one-sentence-diff test earns its keep: "multiple files" is a signal, not a verdict. A rename touching forty files is still a diff you can describe in one sentence, and a plan for it will be forty lines saying the same thing forty times. Row four is Lesson 4.1's reminder that some tasks never leave the gather-context phase — nothing is planned because nothing has been decided yet, and once the cause is known the fix usually lands in row one.

Developing the judgment

The docs are unusually direct about the status of all of this:

The patterns in this guide aren't set in stone. They're starting points that work well in general, but might not be optimal for every situation. — Best practices

So the one-sentence-diff test is a default, and you are expected to overrule it with evidence from your own sessions. Two questions, asked afterwards, calibrate it:

• After a planned change: did the plan tell you anything you did not already know? If three plans in a row only restated your own instructions back to you, you are planning too low.
• After an unplanned change: did you have to correct the approach — not the code, the approach — more than once? Lesson 3.3's rule was that two failed corrections mean clearing and re-prompting. Here it also means the task had a signal you missed, and the re-prompt should be a plan.

The phase people actually skip is the one after the code exists. Lesson 4.5 is about committing.

Checkpoint

1. A colleague says "always use plan mode, it's just being careful." Name the cost you would put on the other side of that trade, and cite where the docs acknowledge it.

   ›Show answerAnswer

   The cost is context. Planning is an exploration phase you have deliberately extended, and every message, file read and command output lands in the same window the implementation is about to run in. Best practices concedes the trade in one sentence: plan mode is useful, but also adds overhead.

   The stronger citation is a feature rather than a sentence. The settings reference documents showClearContextOnPlanAccept on the grounds that planning can use a lot of context, and what it adds is a first menu option that approves the plan, clears the conversation context, and starts implementing from the plan alone. Something is only worth throwing away when there is a lot of it. So the question is never "would a plan help?" — it nearly always helps a little — but whether it helps more than the window it spends.

2. You have been asked to rename a config key across roughly thirty files. One documented planning signal is present. Do you plan? Justify your answer with the test rather than the signal.

   ›Show answerAnswer

   No. The signal present is modifies multiple files, and the test overrules it: you can describe this diff in one sentence — every changed line is the same change, the old key becomes the new one — and the docs say that if you could describe the diff in one sentence, skip the plan. Multiple files is a signal, not a verdict, and a plan for a thirty-file rename is thirty lines saying the same thing thirty times.

   The trap the test is built to catch is the word diff. "Rename a config key across thirty files" is also one sentence as a task, and almost every task is, which is why people run this test and conclude they should always plan. Ask directly, then read the diff — which is also where the reassurance a plan would have given you actually comes from, and cheaper.

3. You want Claude to try an aggressive refactor of a module you might not keep. You choose try-then-rewind instead of a plan. What is the one property of the attempt that would make that choice wrong?

   ›Show answerAnswer

   Whether the attempt runs through Claude's own file tools. A rewind does not cover files a Bash command wrote — a migration script, a code generator, a formatter run — nor a subagent's edits, so if the refactor is going to happen via a shell codemod or be handed to a subagent, try-then-rewind is not a gate at all and you are trusting a net with a hole the size of the change.

   When it is Claude's file tools, the net is already there before you decide anything, because every user prompt creates a new checkpoint. When it is not, commit before the bulk operation instead. The rule underneath: try-then-rewind is the gate when the change is cheap to make and cheap to judge; a plan is the gate when it is expensive to make or expensive to judge.

4. Which of the three planning signals can you not delegate to Claude, and why are the other two worth asking about before you press Shift+Tab?

   ›Show answerAnswer

   Uncertain about the approach. It is a fact about you rather than about the repository, so there is nobody to ask — and the useful form of the check is whether you can name the approach at all, or can name two and cannot choose.

   The other two — does this modify multiple files, am I unfamiliar with this code — are questions about a repository, exactly the kind Lesson 4.1 said to hand over. Asking "which files would this touch?" in default mode, labelled Manual from v2.1.200, is a much smaller request than a planning cycle, and its answer tells you whether to start one. What the answer does not do is settle it: the docs join the signals with or, so one is enough to qualify a task, and the one-sentence-diff test can still tell you to skip anyway.