📄 Domain 3 · Task Statement 3.4

Determine When to Use Plan Mode vs. Direct Execution

⏳ 📊 Domain Weight: 20% 🎯 Difficulty: Core Concept 🔗 Scenarios: Complex Refactors & Rapid Development

One of the most critical architectural decisions in a Claude Code session is choosing the starting mode. Selecting the wrong mode leads to either unnecessary overhead for simple fixes or "code churn" and rework on complex architectural tasks. Mastering this distinction is essential for exam candidates.

📋 Contents

Real-World Analogy: The Shed vs. The Smart Home
Direct Execution: For Known Territory
Plan Mode: For Complex Discovery
The Decision Matrix: Choosing Your Path
Diagram: Behavioral Flows
Scenario Analysis: Real-World Cases
Anti-Patterns: When Modes Go Wrong
Exam Readiness & Key Takeaways

🏭 Real-World Analogy: The Shed vs. The Smart Home

🩹 Analogy — DIY Repair vs. Major Renovation

Imagine you are fixing things around your house:

Direct Execution (A Broken Fence Slat): You see the broken slat, you grab your hammer and a nail, and you fix it in 5 minutes. You don't need blueprints or a multi-phase strategy. You just "do it."
Plan Mode (Converting the Basement into a Smart Home Hub): You need to consider plumbing, electrical layout, server rack placement, cooling, and integration with existing HVAC. If you just start drilling holes in the floor, you'll inevitably hit a pipe or realize you didn't leave room for the wiring. You need a plan first.

In Claude Code, Direct Execution is your hammer; Plan Mode is your architectural blueprint.

⚙ Direct Execution: For Known Territory

Direct Execution (the default mode when you start claude) is optimized for speed and straightforward implementation. In this mode, Claude analyzes the request and begins proposing or making file changes immediately.

Best For:

Familiar codebases where you know the structure well.
Tasks with a well-defined outcome (e.g., "Add a 'middle_name' field to the User model").
Single-file changes or small, localized modifications.
Bug fixes where the root cause is already identified.
Low-risk tasks with minimal cross-module dependencies.

CLI — Direct Execution Trigger

# Starting a session in direct mode
$ claude "Add a logout button to the Header component"

# Claude responds by immediately reading Header.tsx and proposing the edit.

📝 Plan Mode: For Complex Discovery

Plan Mode (invoked via claude --plan, claude -p, or typing /plan in a session) forces a two-phase execution. Claude first explores the codebase and proposes a detailed "Implementation Plan" without touching any files. Only after you approve the plan does Claude begin the work.

Best For:

Unfamiliar codebases that require extensive exploration.
Large-scale changes spanning dozens of files (e.g., "Migrate the entire repo to TypeScript").
Architectural changes with infrastructure implications.
Tasks where multiple valid approaches exist and need evaluation.
Workflows involving complex multi-agent handoffs or multiple MCP servers.

💡 Efficiency — Strategy Over Speed

While Plan Mode takes longer to start, it often finishes correctly on the first try. Direct Execution in a complex codebase can lead to "code churn" where Claude keeps fixing its own mistakes because it didn't understand the full dependency graph before starting.

📊 The Decision Matrix: Choosing Your Path

Use this matrix to determine the optimal starting point for any task. On the exam, scenario questions will often hinge on these variables.

Variable	Choose Direct Execution If...	Choose Plan Mode If...
Codebase Familiarity	High: You wrote the code or work in it daily.	Low: New repo or "legacy" module you haven't seen.
Scope of Change	Narrow: 1-5 files affected.	Broad: 10+ files or cross-service changes.
Task Definition	Clear: Requirements are precise and unambiguous.	Ambiguous: Requires research and architectural options.
Risk Profile	Low: Simple UI fix or internal helper update.	High: Database migration, auth changes, infra updates.
Dependencies	None/Few: Isolated functionality.	Many: Changes affect multi-agent pipelines or shared libs.

🕐 Diagram: Behavioral Flows

Figure 1 — Direct Execution vs. Plan Mode Flow

💻 Scenario Analysis: Real-World Cases

🎓 Exam Scenario — The Migrating Developer

Scenario: You are tasked with migrating an e-commerce platform's legacy payment module (C++) to a new microservice (Go). The codebase of the payment module is unfamiliar, and there are 120 interconnected files with complex business logic.

Correct Answer: Choose Plan Mode. The complexity (120 files), architectural shift (C++ to Go), and lack of familiarity make starting with direct edits extremely dangerous and likely to produce broken logic.

🎓 Exam Scenario — The Maintenance Ticket

Scenario: A Jira ticket arrives: "Change the primary button color from #3B82F6 to #1D4ED8 in the global CSS theme file." You have worked in this project for 2 years.

Correct Answer: Choose Direct Execution. The task is well-defined, extremely narrow (one file), and in a highly familiar codebase. Plan Mode would be an unnecessary waste of time and context.

⛔ Anti-Patterns: When Modes Go Wrong

⛔ "Cowboy" Direct Edits

Starting in direct mode for a task that affects core authentication. Claude begins changing files, hits a naming conflict, tries to fix it, and eventually cascades into 50+ changes with no coherent strategy. Result: Broken PR.

⛔ Over-Planning Simple Fixes

Using `/plan` for a typo change. Claude spends 2 minutes "exploring" the directory structure and "proposing" to change one character in one file. Result: Developer frustration and token waste.

⛔ Not Reviewing the Plan

Triggering Plan Mode but clicking "Approve" without reading the proposed steps. If the plan is flawed, the execution will be flawed. Plan Mode is for collaboration on strategy.

⛔ Reacting to Complexity with Speed

Encountering a complex error in Direct Execution and continuing to "guess" fixes instead of immediately switching to Plan Mode to reset and analyze the underlying architecture.

✅ Exam Readiness & Key Takeaways

Plan Mode is for Discovery: Use it when you don't fully understand the "how" or the "where" of the solution.

Direct Execution is for Delivery: Use it when the path to the solution is obvious and localized.

Risk is a Major Factor: Any change to critical systems (Auth, DB, Production Config) justifies Plan Mode, even if the change is small.

Switching is Allowed: You can start in direct mode and pivot to `/plan` if the task proves more complex than initially thought.

Approvals Matter: The key differentiator of Plan Mode is the human-in-the-loop checkpoint before file system mutations occur.

Previous Task ← Task 3.3: Path-Specific Rules

Next Task Task 3.5: Iterative Refinement →