AI Guides › Step-by-step guides
By Nigel Guy · 6 min read
The usual mistake is typing "build me a booking app" and hoping the first answer is the app. It feels productive for twenty minutes, because code appears. Then you ask for one change, something else breaks, you ask for a fix to the fix, and you end up with a pile you can't explain and can't safely edit.
"Vibe coding" is the term Andrej Karpathy coined in February 2025 for building by describing what you want and letting the model write the code, to the point of forgetting the code exists. That is fine for a throwaway weekend toy. For anything you want to keep, one habit decides whether it works: you write the brief before the model writes a line, and you build in small slices that each have a check.
The rule: no code until there is a written brief, and no slice is "done" until something runnable says so.
You need:
Cost at time of writing: Pro is $20 a month billed monthly, or $17 a month billed annually (about £15 and £13 at time of writing). Max starts at $100 a month (about £75 at time of writing). Check the £ price at checkout, as it moves with the exchange rate and VAT.
Install on macOS, Linux or WSL with curl -fsSL https://claude.ai/install.sh | bash. On Windows PowerShell use irm https://claude.ai/install.ps1 | iex. Open a new terminal and run claude --version to confirm.
In your project folder run git init, then claude. Log in when prompted in the browser. Paste this, filling in the bracket.
You are a patient product lead helping a non-programmer plan a small app.
I want to build: [ONE_SENTENCE_DESCRIPTION].
The people who will use it: [WHO_USES_IT].
Where it must run: [WEBSITE_OR_PHONE_OR_DESKTOP_AND_ANY_TOOLS_I_ALREADY_USE].
Interview me, a few questions at a time, about: what a user does from start to finish, what data is stored, what happens when things go wrong, what is deliberately NOT in version one, and any limits (budget, hosting, privacy).
Ask rather than assume. If I say "I don't know", offer two options with a recommendation.
When we have covered everything, write SPEC.md containing: purpose, user journeys, data, a numbered list of small build slices in a sensible order (each deliverable on its own), what is out of scope, and for each slice one way to prove it works (a test, a command, or exactly what I should see on screen).
Before saving, check that no slice depends on a later one and that every slice has a proof.
Fill in the description, audience and platform. Answer in plain language. This follows Anthropic's own advice to let Claude interview you and write a spec for larger features.
Open SPEC.md yourself. Delete anything you would not miss in version one. Make sure each slice is small enough to describe in a sentence. If a slice has no proof line, add one now. This is the step people skip, and it is the one that matters most.
Type /clear, or quit and run claude again, so the build starts with an uncluttered context. Anthropic's best-practice page explains that performance degrades as the context window fills, which is why a clean session suits a written spec.
Press Shift+Tab until the status bar shows plan mode, or start with claude --permission-mode plan. Plan mode lets Claude read and reason without changing files. Then:
Read SPEC.md. We are building slice [SLICE_NUMBER] only: [SLICE_NAME].
Propose a short plan: which files you will create or change, in what order, and how you will prove the slice works using the proof line in the spec.
Do not touch later slices. If anything in the spec is unclear, ask me before planning.
Press Ctrl+G if you want to edit the plan in a text editor. Approve it, or press Shift+Tab to leave plan mode.
Implement slice [SLICE_NUMBER] from the plan. Then run the proof from the spec and show me the actual output or a description of what is on screen.
If the proof fails, fix the cause rather than weakening the check, and run it again. Tell me plainly if you could not make it pass.
Anthropic's docs put it directly: give Claude a check it can run, otherwise "looks done" is the only signal and you become the test suite. Where you can, make the check a real test or build command; for screens, ask for a screenshot comparison.
Run the app and click through the slice. Then ask: commit with a descriptive message. Each commit is a point you can return to. If a slice goes wrong, press Esc twice or run /rewind to restore conversation and code, or use git for anything done via shell commands.
For each new slice, /clear and begin again from Step 3. Run /init once to create a CLAUDE.md, and add the test and run commands to it, so each fresh session already knows how to check its work. Keep it short; the docs warn that a bloated CLAUDE.md gets ignored.
If you have corrected Claude twice over the same issue, stop. Run /clear and write a sharper prompt that includes what you learned.
Shift+Tab and the permissions docs so you know what Claude may do without asking./help and the current docs.