An engineer asks Claude Code to replace a payment SDK. The repository has several consumers of the old client, an undocumented retry layer and a release policy that requires regression evidence. Editing the first import found would be fast but could miss the transaction path that actually carries risk. Read-only planning makes sense while dependencies and acceptance criteria are uncertain; direct implementation makes sense once the scope is bounded. The Anthropic CCA-F judgment is not ‘always plan first’ but when investigation reduces enough uncertainty to justify changing files, and what evidence should accompany the transition to execution.
Identify uncertainty before choosing a mode
A small change to a clearly isolated function may not need a lengthy planning phase. If the expected behavior, affected file and tests are already known, direct implementation with bounded permissions can be efficient. A cross-service payment migration is different: the engineer may not know every caller, authentication path or rollback condition. The uncertainty lies in the architecture, not in how to write one API request. A plan-oriented exploration should reduce that uncertainty before code is modified.
Do not use the number of files alone as a mode selector. A one-file change can be high risk if it alters encryption or financial transactions; a mechanical rename across many files can be well understood and testable. Ask which assumptions remain unverified, whether the action has side effects and how easily an error can be reversed. The answer determines whether the first useful step is evidence gathering, a design proposal or an authorized edit.
Understand the purpose of read-only planning
Claude Code’s plan mode is designed for exploring and proposing an approach without writing to the project as part of that mode. The assistant can inspect relevant source and articulate a design before the developer allows implementation. This is valuable when requirements are incomplete or several architectural options deserve comparison. It reduces accidental churn from early guesses, but it does not guarantee that the proposed plan is factually correct.
A sound plan should identify the current behavior, target behavior, affected modules, dependency relationships, migration strategy, tests and rollback considerations. The developer can challenge it while changes are still cheap. If the assistant says to update the payment client but cannot identify where the old client is instantiated, the plan is not ready. Ask for exact files, interfaces and evidence rather than rewarding a lengthy narrative with a false sense of completeness.
Separate exploration from execution authority
A model’s statement that it is ready to implement should not automatically grant permission to edit the repository or deploy code. Plan mode and execution permissions are related but distinct controls. The developer or host decides when to enable the relevant modification tools. For protected branches, CI and review policies remain in force even if the plan is approved. A helpful assistant may produce a high-quality proposal, but the system must enforce who can modify which files and services.
This matters for tool access. Reading source code and searching files are usually less intrusive than running arbitrary shell commands or writing external configuration. The runtime should offer appropriate tools for the current phase rather than merely asking Claude in prose to avoid editing. The approved implementation can then use targeted operations while preserving a clear record of which changes were authorized and on what evidence that authorization rested.
Make the plan testable
For a payment SDK migration, the acceptance criteria might require unchanged payment identifiers, preserved idempotency behavior, correct currency handling and no regressions in refunds. The plan should connect each condition to a test or inspection method. Without that mapping, the engineer cannot tell whether the finished work matches the intended design. A testable plan is stronger than a sequence of generic actions such as update code, run tests and check the result.
Identify failure cases before implementation. What if the new SDK returns ambiguous errors? Does it use different pagination or settlement states? Are credentials handled through the same secret store? How will the team identify affected transactions if rollback is needed? Some facts may require official SDK documentation or a staging experiment. Mark those dependencies rather than letting the assistant quietly assume equivalence between APIs because their method names look similar.
Treat the plan as a controlled hypothesis
A plan captures the best current understanding, not immutable truth. During implementation an unexpected dependency may emerge. The correct response is to revisit the affected assumptions, update the plan and obtain any necessary approval for the expanded scope. An assistant should not silently rewrite the objective from migrating one payment integration to replacing the entire billing architecture. Scope changes deserve the same scrutiny as the original decision.
Maintain the source revision and evidence behind the plan. If another developer changes the checkout service while the plan is under review, the implementation should revalidate the impacted paths. A plan approved for commit A may no longer be safe on commit B. This is especially important when planning and execution are separated in time or handled by different engineers. Continuity depends on current evidence, not just the existence of an earlier approving message.
Know when direct execution is the better choice
Plan mode has an opportunity cost. A one-line typo in an internal label with a nearby test and no side effects may be fixed directly and reviewed through the normal diff. Spending many model turns building a detailed design document would add little. The architect should favor short, reversible execution when the target is precise, the necessary context is available and tests can quickly establish correctness. This is not cutting corners; it is proportional process design.
Direct execution still needs boundaries. The agent should inspect the exact file, apply a focused edit and check the resulting change. It should not interpret a simple task as permission to refactor unrelated modules. If a supposedly trivial fix uncovers inconsistent APIs or security-sensitive behavior, switch back to investigation. Good workflow selection is adaptive: begin with the lightest mechanism that can produce a reliable result and expand only when the actual evidence justifies it.
Use iterative refinement without losing the goal
After a patch, CI checks should verify the actual changed revision rather than accepting a model’s statement that the tests passed. When an investigation is still exploratory, choose bounded repository discovery and editing tools that match the stage. A plan is useful only if its proposed checks can be executed and the implementation remains inside its approved scope.
A practical implementation often involves a cycle of change, focused test, feedback and correction. The iteration should preserve acceptance criteria rather than optimizing only for making one failing assertion disappear. If the new SDK breaks a refund test, understand whether the change exposed an incorrect assumption or the test itself is obsolete. Do not weaken the assertion simply to obtain a green build. Record the reason for every meaningful adjustment and re-run the checks that the change could affect.
Claude can assist by proposing a narrow hypothesis for each failure. Test-driven refinement and requirement interviews help determine whether the next step should be another bounded patch or clarification from the person who owns the business rule. A developer may ask for a minimal fix, examine the diff and test again. Repeated attempts with no progress should trigger a different investigation approach rather than an unbounded sequence of edits. This complements Claude Code workflows while focusing on how planning and execution phases should be selected, bounded and evaluated.
Review the boundary between code and production
Even after the migration’s code tests pass, a production rollout may depend on credentials, network policies, feature flags and data reconciliation. Planning should identify those dependencies, but the coding assistant does not gain production rights by mentioning them. A release owner must ensure that staging evidence, rollout monitoring and rollback conditions are satisfied under the organization’s normal controls. Separating code readiness from operational approval reduces the risk of equating an accepted patch with a safe deployment.
The assistant can generate release notes and help monitor permitted read-only signals, but external system changes should use authenticated, auditable workflows. If the application introduces a new retry policy, verify that it does not duplicate financial actions when an acknowledgment is lost. If a rollback is necessary, it may need a data repair in addition to reverting code. Such considerations are reasons to plan early for complex changes, not reasons to give a model unrestricted authority to improvise a release.
Plan and implement the payment migration
The engineer first asks Claude to map every use of the old SDK. The assistant locates checkout, refund and reconciliation callers, examines dependency versions and records uncertainty about the new provider’s error semantics. Its plan proposes an adapter layer, incremental replacement, idempotency tests and a staged rollout. The developer confirms the scope and approves a bounded implementation. Claude then applies small patches, runs relevant tests and presents the resulting diffs for review.
An unexpected reconciliation dependency appears during testing. Rather than quietly altering a separate service, the assistant reports the discovery and proposes a plan amendment. After approval, the team tests the expanded change and follows normal release controls. This is the operational distinction the exam tests: plan when the architecture or authority boundary is uncertain, execute directly when the task is precise and reversible, and preserve verified evidence across both phases so the final result can be trusted.