2.3 · The Core Workflow: Explore, Plan, Code, Verify

2.3 · 25 min

The Core Workflow: Explore, Plan, Code, Verify

Watch a strong operator and a struggling one work the same feature, and the difference is not typing or even prompting. The struggling one opens with "add rate limiting to the API" and gets code in eight seconds: a middleware bolted onto the wrong layer, solving a problem adjacent to the real one, now occupying both the codebase and the context window. The strong one gets code four minutes later and merges an hour sooner. Those four minutes have a shape, the docs name it, and it is the single workflow this course will drill until it is reflex: explore, plan, code, verify.

Why the naive move fails mechanically

Lesson 1.2 gave you the agent loop: the model acts, reads results, acts again. The loop is greedy by nature. Given "add rate limiting", the model's cheapest path to looking done is to start producing plausible code immediately, gathering context only as errors force it to. The docs state the problem without decoration: letting Claude jump straight to coding can produce code that solves the wrong problem. And a wrong start is not neutral, because everything the loop produced sits in context influencing every subsequent decision. Lesson 1.5 named that failure class; here it is as a workflow bug: the most expensive place to discover a misunderstanding is after the code exists.

The workflow's four phases each exist to kill a specific failure early, while it is still cheap:

Explore. Enter plan mode (Shift+Tab, or launch with claude --permission-mode plan) and have Claude read before it writes: "read src/api/ and how requests flow through middleware; look at how we handle config." Plan mode is read-only by construction, so exploration cannot leak into premature edits. Misreadings of the codebase die here.

Plan. Still in plan mode: "I want per-user rate limiting on the public endpoints. What needs to change? Create a plan." You get the implementation as prose while it costs nothing to be wrong. Read it like a reviewer, because this is review, moved to where it is cheap. Press Ctrl+G to open the plan in your editor and change it directly. When you approve, Claude Code asks how to proceed and the approve options switch the session's permission mode, dropping you into execution. Wrong approaches die here.

Code. Claude implements against the agreed plan. Your role drops to spot-checking that execution tracks the plan, which is a far easier judgment than evaluating improvised code from scratch.

Verify. Run the check that was named before the work started: the test suite, the typecheck, the manual probe. The docs put it bluntly: Claude stops when the work looks done, and without a check it can run, "looks done" is the only signal available. Give the loop something that returns pass or fail and it closes on its own; withhold it and you are the verification loop. Plausible-but-wrong dies here, or it ships.

One tuning knob spans all four phases: reasoning depth. Current models expose an effort setting (/effort, default high), and for a single genuinely hard decision you can put the keyword ultrathink in the prompt to request deeper reasoning for that turn only. Spend it on the plan phase if anywhere; that is where a wrong decision multiplies.

When plan mode is overkill

A workflow you apply indiscriminately becomes ritual, and the docs themselves draw the line: for tasks where the scope is clear and the fix is small, ask directly; planning pays when you are uncertain about the approach, when the change spans multiple files, or when the code is unfamiliar. Their test is the one to memorize, because it is the cheapest heuristic in this course: if you could describe the diff in one sentence, skip the plan. "Rename getUser to fetchUser everywhere" needs no plan. "Add per-user rate limiting" cannot be described as a diff in one sentence, which is precisely the signal that there are decisions hiding in it.

One-shot on a multi-file change

"Add rate limiting to the API." Code appears immediately, built on whatever the model guessed about your middleware stack. You review 400 unfamiliar lines cold, find the misunderstanding on line 12, and the session's context is now full of the wrong approach, which keeps leaking into the fix.

Explore, plan, code, verify

Two minutes of reading, a six-line plan you correct once ("per-user, not per-IP, and config lives in config/limits.ts"), then implementation against the corrected plan, then npm test plus a curl loop you specified up front. The misunderstanding died as one prose line, not four hundred code lines.

Session hygiene: one task, one session

The workflow has a container, and the container has rules. Everything from Lesson 1.3 about context rot applies live here: the session that just finished the rate limiter is carrying its full history (the exploration reads, the plan drafts, the dead ends) and every token of it competes for attention against whatever you do next.

