- In short
- The hybrid plan-then-execute pattern uses plan mode for the investigation and design phase, then switches to direct execution to implement the approved approach. It pairs the safety of read-only planning with the speed of editing once the path is known.
What the Claude Code plan then execute pattern is
The Claude Code plan then execute pattern is the workflow most real tasks actually take, and it refuses to treat the mode decision as all-or-nothing. Rather than choosing plan mode for the entire job or direct execution for the entire job, you split the task at its natural seam: the uncertain investigation-and-design part runs under read-only plan mode, and once that produces an approved plan, you switch into direct execution to implement it. You get the caution of planning where caution pays and the speed of editing where the path is already clear.
The previous two knowledge points set up each half. Plan mode earns its place when the approach is uncertain or the change is broad; direct execution earns its place when the change is well understood and scoped. The insight of the hybrid pattern is that a single task often contains both shapes at different moments. The first half, figuring out what to do, is uncertain. The second half, doing the now-decided thing, is known. Applying one mode to the whole task wastes the strength of the other.
- Plan-then-execute pattern
- A hybrid Claude Code workflow that runs investigation and design under read-only plan mode, then switches to direct execution to implement the approved plan.
The four phases of the hybrid workflow
The best-practices guide describes the recommended shape as four phases, and the mode boundary falls cleanly between the second and third.
Phase one is explore. In plan mode, Claude reads the relevant files and answers questions without making changes, building the understanding the design will rest on.
Phase two is plan. Still read-only, Claude turns that understanding into a detailed implementation plan: which files change, in what order, and how the pieces fit. You can open the plan in your editor and adjust it before approving.
Phase three is implement. You leave plan mode, and Claude writes the code, following the plan and verifying as it goes.
Phase four is commit. Claude commits the change with a descriptive message and, if you ask, opens a pull request.
The first two phases are read-only investigation; the last two are direct execution against a vetted plan. The art being tested is knowing that the transition belongs at the explore-plan to implement boundary, not earlier and not later.
Why this matters for the Claude Certified Architect exam
Task Statement 3.4 explicitly notes that this hybrid is common in practice and tested on the exam, and it is set at the apply level so questions place you mid-workflow and ask what to do next. The decisive judgement is the mode transition: an architect who understands the pattern leaves plan mode once the plan is approved, because keeping the read-only constraint through implementation would only slow a now-known change. An architect who does not will either skip planning on an uncertain task or stay in plan mode long after the uncertainty has been resolved.
Scenario 2 and Scenario 4 supply the context. A well-constructed item describes a feature whose design is genuinely uncertain but whose implementation, once designed, is routine. The correct answer plans the design and then executes the implementation directly, mapping the two halves of the task to the two modes. This is why the knowledge point sits downstream of both plan mode use cases and direct execution use cases: you cannot apply the hybrid until you can recognise each half on its own.
Applying the pattern without overstaying in plan mode
The most common failure is not under-planning but over-planning: treating plan mode as a virtue to be maximised and lingering in it while Claude narrates changes it is not allowed to make. Once the plan is approved, the uncertainty that justified planning is gone, and every further moment in read-only mode is friction on work whose answer is already settled. The pattern is a sequence, not a steady state, and the discipline is to cross the boundary decisively.
Approving a plan is the concrete switch. In the permission-modes documentation, approving a plan exits plan mode and moves the session into an editing mode so Claude can begin writing. From there the rhythm becomes the direct-execution rhythm, implement, run the check, iterate, because the hard thinking has already been banked in the approved plan. Recognising that the plan is the hand-off artefact between the two halves is what keeps the workflow fast.
Worked example
An engineer must add OAuth login to an app whose existing session handling they do not fully understand. The design is uncertain, but once chosen, the implementation is conventional.
The engineer starts in plan mode and explores: how are sessions created today, where are secrets read from, what does the current login path look like. Claude reads the auth module and the environment configuration and answers without editing. The uncertainty, how OAuth should slot into the existing session flow, is exactly what planning is for, so this phase stays read-only.
Claude then produces a plan: add a callback route, exchange the code for tokens, create a session through the existing session factory, and store the refresh token where the current secrets live. The engineer reads it, notices the plan should reuse an existing CSRF guard, edits that into the plan, and approves. Approving exits plan mode.
Now the work is known, and the engineer does not linger in read-only mode out of habit. Claude implements the callback handler from the plan, writes a test for it, runs the suite, fixes a failure, and commits with a descriptive message. The uncertain half was planned; the routine half was executed directly. Had the engineer stayed in plan mode through implementation, every edit would have stalled behind a planning round the task no longer needed, the precise anti-pattern this knowledge point warns against.
Common misreadings to avoid
Two traps cluster around the mode boundary.
Misconception
In the hybrid pattern you stay in plan mode the whole time and just allow edits near the end.
What's actually true
Misconception
If a task needs any planning at all, the whole task should be done in plan mode for consistency.
What's actually true
Approving the plan: the concrete switch and its options
The hinge of the whole pattern is a single action, approving the plan, so it pays to know exactly what that action does. When Claude finishes planning it presents the plan and asks how you want to proceed, and your answer determines the permission mode the session lands in next. You can approve and drop straight into an automatic editing mode for an unattended run, approve into a mode that accepts edits while you watch them land, or approve with manual review so you confirm each edit individually. You can also decline to approve yet and keep refining the plan with feedback. Whichever editing option you choose, the moment of approval is the moment the read-only constraint lifts and execution begins.
That design is what makes the pattern a clean two-phase workflow rather than a vague blend. There is a precise boundary, marked by an explicit decision, between investigating under read-only safety and editing at full speed. Recognising that the approval is the boundary, not some gradual loosening of the rules, is what lets you answer questions that drop you at the seam and ask what comes next. Before approval you are still planning; after it you are executing, and there is no in-between state where plan mode quietly allows edits.
Verifying the implementation against the plan you approved
The second phase has its own discipline, because executing a plan is not the same as executing it correctly. The approved plan doubles as a specification you can check the implementation against, and the best-practices guidance suggests doing exactly that with a fresh perspective. After Claude implements, you can have a subagent review the diff against the plan in a separate context: did every step get built, do the listed edge cases have tests, did anything outside the plan's scope change. Because that reviewer sees only the diff and the plan, not the reasoning that produced the change, it evaluates the result on its own terms and catches gaps the implementing session might rationalise away.
This closes the loop the hybrid pattern opens. You planned because the work was uncertain; you executed directly because the plan resolved the uncertainty; and you verify against the plan to confirm the execution honoured it. The pattern is strongest when all three steps are present, and an answer that plans, executes, and then checks the result against the plan reflects the full workflow rather than a truncated version of it.
It also clarifies when the hybrid is the wrong frame. If a task has no uncertain phase at all, there is nothing to plan and the pattern collapses into plain direct execution; if a task is uncertain the whole way through, you may re-enter plan mode for a second investigation rather than pushing ahead. The hybrid is specifically the shape for tasks with a fuzzy front half and a routine back half, and matching the pattern to that shape, instead of forcing every task through four phases, is part of applying it well.
Beyond the interactive pattern: saving plan-then-execute as a workflow
The four-phase hybrid is an interactive pattern you drive by hand, but Claude Code also documents a way to capture the plan-then-execute shape as something reusable. Its workflow feature lets Claude write a workflow for a task and then execute that workflow's logic, and when the workflow is scripted the intermediate results stay in script variables instead of accumulating in Claude's main context, the same context-protection idea the explore subagent applies to discovery.
You can prompt Claude to create a workflow explicitly, or trigger the behaviour with the keyword ultracode; setting /effort ultracode makes Claude plan a workflow for substantive tasks in the session. Once a useful run exists, you can run /workflows, select that run, and press s to save it as a command you can replay later, which turns a one-off plan-then-execute session into a repeatable command for recurring work.
Two caveats matter for both the exam and real use. The workflow feature is documented as a research preview, it requires Claude Code v2.1.154 or later, and it is available on paid plans with Anthropic API access. So while the interactive four-phase hybrid is the pattern Task 3.4 centres on, scripted workflows are the productized extension of the same plan-then-execute idea, worth recognising but not a substitute for understanding the manual mode boundary.
How this is tested on the exam
Look for questions that describe a task with two distinct halves, a fuzzy design followed by a mechanical build, and ask for the workflow, or that drop you in just after a plan is approved and ask what to do next. The correct answers recognise the seam: plan the uncertain part, then execute the known part directly, and do not overstay in read-only mode. Because the hybrid is the bridge between recognising the two modes and classifying tasks under pressure, it unlocks mode selection scenario classification, where you decide the mode for a task you are handed cold.
An engineer used plan mode to investigate an unfamiliar billing module and has just approved a detailed implementation plan. The remaining work is conventional code the plan fully specifies. What is the best next step?
People also ask
What is the plan-then-execute pattern in Claude Code?
Why not stay in plan mode through implementation?
What are the phases of the hybrid workflow?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Even Anthropic Engineers Use This Claude Code Workflow
Why watch: Lays out the explore/plan-then-execute hybrid: investigate and design in plan mode, then switch to direct execution to implement the approved approach.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.