Explore, Plan, Code, Commit

Most people open Claude Code and paste in what they want. That's the mistake. Skipping straight to code works for trivial tasks — but for anything real, it means you're course-correcting mid-build, which costs more time than the setup you skipped.

The better way is a four-step loop: Explore, Plan, Code, Commit. Here's how to run it.

Explore

Before Claude writes a single line, it needs to understand your codebase. That means reading the relevant files, understanding the existing patterns, and figuring out where in the architecture the change belongs.

The fastest way to trigger this is Plan Mode. Press Shift + Tab until you see "plan mode" under the text input. In plan mode, Claude can't edit files — it can only read them. That constraint is the point. You're asking Claude to research, not build.

Give it a specific brief, not a vague request:

I need to add WebP conversion to our image upload pipeline.
Figure out where in the pipeline it should happen, whether we
need new dependencies, and how to approach it.

Claude will read the relevant files, run web searches, and come back with findings. If you'd rather not use plan mode, you can also just ask Claude to explore your codebase as a standalone request — "explore the codebase and tell me how X works" — before you start building. Either way, the goal is the same: context before code.

Plan

After Explore, Claude generates a plan of action: the specific changes it intends to make, the order it'll tackle them, any dependencies involved.

This is the most valuable step in the workflow — and the one almost always skipped by people who complain that Claude goes off in the wrong direction. The plan is your chance to course-correct before any code is written. Read it. Ask yourself whether it matches how you'd actually approach the problem. If it doesn't, push back now. Ask Claude to revise specific areas before you approve. A change at this stage costs nothing. The same change after Claude has built half the feature costs a lot.

Once the plan looks right, approve it. Claude will work through the items it listed, one by one.

Code

With the plan approved, Claude builds. You can have it auto-accept file edits, or review each one — either works depending on how closely you want to follow the changes.

A few things that make this phase go better:

Give Claude the tools to verify its own work. If you're building a web UI, install the Claude Code Chrome extension so Claude can control a browser tab and test the UI before it calls something done. If you have a test suite, make sure Claude can run it — and make sure those tests are a real source of truth, not something Claude wrote specifically to pass. Tests are only useful if they'd catch an actual mistake.

If Claude keeps running into the same issue, ask it to save the fix to your CLAUDE.md file. That's the project-level memory Claude reads at the start of every session. One line in there is worth more than re-explaining the same context twenty times.

Use the back-and-forth deliberately. The Code phase isn't "Claude does it all." It's a loop: Claude proposes, you review, you steer. The plan created in the previous step is the reference point — Claude uses it to decide whether what it's built so far is on track. If you find yourself needing to course-correct, you still have the full context of how the plan was constructed, which makes re-orienting faster.

Commit

When you've tested the result yourself and you're satisfied, it's time to push. Two steps before you do.

First, run a sub-agent code review. Ask Claude to review the changes as a separate task with fresh context. It'll catch things that get missed when you've been close to the work.

Second, have Claude generate the commit message in your style. If you have a convention, describe it once. If not, just ask Claude to write the message based on the diff — it's faster than doing it yourself and usually more precise about what actually changed.

Then push. Start the loop again on the next feature.

Why the order matters

The four steps aren't just a checklist — they're a sequence that gets harder to reverse as you move through it. Exploring first gives Claude the context it needs to plan well. Planning before coding means mistakes are cheap (revising a bullet point) instead of expensive (rewriting working code). Committing last means you've reviewed before it's permanent.

Skip Explore and Plan, and you're doing the expensive part first. That's why it feels like Claude doesn't understand the project — it doesn't, because you didn't tell it to look.

The loop is: Explore. Plan. Code. Commit. Run it every time.

---

Questions or workflow patterns that have worked for you — send them to hello@plainbuilt.co. I read everything.