So the position, stated plainly: one task per session, and clear aggressively. When a task ends, /clear, then start the next task with a fresh dispatch. The cost is re-establishing state, which CLAUDE.md and a good opening prompt make cheap. The benefit is that the new task never inherits the old task's noise. The docs back both halves: run /clear between tasks to reset the window, and, their heuristic for mid-task failure, if you have corrected Claude more than twice on the same issue, the context is cluttered with failed approaches; clear and restart with a better prompt that incorporates what you learned. A clean session with a better prompt almost always beats a long session with accumulated corrections. Some operators keep marathon sessions because re-explaining feels wasteful. Watch their transcripts: by hour two they are paying more in corrections than a restart would have cost in setup.

/compact is the middle tool, and it is for mid-task pressure, not task boundaries. It summarizes the conversation to reclaim space, and you can steer what survives: /compact focus on the API changes. Use it when you are deep in one task, the window is filling, and losing the thread would cost more than a lossy summary. At a task boundary it is strictly worse than /clear: you pay tokens to preserve history whose whole value has expired. Two refinements worth having: Esc Esc (or /rewind) can summarize just a segment of the conversation instead of all of it, and /btw answers a side question in an overlay that never enters history at all, so curiosity stops costing context.

The last piece is continuity across sittings. Sessions persist on disk: claude --continue resumes the most recent session in the directory, claude --resume opens a picker, and /rename names a session so tomorrow it is rate-limiting instead of a timestamp. Resuming restores the conversation as it was, rot included, which makes resume a tool for continuing one task across sittings, never a license for the eternal session. The docs suggest treating named sessions like branches, one per workstream, and that mental model is exactly right.

Lablab-2-3One feature, full cycle

Goal: Run explore, plan, code, verify end to end on a real feature in the practice repo, exercising Ctrl+G plan editing and honest verification.

Prereqs: the agentic-practice repo with its CLAUDE.md from Lab 2.2.

  1. Pick the feature: a --summary flag for the duration tool that prints count, total, and average of all durations parsed in a run. Write your verification down first, in workflow-lab.md, before Claude sees anything: which commands you will run and what output proves it works.
  2. Explore. Start claude --permission-mode plan and dispatch: "Read the duration parsing code and the CLI entry point. Explain how a new flag would flow through." Confirm what it says against what you know of the repo.
  3. Plan. "Add a --summary flag: after parsing, print count, total, and average as human-readable durations. Create a plan." Read the plan critically, then press Ctrl+G and edit at least one real thing (output format, file placement, a test case it missed). Approve with manual edit review.
  4. Code. Let it implement. Watch the diffs against the plan instead of evaluating from scratch; flag any silent departure from what was agreed.
  5. Verify. Run exactly what you wrote in step 1 yourself. Do not substitute Claude's report of green for your own run.
  6. Close the loop: /clear, then dispatch a trivial follow-up ("add one edge-case test for zero durations") as a fresh one-sentence task, no plan mode. Feel where the workflow earns its cost and where it would be ceremony.

Verify

  • workflow-lab.md contains verification criteria with a timestamp or commit predating the implementation.
  • Your Ctrl+G edit is visible in what got built (the implementation matches your edited plan, not the original).
  • Your own step 5 run passes: tests green, flag behaves as specified.
  • The step 6 task completed without plan mode, and you can say in one sentence why that was correct.
>Troubleshooting
  • Claude starts writing code during the explore step: check the status bar; you are probably not in plan mode. Shift+Tab cycles into it, or relaunch with the flag.
  • The plan is vague ("update the CLI to handle the flag") rather than specific: push back before approving. "Name the exact files and functions you will touch" is a legitimate planning demand, and vague plans are how silent scope creep gets pre-approved.
  • Verification fails after Claude reported success: good, the lab worked. Feed the failing output back, let it fix, re-verify yourself. Note the gap between reported and actual in workflow-lab.md; that gap is why step 1 exists.

Knowledge check

Knowledge check

Q1You just merged a feature and are about to start an unrelated bug fix in the same terminal. The session has plenty of context space left. What is the right move, and why?
Q2Which task is the strongest case for skipping plan mode entirely?
Q3Deep into a single long task, the window is two-thirds full and Claude is mid-implementation. Losing the thread would be expensive. What does the lesson recommend?
Q4Claude reports: all done, tests pass, the feature works. Per the workflow, what is the verify phase?

Sources