Deciding When Plan Mode Earns Its Cost
You have three tasks queued for a Claude Code session today:
- Task A: rename a poorly-named local variable in one function, in a file you wrote last week.
- Task B: migrate the notification service from polling to webhooks, touching an unknown number of call sites across the codebase.
- Task C: fix a typo in a log message string.
- For each task, say whether you'd use plan mode, and justify it using the specific signals (not just "it's small" or "it's big").
- Explain the actual mechanism by which skipping plan mode on Task B could cost more than the time plan mode would have taken.
- If you started Task B without plan mode and, three files in, discovered a shared retry helper used by two unrelated services, what's the right move at that point?
1. Per-task judgment:
- Task A: skip plan mode. You already know the exact file, the exact function, and the diff is describable in one sentence. There's no ambiguity about approach and the blast radius is one function you wrote and understand.
- Task B: use plan mode. The scope is explicitly unknown ("unknown number of call sites"), it touches a service other code depends on, and there is more than one reasonable approach (migrate everything at once vs. scope down to specific consumers first). This is exactly the combination — ambiguity plus blast radius — that makes the round trip worth it.
- Task C: skip plan mode. Trivially small, single file, zero ambiguity about the fix.
2. Why skipping plan mode on Task B can cost more:
Without plan mode, Claude starts editing based on its first read of the scope. If that first read misses a shared dependency, the wrong assumption doesn't stay contained — it gets baked into every downstream edit made "for consistency": tests written against the wrong interface, imports pointed at the wrong module boundary, error handling shaped around the wrong failure mode. Discovering the mistake later means untangling a diff that mixes correct and incorrect changes across many files, which costs far more review and rework time than the single round-trip a plan would have cost. In a plan, the same wrong assumption costs nothing to reject — you're rejecting a paragraph of English before any file has changed.
3. The right move mid-edit:
Stop making further edits and get this specific discovery down in
writing before deciding how to proceed — effectively converting to a
plan-mode-style checkpoint mid-task: "here's what I've found — a
shared retry helper used by two other services. Should I scope this
migration to notifications only with a thin compatibility adapter, or
is changing the shared helper's signature actually in scope?" Getting
that decision made explicitly, before more files are touched, is
cheaper than discovering the same ambiguity after five more files have
been edited under the wrong assumption. This is also a good moment to
use Esc and /rewind if the edits so far are already inconsistent
with whichever direction you choose.
Share this question