AniUI Academy

Explore, Plan, Then Code

The four-phase workflow — explore, plan, implement, commit — how to enter and leave plan mode, editing the plan before it runs, and when planning is just overhead.

9 min read

The most expensive mistake an agent makes is not writing bad code. It is writing perfectly good code that solves a problem you did not have.

You will not catch that by reading the diff, because the diff looks fine. You catch it earlier, by getting the approach out into the open before anything is written.

Four phases

The workflow that Anthropic's own teams settled on separates research from execution, and then execution from committing.

  1. Step 1

    Explore

    Claude reads the relevant code and answers your questions about it. No changes. You are checking that it understands the ground.

  2. Step 2

    Plan

    Claude proposes what it will change and in what order. You read it, argue with it, edit it.

  3. Step 3

    Implement

    Claude writes the code against the agreed plan, and against whatever check you gave it.

  4. Step 4

    Commit

    A descriptive commit and, if you want one, a pull request.

The middle two are where the value is. The first is what makes the second any good.

The two-phase split at the front is the part that changes outcomes. Jumping straight to code means the first artefact you can react to is a diff, and by then the misunderstanding is expensive.

Getting into plan mode

Plan mode is one of the permission modes you met earlier. Press Shift+Tab to cycle through them until the status bar shows plan mode. You can also start a session in it:

claude --permission-mode plan

Or, when you only want a single message planned rather than the whole session, prefix that prompt with /plan.

Press Shift+Tab again to leave plan mode without approving anything.

Worth being clear about what plan mode restricts, because the name suggests something more restrictive than it is. Claude still reads your files and still runs commands to explore. What it will not do is edit your source. Those edits stay blocked until you approve a plan.

A session in two halves

claude (plan mode)

  1. You typed: Read src/auth/ and explain how we handle sessions and login. Also look at how environment variables for secrets are managed.

  2. Claude ran: Read src/auth/session.ts

  3. Claude ran: Read src/auth/login.ts

  4. Claude ran: Read src/config/env.ts

  5. Claude replied: Sessions are opaque tokens in a signed cookie, stored in Redis with a 14-day TTL. Login is email and password only. Secrets come from process.env with a Zod schema in config/env.ts that fails startup if one is missing.

  6. WhyThis is the explore phase and it is doing real work. If that summary had been wrong, you would have found out here, for the cost of reading four sentences.

  7. You typed: I want to add Google OAuth. What needs to change, and what does the session flow look like? Create a plan.

  8. Claude replied: Plan: 1. Add GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET to the env schema. 2. New route at /auth/google/callback. 3. Extend the users table with a provider column and a provider_id column. 4. Reuse the existing session creation so OAuth logins get the same cookie. 5. Tests for the callback handler, including the case where the email already exists with a password.

  9. WhyStep 5 is the interesting one. That collision case is the sort of thing that gets discovered in production, and it surfaced here because the plan had to be specific enough to argue with.

  10. You typed: Good, but do not add a provider column. We will have multiple providers per user eventually, so use a separate identities table.

  11. Claude replied: Updated. Step 3 now creates an identities table keyed on user_id, provider and provider_id, with a unique constraint on the last two.

  12. WhyThat correction cost one sentence. After implementation it would have cost a migration, a revert, and a context window carrying both the wrong schema and the right one.

Nothing has been written yet, and the design has already changed once.

Editing the plan directly

You do not have to negotiate over a plan in prose. Press Ctrl+G to open the proposed plan in your default text editor, change it there, and save.

This is worth reaching for more often than people do. Describing an edit is slower and less precise than making it, and if you find yourself writing "in step three, replace the second bullet with...", you are doing by conversation something the editor does in five seconds.

Approving

When the plan is ready, Claude asks how to proceed, and the options are about what happens next rather than about the plan itself:

  • Yes, and use auto mode — approve and let Claude work with the classifier handling approvals in the background.
  • Yes, manually approve edits — approve and review each edit as it comes.
  • No, keep planning — stay in plan mode and say what you want changed.

Approving exits plan mode and switches the session into whichever mode you picked, so Claude starts editing straight away. If you want to plan again later, cycle back with Shift+Tab or prefix the next prompt with /plan. As a small convenience, accepting a plan also names the session after its content, which makes it easier to find later in the session picker.

When not to plan

Planning has a cost, and it is not only your time. A planning round trip adds its own reading, its own reply and its own back-and-forth to the context window before a line of code exists.

Skip it when the scope is clear and the change is small. Fixing a typo. Adding a log line. Renaming a variable. For these, asking Claude to plan is a ceremony that produces a plan you already knew.

The rule of thumb is short enough to remember: if you could describe the diff in one sentence, skip the plan.

Planning earns its cost in the opposite conditions — when you are not sure of the approach, when the change spans several files, or when you are unfamiliar with the code being modified. Notice that the last one is about you, not the task. A five-line change in a subsystem you have never read is a good candidate for planning, because the plan is how you find out whether Claude understood something you cannot check yourself.

The last phase

The fourth phase is the one people skip, and it is the cheapest of the four. Ask for a commit with a descriptive message, and a pull request if the change wants one.

Doing it in the same session matters, because Claude has the full history of what changed and why. Coming back tomorrow to write that commit message means reconstructing it from a diff, which is exactly the job you just avoided.

What to take away

Separating research from execution stops Claude from confidently solving the wrong problem. Plan mode blocks source edits while leaving reading and exploration intact, and you enter it by cycling with Shift+Tab, starting with claude --permission-mode plan, or prefixing one prompt with /plan. Read the plan properly, and when a step is wrong press Ctrl+G and fix it in your editor rather than describing the fix. Then approve, implement, and commit in the same session while the reasoning is still there. And skip all of it when the change is one you could describe in a sentence, because a plan for a rename is overhead.

Next: what to do when Claude is already going the wrong way, and the judgement call about when to stop correcting and start again.

Check yourself

5 questions · pass 4/5 to unlock Course-Correcting

up to 50

  1. 1.What does plan mode stop Claude from doing?

  2. 2.How do you enter plan mode in the terminal?

  3. 3.Claude presents a plan and one step is wrong. What is the most efficient response?

  4. 4.Which task is planning most likely to be wasted on?

  5. 5.Why does separating exploration from implementation improve results?

5 left to answer