3.4 Plan Mode vs Direct Execution

When you give Claude Code a task, it can take one of two stances. It can dive straight in and start changing files — direct execution. Or it can first explore the codebase, think through approaches, and propose a plan WITHOUT touching anything — plan mode. Task Statement 3.4 is about choosing correctly between them, and the key insight is that the choice hinges on something specific that's easy to get wrong.

Here's the analogy. If your kitchen tap is dripping and you know exactly which washer to replace, you just do it — direct execution. But if you're renovating the whole kitchen — moving plumbing, choosing a layout, deciding where appliances go — you'd be reckless to start swinging a hammer before you have a plan. You'd measure, sketch options, and decide on an approach first. Plan mode is that measure-and-sketch phase: Claude reads and analyzes the codebase and proposes an approach, but makes no changes until you approve.

The trap — and the single most important idea in this lesson — is what actually triggers plan mode. People assume it's about DIFFICULTY: hard task → plan mode, easy task → just do it. That's wrong. The real trigger is AMBIGUITY and scope: how many valid approaches are there, how many files will change, are there architectural decisions to make? A genuinely HARD bug with one clear fix is direct execution; an EASY-sounding change that touches the architecture in several possible ways needs plan mode. Difficulty and ambiguity are different axes.

Let's make the decision concrete. PLAN MODE is for tasks with large scope or open design questions: large-scale or architectural changes, situations with multiple valid approaches, multi-file work that needs a consistent strategy, or anything requiring real codebase exploration before you commit. In plan mode Claude reads and analyzes safely, then proposes — so you catch a bad approach BEFORE it's written into dozens of files, avoiding costly rework.

DIRECT EXECUTION is for well-scoped, well-understood changes: a single-file bug fix with a clear stack trace, adding one validation check, a change where the approach is obvious and the blast radius is small. Reaching for plan mode here would just add ceremony to something you could simply do.

There's also a HYBRID worth knowing: plan THEN execute. A library migration is the classic case — you use plan mode to design the migration approach (which is genuinely ambiguous and spans many files), then switch to direct execution to apply the agreed plan file-by-file. Plan for the thinking, execute for the doing.

Plan mode connects to something from Domain 1: subagents and context preservation. When Claude plans a non-trivial change, it often needs to UNDERSTAND the codebase first — and that exploration can be verbose, pulling in lots of file contents. If all that discovery output landed in the main conversation, it would bloat the context before the real work even started.

That's where the Explore subagent comes in (you met the built-in subagents in Domain 1.3). During plan mode, Claude can delegate the verbose discovery phase to the Explore subagent, which reads and searches in its OWN isolated context and returns only a concise summary. The main conversation gets the understanding without the clutter — the same context-isolation benefit from Lesson 1.3, now serving the planning phase. This is why plan mode plus Explore is a powerful pairing for multi-phase tasks: you preserve main-context budget for the actual implementation.

The 3.4 traps almost all stem from one confusion: mistaking difficulty for the trigger, or hesitating to commit to plan mode when complexity is already stated. Anchor on 'ambiguity and scope decide, not difficulty.'

The signature trap: a task is described as clearly large and architectural (restructure a monolith, a 45-file migration), and one tempting answer says 'start with direct execution and switch to plan mode only if you hit unexpected complexity.' That's wrong — the complexity is ALREADY STATED in the requirements, so you choose plan mode UP FRONT. Waiting to discover complexity you've already been told about risks exactly the costly rework plan mode exists to prevent. Conversely, don't over-apply plan mode: a single-file fix with a clear stack trace is direct execution, even if the underlying bug is hard to understand.

You now know the plan-vs-direct decision, the ambiguity-not-difficulty trigger, the hybrid pattern, and how the Explore subagent supports planning. The exercise has you classify tasks and feel the difference between the two stances.

Plan mode is about HOW to approach a task. The next lesson, 3.5, is about how to ITERATE when Claude's first attempt isn't right — the refinement techniques that turn a rough result into a correct one.