Explore, Plan, Code, Commit
The canonical loop: investigate before planning, plan before coding, verify before committing — and why skipping steps costs more than it saves.
The failure this loop prevents
The classic AI-coding failure isn't bad code — it's confidently solving the wrong problem. An agent that starts editing thirty seconds after reading your prompt is guessing about the codebase, the constraints, and what you actually meant. The explore–plan–code–commit loop exists to separate research from implementation, so by the time code gets written, the problem is actually understood.
The four phases, each with an explicit gate you control:
Phase 1 — Explore (read-only)
Start in plan mode, which makes Claude read-only: it can explore the codebase and reason, but it cannot edit anything. Ask for understanding, not changes:
Read /src/auth and understand how we handle sessions.
No diffs, no "helpful" drive-by fixes — just comprehension. Plan mode also delegates research to a read-only Plan subagent (a separate helper with its own memory), so heavy exploration doesn't clutter the main conversation's context.
Phase 2 — Plan
Still in plan mode, ask for the plan:
What files need to change to add Google OAuth? Create a plan.
You get a concrete implementation plan — which files, what changes, in what order — that you approve before any edit happens. Crucially, you can edit the plan directly (press Ctrl+G to open it in your editor) before approving. This is the highest-leverage moment in the whole loop: correcting a wrong assumption in the plan costs one edit; correcting it after implementation costs a rewrite.
Phase 3 — Implement
Exit plan mode and turn the plan into code:
Implement the flow from your plan. Write tests for the callback
handler, run the suite, and fix any failures.
Two things matter here. First, the implementation targets the approved plan, not a fresh interpretation of your original request. Second, verification is part of the phase — run the tests, fix the failures — not something bolted on later.
Phase 4 — Commit
Land the work: a descriptive commit message, a pull request, and updates to any docs or changelogs the change made stale. This phase is easy to treat as ceremony, but it's where the work becomes reviewable by other people — and where an agent can handle the mechanical parts (message drafting, PR description) that humans rush.
A worked run: adding Google OAuth
The whole loop in one continuous session, four explicit gates:
| Phase | Prompt | Gate |
|---|---|---|
| Explore | "Read /src/auth and understand session handling" | You confirm its understanding is right |
| Plan | "Create a plan for adding Google OAuth" | You edit the plan (Ctrl+G), then approve |
| Implement | "Implement from your plan, test the callback handler, fix failures" | Tests pass |
| Commit | "Commit with a descriptive message and open a PR" | You review the PR |
Each gate is cheap to pass and expensive to skip. If exploration reveals the session store is Redis-backed when you assumed cookies, you learned that for the price of a read — not a rewritten feature.
When to skip the ceremony
The loop is not a ritual. Skip it when the diff is describable in one sentence — a typo fix, a log line, a renamed variable. Planning a one-line change adds overhead and no safety.
Invest in the full loop when any of these hold:
- Scope is uncertain — you can't list the files that will change.
- Changes span multiple files — coordination errors get expensive.
- The code is unfamiliar — to you or to the session.
A useful heuristic: if you could review the diff faster than you could read a plan, skip the plan. Otherwise, plan.
Why this is worth narrating in interviews
When an interviewer asks how you use AI tools, "I prompt it and check the output" is a junior answer. Describing this loop — read-only exploration first, an editable plan as a gate, verification inside the implementation phase, and knowing when the ceremony isn't worth it — demonstrates that you treat an AI agent like an engineering process, not a slot machine. The phases map exactly to how you'd supervise a capable new teammate, which is the mental model that makes everything else in this track click.