Home › Study guides › CCAR-F › Domain 3 › Lesson 3.4

CCAR-F · Domain 3 · 20% of the exam · Lesson 3.4 · 23 min read

Plan mode versus direct execution

When Claude Code should explore and plan before editing, when it should just make the change, and how the Explore subagent keeps discovery out of your context.

Written against task statement 3.4 of the official CCAR-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

3.4.1 Why "just start coding" is sometimes the expensive choice

Picture a development team that uses Claude Code, Anthropic's command-line coding assistant, for its everyday work: writing code, refactoring, debugging. Follow the team through one ordinary week. On Monday a crash report arrives with a stack trace, the error report that names the exact file and line that failed. It points at line 42 of billing/invoice.py, where an empty value reaches format_invoice(). On Tuesday a product manager asks that schedule_delivery() in orders/delivery.py reject a delivery date earlier than the order date.

On Wednesday the lead announces the big one. The team's monolith, one large application that does everything, is to be split into microservices, small separate programs that each own one job. The first three are orders, billing and notifications. That means touching dozens of files and deciding where each service boundary goes.

If you asked a contractor to do all three jobs, you would expect different behaviour for each. For the crash and the date rule, you want them to fix it and move on. For the split, you would be alarmed if they opened the first file and started cutting. You would expect them to read the code, map what depends on what, and show you a design before a single line moves. Cutting without that map is how a two-week job becomes a two-month one.

Claude Code works in the same two ways, and you choose which. In direct execution, Claude reads what it needs, edits files and runs commands straight away. In plan mode, Claude explores and writes a plan first, and Claude Code, the program that runs the model, blocks every edit until you approve that plan. This lesson is about picking the right mode for the task in front of you. It also covers a third tool, the Explore subagent, which keeps the reading phase from swamping your conversation.

3.4.2 Two modes, one switch

Before choosing between the modes, you need to know exactly what each one allows. The whole decision rests on one difference: whether Claude may change files yet.

Direct execution is not a mode you turn on. It is Claude Code's ordinary way of working: you describe the change, and Claude reads the files it needs, edits them, runs the tests and reports back. Whether it stops to ask you before each edit depends on the session's permission mode, the setting that decides what Claude Code may do without asking you first. Either way, the work moves straight from reading to changing. For the Monday crash that is exactly right, because the stack trace already says where the problem is.

Plan mode is one of those permission modes, and it tells Claude to research and propose changes without making them. Claude can read files and run commands to explore, and it writes a plan, but it does not edit your source files. Claude Code keeps edits blocked until you approve the plan. The controls are few:

Memorise the first three rows: they are the three ways in. Recognise the last two as the ways out, with and without a decision.

When the plan is ready, Claude presents it and asks how to proceed. You can approve it and let Claude edit, approve it but review each edit yourself, or choose "No, keep planning" and say what to change. Ctrl+G opens the proposed plan in your text editor, so you can rewrite parts of it before deciding. Approving exits plan mode, so from that point the implementation runs as direct execution. That approval step is the whole point: a human agrees the design before any file depends on it.

Back to the Wednesday split. The lead starts with claude --permission-mode plan and asks Claude to map how orders, billing and notifications are tangled together, then propose service boundaries. Claude finds that billing calls three functions inside orders directly, and that notifications reads the orders database table. Its plan has three steps. First, give orders a read-only interface, a fixed set of requests other services use to ask it for data. Then move notifications onto that interface and extract it, and finally split billing behind a second interface. Not one file has changed. The team argues about the billing boundary, edits the plan, and only then approves it.

3.4.3 Reading the task: which mode does it deserve?

Here is the skill the exam tests: given a task described in a sentence or two, which mode do you pick, and what in the description told you? The three tasks in the team's week make the signals visible.

The Monday crash is a single-file bug fix with a clear stack trace. The location is known, the fix is small, and there is one obvious way to do it. The Tuesday change is one validation check in one function, a change you can state in a sentence: "if the delivery date is before the order date, return an error." Both call for direct execution. Plan mode here is ceremony: it adds a research phase and an approval step to a change that needs neither. Anthropic's best-practice guide says the same: when the scope is clear and the fix is small, ask Claude to do it directly.

