Plan Mode: why I trigger it before any non-trivial task
Claude Code's default mode alternates reading, deciding and acting in the same loop: the agent can read a file and edit it right after, with no intermediate validation step. That works fine for a small, clear task. It gets risky as soon as the task is big enough that the agent picks, without saying so explicitly, an approach I wouldn't have chosen.
What Plan Mode actually changes#
In Plan Mode, the agent loses access to write and execute tools: it can read, search, explore, but not edit a file or run a command. It has to build its understanding of the problem with those tools alone, then present an explicit plan before I authorize the switch to execution. The key point isn't the restriction itself, it's when it kicks in: before the first edit, not after.
The real cost of a bad approach#
Without Plan Mode, a shaky approach is usually discovered mid-execution,
once several files have already been modified in a direction that then has
to be undone. The cost isn't only the time lost backtracking, it's the
difficulty of isolating, in the repo's current state, what came from the
good approach and what came from the bad one. With Plan Mode, that diagnosis
happens on text, before a single file has moved: fixing a plan costs a
re-read, fixing a half-finished refactor costs an entire git diff to
untangle.
The signal that makes me switch to Plan Mode by reflex: as soon as the task touches more than two or three files, or I'm not sure in advance which approach I'd pick myself. On a single-file task with one reasonable way to do it, Plan Mode adds nothing, it only slows things down.
What a good plan should show, not just state#
A plan that just announces "I'll modify X to do Y" isn't worth much: any plan can be phrased that way. What makes a plan verifiable is that it names the files involved, explains the choice made against the alternatives it ruled out, and explicitly flags points of uncertainty rather than smoothing them over. A plan that mentions no discarded alternative is often a plan that was never really compared to others, just written after the fact to justify the first idea that came up.
The limit: Plan Mode doesn't replace judgment#
Approving a plan without really reading it cancels the whole benefit of the mode: it's back to the default mode, with a purely formal confirmation step added on top. The point of Plan Mode isn't to add a checkbox, it's to force a real read before execution.
A well-written plan remains text produced by a probabilistic model: it can be coherent, detailed, and still rest on a false assumption about the existing code. Actually reading it, checking the factual claims it makes (does that file really exist there, does that function really have that signature), stays my responsibility, not something the mode guarantees on its own.
Where it overlaps with TDD#
Plan Mode's logic echoes real TDD with Claude Code: in both cases, the point is to force an explicit stopping point before the code heads in a direction, rather than discovering the problem once work is already under way. The red test before the implementation, the plan before the edit: same principle, applied at two different moments of the cycle.
What it changes day to day#
I cover Plan Mode in its own module in Claude Expert, because it's one of the habits that most clearly separates a productive session from one that drives into a wall without anyone noticing until several files have already changed. The rule I apply fits in one sentence: on any task where I'm not certain in advance which approach I'd choose myself, the plan comes before the code, never the other way around.