Plan mode or direct execution

Asking Claude Code to “move the monolith to microservices” and letting it edit from minute one is a recipe for rework: dependencies surface late and architecture decisions get made by accident. Asking for a plan to fix a typo is a waste of time. The question is when planning is worth it.

The two modes

In plan mode, Claude explores the code and designs an approach without modifying anything: it’s read-only exploration. You review it, adjust it, and only then is it executed. In direct execution, Claude reads and edits in the same step.

Plan mode	Direct execution
Several valid ways to do it	One clear path
Architecture decisions (service boundaries, choosing between integrations with different infrastructure)	A narrow, well-understood change
Many files (a library migration touching 45)	One file, one function
A vague request with no data (“make checkout faster”)	A bug with a clear stack trace, a typo breaking the deploy, adding a date validation

There’s no fixed file threshold. What decides is whether there’s ambiguity and alternatives to compare. If the complexity is already in the requirement (“restructure authentication across 15 files”), planning starts at the beginning; you don’t wait to “see if surprises show up”.

The hybrid pattern

The most common approach combines both: the plan-then-execute pattern. First you plan in plan mode (map the uses of the old library, decide the replacement pattern and the edge cases) and, with the plan approved, you switch to direct execution to apply it file by file. Re-planning each file breaks the consistency the plan was meant to give.

And the other way round: if complexity that wasn’t in the requirement appears in the middle of direct execution (a simple rename that turns out to involve reflection and six packages), stop and switch to plan mode to map the usages before continuing.

Protecting the context while exploring

Exploration produces a lot of output: file listings, dependency graphs, code snippets. If all of it enters the main conversation, the window fills up and the following answers get worse. The Explore subagent is a built-in, read-only subagent designed for searching and analyzing code: it does the exploration in its own context and returns only a summary. Its advantage isn’t special access or a different model, but isolation.

The usual traps

• “Start directly and let the implementation reveal the boundaries”: it discovers the dependencies when there’s already work to undo.
• “Direct execution with very detailed instructions”: it assumes you already know the right structure without having explored.
• “Go direct and switch to plan if complexity appears”, when the complexity is already known.
• Using plan mode for everything, trivial changes included.
• Reading files in the main conversation to “have everything at hand” during a long exploration.

In the exam

Look for the signals in the scenario: architecture decisions, several options, dozens of files or a request with no data call for plan mode; a one-line change with a known cause calls for direct execution. If exploration threatens to fill the context, the answer adds the Explore subagent.