The one-prompt app demos are lying to you. The developers actually shipping real products follow a boring, repeatable loop — and once you see it, you can’t unsee it in every polished demo video.
This post is about how to use Claude Code the way those developers actually do: not a single trick, but a process. It’s Part 1 of Master Claude Code. By the end, you’ll have a six-step loop you can apply to your very next task: scope it, ground Claude in a CLAUDE.md, plan before you touch code, verify in small steps, and commit at a boundary you can always roll back to.
- The gap isn’t the model, it’s the harness. The same Claude, used with a scope-plan-verify-commit loop instead of one giant prompt, produces work you can actually trust.
CLAUDE.mdand plan mode are the two levers that matter most — one gives Claude context before it starts, the other stops it from editing before you’ve reviewed the approach.- Git commit boundaries are your undo button. Small, verified, committed slices mean a bad step costs you minutes, not the whole session.
- Claude Code installed — see Run Claude Code for Free or Connect Claude Code to Any Model if you haven’t set it up
- A project under git version control, even a small personal one
- No prior Claude Code experience required — this is written for the first real project, not just the first prompt
Why One-Prompt “Vibe Coding” Collapses on Real Projects#
A single sprawling prompt works right up until the project has more than one moving part. Vibe coding a landing page in one shot is genuinely fine — it’s small, disposable, and easy to eyeball.
The same approach on a real app with auth, a database, and existing conventions falls apart for a specific reason: there’s no checkpoint. One giant prompt produces one giant diff, and when something in it is wrong, you can’t tell which part.
This isn’t a niche complaint. It’s the exact theme of the top comments on one of the most-watched recent Claude Code videos: viewers explicitly asking how to move from “everyone making products with one prompt” to an actual, repeatable process — the same conclusion developers on Hacker News keep landing on when they compare notes: the harness matters more than the model, workflows beat demos, and verification is the real bottleneck.
The fix isn’t a better prompt. It’s a smaller loop. Every step below exists to give you a checkpoint — a place where you can catch a problem before it compounds into the next one.
How to Use Claude Code: The Repeatable Loop#
Here’s the six-step loop, in the order you actually run it. Save this list — you’ll use it on every task, not just your first one.
- Scope the task in one sentence. Not “build the dashboard” — “add a
/api/ordersendpoint that returns the last 20 orders for the logged-in user.” - Check or update
CLAUDE.md. Does Claude already know your conventions for this kind of change? If not, add the missing piece before you start. - Enter plan mode and let Claude propose an approach. Press
Shift+Tabtwice, or prefix your prompt with/plan. Claude reads and explores but can’t edit yet. - Review and adjust the plan. Push back on anything that touches more files than the task needs, or skips a convention you just added to
CLAUDE.md. - Execute in small verified steps. Approve the plan, then check each meaningful chunk — run the tests, read the diff — before moving to the next.
- Commit at a clean boundary. One working slice, one commit, a message that says what changed and why. Then go back to step 1 for the next slice.
Steps 3 and 4 are the ones vibe coding skips entirely. They cost you two or three minutes. They’re also where almost every expensive mistake gets caught while it’s still just text on a screen, not code in your repo.
Writing a CLAUDE.md That Actually Makes Claude Better#
CLAUDE.md is the one file that turns “explain your codebase every session” into “explain it once.” It’s a plain markdown file, read at the start of every session, that holds the facts and rules Claude would otherwise need re-explained. The official guidance is specific about what belongs in it: build and test commands, project conventions, architecture notes — the kind of thing a new teammate would need to be productive.
Run /init in your project and Claude writes a starting version by reading your codebase. Here’s a small, real one for a Node API project:
# Project Instructions
## Commands
- Run tests: `npm test`
- Run one test file: `npm test -- path/to/file.test.js`
- Lint: `npm run lint`
## Conventions
- Use 2-space indentation
- API handlers live in `src/api/handlers/`
- Every new endpoint needs a matching test in `src/api/handlers/__tests__/`
- Database queries go through `src/db/`, never raw SQL in handlers
## Git
- Commit messages: `type: short description` (e.g. `feat: add order history endpoint`)
- Never commit directly to `main`Notice what’s specific here. “Use 2-space indentation” is something Claude can check itself against; “format code properly” is not. The same principle applies to every line: concrete, verifiable instructions get followed far more consistently than vague ones. Keep the whole file under 200 lines — longer files eat more context and, per Anthropic’s own guidance, tend to get followed less reliably, not more.
Two instructions that quietly contradict each other are worse than one missing instruction. If your CLAUDE.md says “use tabs” in one section and a nested directory’s own CLAUDE.md says “use 2-space indentation,” Claude may pick either one. Review it the way you’d review a teammate’s onboarding doc.
Plan Mode: Where Verification Actually Happens#
Plan mode is step 3 and step 4 of the loop, and it’s the single biggest lever in this whole workflow. Press Shift+Tab twice from a fresh session — once takes you to accept-edits mode, twice lands on plan mode — and Claude switches into research-only behavior. It reads files, runs read-only commands to explore, and writes out a plan. It does not touch your source files until you approve one, per the official documentation.
This matters because verification, not code generation, is where real projects actually slow down. A plan is cheap to read and cheap to correct. A finished diff across twelve files is not. Reading the plan before any code exists is the whole trick — you’re reviewing intent, not untangling implementation.
When the plan looks right, you’ll be asked how to proceed. For most tasks on a project you’re learning, choose to approve and manually review each edit rather than handing Claude free rein — you get the plan’s clarity and the safety of watching each change land. As you build trust with a given codebase and a given kind of task, loosening that becomes a judgment call, not a default.
Bottom line: if you only adopt one habit from this post, make it entering plan mode before any task that touches more than one file.
Git Discipline: Commit Boundaries So You Can Always Roll Back#
A commit boundary is the practical payoff of everything above. Once a slice of work is planned, executed, and verified, commit it — before starting the next slice, not after three more are stacked on top. This is the difference between “something broke, let me check the last commit” and “something broke, which of the last six changes was it.”
A few habits make this loop actually hold up:
- One slice, one commit. If you can’t describe the change in one sentence, it’s probably more than one slice.
- Write the commit message before you move on, not as an afterthought when you wrap up the session — you still remember why, not just what.
- Never let an unverified change sit uncommitted while you start the next one. That’s exactly how a small mistake at step 5 becomes an untraceable mistake three tasks later.
The commit is your rollback point, and the plan is your review point. Between the two, you always have a place to stop and a place to go back to — which is the entire difference between this loop and one giant prompt.
Recap: The Loop You’ll Reuse on Every Task#
| Step | What you do | Why it matters |
|---|---|---|
| 1. Scope | One sentence, one clear outcome | Vague scope produces vague plans |
| 2. CLAUDE.md | Check it’s current for this task | Claude follows specific rules, not guesses |
| 3. Plan mode | Shift+Tab twice, let Claude explore | No edits happen until you approve |
| 4. Review | Push back on anything too broad | Cheapest place to catch a bad approach |
| 5. Verify | Small steps, check as you go | Catches problems before they compound |
| 6. Commit | Clean boundary, clear message | Your rollback point for the next slice |
This loop doesn’t get faster by skipping steps — it gets faster because each step is small. Once CLAUDE.md is written and plan mode is a reflex, the whole cycle takes minutes, not the hours a bad one-prompt attempt costs you when you have to start over.
Next in this series: once you notice yourself running the same scoped task over and over — the same PR checklist, the same setup steps — that’s exactly when it’s worth turning into a Claude Code Skill, so Claude reaches for it automatically instead of you re-typing it.
What’s the first real task you’re going to run through this loop?
Read next: Claude Code Skills Tutorial: Build Your First Skill for Part 2, and Cursor vs Claude Code if you’re still deciding on the tool itself.