The Wednesday split has every plan mode signal at once. It is large-scale, touching dozens of files. It is architectural: where the service boundaries go shapes everything built after it. It has multiple valid approaches: extract notifications first, or billing first, or change how the services talk to each other before splitting anything. And the code is tangled in ways nobody on the team fully remembers. Any one of these signals is a reason to plan; all four together make direct execution reckless.

Memorise which way each signal points. The row people overlook is "different infrastructure requirements", and the split contains a live example of it.

Notifications needs to know when an order is placed, and there are two sound ways to tell it. Orders could call notifications directly over the network. Or orders could post an event to a message queue, a separate piece of software that holds messages until the receiver collects them. The code change looks modest either way. But the queue is new infrastructure that someone must run, monitor and pay for, so choosing between the two is an architectural decision. It belongs in plan mode, however small the edit looks.

3.4.4 What planning actually buys: no costly rework

It is tempting to think of plan mode as a seat belt, a way to stop Claude from breaking things. That is part of it, but the bigger value is economic. When exploration and design come before any change, problems surface while they are still cheap to fix. That spares you costly rework: redoing changes that were built on a wrong assumption.

Consider the Wednesday split run in direct execution. Claude opens the notifications module and starts extracting it. Forty minutes in, it discovers that notifications reads the orders table directly. Now there is a half-extracted service and a dependency nobody planned for. The team can bolt on a workaround, or undo the work and start again with a better boundary. Either way the discovery came AFTER the edits, and every edit made on a wrong assumption is rework. Multiply that by several surprises across dozens of files and the cost runs to days.

In plan mode the same discovery happens during exploration, before any file changes. The plan absorbs it: "notifications depends on the orders table, so give orders a read-only interface first." The discovery costs a line in a plan instead of a day of undoing. This is what safe exploration means: Claude can open and trace anything and try designs out in words, while Claude Code keeps every file unedited. The approval step then puts a human in front of the design, where a wrong boundary costs a conversation rather than a rewrite.

The same timing argument rules out a tempting half-measure: start directly and switch to plan mode only if the split turns out to be complicated. The complexity is not something that might appear later; the task description already says dozens of files and undecided boundaries. Waiting for the first surprise means the surprise has already cost you edits.

3.4.5 The Explore subagent: discovery without drowning

Reading before designing has a hidden cost. Everything Claude reads lands in the conversation's context window, its working memory: every message, every file it opened, every command output. That memory is finite, and Claude's performance drops as it fills; it may start forgetting earlier instructions or making more mistakes. Mapping the monolith might mean reading sixty files. Do that in the main conversation, and by design time the window is stuffed with file contents that were useful once and are now dead weight.

The split is a multi-phase task: map, then design, then implement. If the mapping fills most of the window, the later phases start short of room, and a long session can run out of it altogether. That is context window exhaustion. It is a problem of WHERE the reading happens, not of how much reading the task needs.

The fix is to move the reading somewhere else. A subagent is a helper that Claude starts for one job; it works in its own context window, with its own tools, and hands back a result. Claude Code has a built-in one for this job, the Explore subagent. Its tools are read-only (Write and Edit are denied), and its purpose is finding files, searching code and exploring a codebase. Claude delegates to it on its own when it needs to understand code without changing anything, and picks a depth: quick, medium or very thorough. You can also ask for it by name, as in "use the Explore subagent to map how orders and billing depend on each other".

The subagent reads the sixty files inside ITS context window and returns only a summary: which modules call which, where the shared tables are, which three functions cross the boundary. The main conversation keeps a page of findings instead of sixty files of raw content. Think of sending a colleague into the archive room. They come back with a one-page memo, not a trolley of boxes.

On the split, the lead asks for exactly that from inside the plan mode session. The mapping runs in the Explore subagent, the summary comes back, and Claude designs the boundaries from it. After approval, the implementation phase starts with most of the window still free. The reverse holds too: for the Monday fix, where Claude reads one file, a subagent only adds delay. Reach for one when discovery would produce verbose output you will not need again, and the result can come back as a summary.

3.4.6 Combining the two: plan, then execute

