Domain 3 · Task 3.4
Plan Mode vs Direct Execution
Determine when to use plan mode vs direct execution.
Plan mode lets Claude Code investigate and design without making changes (Read/Grep/Glob only), then propose a plan you approve before any edits. Direct execution makes changes immediately. The choice is a complexity judgement made up front from the requirements, and the exam's trap answer is always "start direct and switch later."
Key concept
Architectural work, many files, or multiple valid approaches → plan mode. One clear, well-scoped change → direct execution. Judge from the stated requirements, not "wait and see." Combine: plan to investigate, direct to implement.
What you need to know
When to plan, when to execute
Plan mode is for complexity: large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications. Direct execution is for simple, well-scoped changes. The signals line up cleanly:
| Use plan mode when… | Use direct execution when… |
|---|---|
| Large-scale changes (dozens of files) | Single-file, well-scoped fix |
| Multiple valid approaches / architectural decisions | Clear, unambiguous change |
| Unfamiliar codebase needing exploration first | Clear stack trace → one obvious fix |
| A migration affecting 45+ files | Adding one validation conditional |
Plan mode enables safe exploration and design before committing, which prevents costly rework when there are architectural decisions to get right.
Complexity is judged from the requirements
The most important nuance: complexity is assessed from the stated requirements, not discovered by trial. If the task is "break this monolith into microservices across dozens of files with boundary decisions," the complexity is already on the table — that is plan mode. "Start direct and switch to planning later if it gets complicated" is the wrong answer precisely because it ignores that the scope is known in advance. Conversely, "fix this null-pointer bug at the line in this stack trace" is one clear change — planning it would be overhead.
The Explore subagent and the combined pattern
For verbose discovery, the Explore subagent isolates the noisy investigation output and returns a summary, preserving the main context window during multi-phase tasks. This composes with the standard workflow: plan mode to investigate and design → approve the plan → direct execution to implement. You are not forced to choose one mode forever — you plan when there are decisions to make, then execute directly once the approach is settled.
Exam traps
| The trap | The reality |
|---|---|
| Start every task in direct execution and switch to plan mode only if it turns out to be complex. | Complexity is judged from the requirements up front. If the scope is already large or architectural, choose plan mode from the start. |
| Plan mode is slower, so a well-scoped single-file fix should still be planned to be safe. | For a clear, unambiguous change (e.g. a bug with an obvious stack trace), direct execution is correct; planning is pure overhead. |
| Plan mode makes changes as it explores, so you must be careful about side effects. | Plan mode only investigates (Read/Grep/Glob) and proposes a plan — it makes no changes until you approve. |
| Verbose discovery must run in the main context, so long investigations inevitably exhaust the window. | The Explore subagent isolates verbose discovery and returns a summary, preserving the main context during multi-phase work. |
Practice scenario
Real questions from the bank that test this topic — the correct answer is highlighted.
Your team is debating when to use Claude Code's plan mode.
Which scenario benefits MOST from plan mode?
Why: Plan mode is most valuable when changes span multiple files with non-trivial design choices that benefit from human review before any code is touched. A clear-scope refactor (A) and a one-off bash command (D) are too simple to need a plan. An unknown-cause bug (B) needs adaptive exploration, not upfront planning — you can't plan what you don't yet understand. A multi-file feature with design decisions (C) is exactly where plan mode pays off: enough complexity to warrant a plan, enough structure to make one possible.
You've been assigned to restructure the team's monolithic application into microservices. This will involve changes across dozens of files and requires decisions about service boundaries and module dependencies. Which approach should you take?
Why: Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, and architectural decisions—exactly what monolith-to-microservices restructuring requires. It enables safe codebase exploration and design before committing to changes. Option B risks costly rework when dependencies are discovered late. Option C assumes you already know the right structure without exploring the code. Option D ignores that the complexity is already stated in the requirements, not something that might emerge later.
Build exercise
Route two tasks to the right mode
~30 min- 1Take a task with clear architectural scope (e.g. "split this monolith into two services touching many files") and enter plan mode.
Why: The stated scope already signals architectural complexity — plan before committing.
- 2Review the proposed plan and confirm no files were changed during exploration.
You should see: Plan mode produced a design with zero side effects, awaiting your approval.
- 3Approve the plan and switch to direct execution to implement the first step.
Why: This is the combined pattern — plan to design, direct to build.
- 4Take a second task that is a single-file fix with a clear stack trace and use direct execution immediately.
You should see: The fix lands without a planning round — planning would have been overhead.
- 5For a large unfamiliar area, delegate discovery to the
Exploresubagent and read only its summary.You should see: The main context receives a concise summary rather than the full investigation transcript.
Sources
Drill Claude Code Configuration & Workflows
Practice only this domain’s questions, untimed, with instant explanations.