The modes are not rivals, and the best answer to a big task is usually both, in order. The classic case is a library migration affecting 45+ files. A library is a ready-made package of code that many files rely on. Say the team's next job is to replace the library its code uses to call other services over the network, and that library appears in 48 files. Nobody knows every place it is used. The two libraries also differ in how long they wait for an answer and when they retry, and some modules wrap the old library in shared helpers that others depend on.

Running the whole job in plan mode gets you a plan and nothing else, because plan mode never edits. Running it directly means learning about the retry difference on file 31 and going back over the first 30. The right shape is plan mode for the investigation and direct execution for the implementation.

In plan mode, Claude has the Explore subagent find every usage and group them by pattern. It proposes an order (shared helpers first, then the modules that depend on them), flags the waiting and retry differences as the risky spots, and stops. The team approves. Approval exits plan mode, and Claude implements the plan group by group, running the tests after each.

The modes are not a setting you choose once per session. The same session moves between them: Shift+Tab into plan mode for the investigation, approve, implement directly, and back into plan mode if a later phase raises a new design question. When a question asks how to handle a large migration from start to finish, look for this sequence, investigation first.

3.4.7 The exam traps

Every trap on this task statement is a mismatch between the shape of the task and the mode chosen for it, or a discovery phase run in the wrong place.

• ✗ Starting the microservice split in direct execution and letting the boundaries emerge. ✓ Plan mode: the boundaries are an architectural decision, and letting them "emerge" means finding dependencies after the edits that rely on them.
• ✗ Direct execution with exhaustive up-front instructions for an architectural change. ✓ Plan mode: complete instructions assume you already know the design, and here working out the design IS the task. You cannot write instructions for a design you have not done.
• ✗ Starting directly and switching to plan mode only if the task turns out to be complex. ✓ Plan mode from the start when the description already says dozens of files or undecided design; the complexity was stated, not discovered.
• ✗ Plan mode for a one-file fix with a clear stack trace or a single validation check. ✓ Direct execution: the location and the fix are known, and planning adds an approval step with nothing to approve.
• ✗ Reading sixty files in the main conversation "so Claude has full context" before a multi-phase task. ✓ The Explore subagent, which reads them in its own window and returns a summary, leaving room for the phases that follow.
• ✗ Trying to do a 45-file migration entirely in plan mode, or planning every file separately. ✓ One investigation and one approved plan in plan mode, then direct execution to carry it out.

3.4.8 Put it together: run the week yourself

You now have every piece. You know what the two modes allow and how to switch between them. You know which signals decide the mode, why planning first avoids rework, and how the Explore subagent keeps discovery out of the main conversation. You also know how the modes combine on a large migration. The quickest way to make it stick is to run the pattern once and feel the difference.

Several later topics build on these decisions. Iterative refinement (3.5) is how you steer the implementation once it is under way: concrete examples, tests written first, and letting Claude interview you before it builds something unfamiliar. Claude Code in CI/CD (3.6) runs Claude with no human at the keyboard, so nobody is there to approve a plan and the scope must be set in advance. Context management in large codebases (5.4) takes subagent delegation further, with scratchpad files and summaries that carry findings from one exploration phase to the next.

Key takeaways

• ✓ Direct execution reads and edits straight away; plan mode, entered with Shift+Tab, claude --permission-mode plan or /plan, lets Claude explore while edits stay blocked until you approve a written plan.
• ✓ Choose plan mode for large-scale, architectural or multi-file changes, tasks with several valid approaches, and choices between designs with different infrastructure needs.
• ✓ Choose direct execution for simple, well-scoped changes, such as a one-file bug fix with a clear stack trace or one validation check in one function.
• ✓ Planning first moves the discovery of hidden dependencies to before the edits, where fixing them costs a sentence rather than rework, so when a task states its complexity, plan from the start.
• ✓ The Explore subagent reads with read-only tools in its own context window and returns a summary, which prevents context window exhaustion on multi-phase tasks.
• ✓ For a 45+ file library migration, investigate in plan mode with the Explore subagent, approve the plan, then implement it in direct execution.

Check your understanding

4 questions written for this lesson, then one from the CCAR-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Permission modes, plan mode section
• Common workflows
• Subagents, built-in Explore
• Best practices, explore then plan then code
• Commands reference
• The CCAR-F exam guide, summarised