How to vibe code: a step-by-step walkthrough with a worked example

What do you need before you start vibe coding?

You need three things: a tool, a project small enough to describe on one screen, and a way to tell whether the result is right. You do not need to know a programming language. If the term is new to you, read what vibe coding is first; this page is the hands-on part.

The third item is the one beginners skip. An AI tool will happily build the wrong thing and show you a polished screen. The only protection is knowing in advance what a correct result looks like, ideally as a handful of inputs and the answers you expect.

Step 1: Which tool should you pick?

Choose by how much setup you will tolerate, not by which tool is most talked about. A browser builder gives you a live preview in minutes. A coding agent gives you real files on your machine and more control, and asks more of you.

Features, plans and limits change often, so check each tool's own page before paying: Lovable, Bolt, Replit, Cursor, Claude Code. The full comparison is in best vibe coding tools.

Step 2: How do you write the spec before the first prompt?

Write five lines in a note before you open the tool. Your spec is the difference between a result you can check and one you have to squint at.

1. User. One specific person and the moment they use it.
2. Screen. What is on the page, in plain words.
3. Behavior. What happens when they act, with one example that has real numbers.
4. Not building. The features you are leaving out on purpose.
5. Done when. The check you will run, written as input and expected output.

Our worked example is a small tool for splitting a group bill. Three friends, Ana, Ben and Cy, share a trip. Ana paid 90, Ben paid 30 and Cy paid nothing. The total is 120, so each share is 40. Ana paid 50 more than her share and is owed 50. Ben paid 10 less than his share, so he owes 10. Cy owes the full 40. The tool should say: Cy pays Ana 40, and Ben pays Ana 10. That one example is the test for the whole project.

User: a friend who is tracking who owes what after a group trip.
Screen: a list of people with a "paid" amount each, an add-person button, and a results panel.
Behavior: the results panel lists who pays whom, using the fewest payments.
  Example: Ana paid 90, Ben paid 30, Cy paid 0 -> Cy pays Ana 40, Ben pays Ana 10.
Not building: accounts, saving to a server, currencies, receipts, sharing links.
Done when: the example above gives exactly those two payments, and two people who paid equal amounts give "nobody owes anything".

Step 3: What should the first prompt look like?

Paste the spec and add two instructions: ask before assuming, and keep it to one page. Tools that are told only what to build tend to keep adding. Tools told what to leave out stop sooner.

Build a single-page web app that splits a group bill, using the spec below.

[paste your five-line spec]

Rules:
- Keep everything on one page and in the browser. No login, no server, no database.
- Show the result as plain sentences, such as "Cy pays Ana 40".
- Use whole numbers or two decimal places; round cleanly.
- If something in the spec is unclear, ask me before building.
- When you finish, tell me how to run it and what you assumed.

If you use a coding agent rather than a browser builder, ask it to propose a plan before it writes files. Claude Code has a plan mode for this; see the Claude Code overview for current features. For a deeper method, read how to write an app build prompt.

Step 4: How do you test what the AI built?

Do not judge by whether it looks right. Judge by whether it gives the right answer. Run your known example first. Then try the inputs most likely to break it.

Write down any case that fails. Send them one at a time, quoting the input and the result you got. Compare “It is broken” with “With Ana 90, Ben 30, Cy 0 it shows Cy pays Ben 40. It should show Cy pays Ana 40.” The second gets fixed on the first try far more often.

Step 5: How do you ask for changes without breaking things?

Ask for one change per message, and say what must not change. The most common cause of a spiral, where each fix breaks something else, is a request that touches too much.

• Name the thing and the behavior. “In the results panel, show each payment on its own line.”
• Fence it. “Do not change how the shares are calculated.”
• Paste errors whole. Copy the full error text from the browser console or terminal, with no summary.
• Ask for an explanation when stuck. “Explain in plain English why the rounding is wrong before you change anything.”
• Restart the thread when it drifts. After a long run of failed fixes, open a new session with the spec and the current code, and ask it to find the cause fresh.

Bug: [what you did] -> [what happened].
Expected: [what should happen, with the exact numbers].
To reproduce: [the input].
Error text (if any): [paste the full message].
Constraint: fix only this. Do not change [the parts that work].
Before you edit, tell me in two sentences what you think the cause is.

Step 6: How do you save progress and undo mistakes?

Save a known-good version before every larger change. That is the single habit that separates calm vibe coding from lost afternoons. Browser builders keep a history you can restore. If you work in a folder on your machine, use Git.

git init
git add -A
git commit -m "working: bill splitter passes the Ana/Ben/Cy test"

# before a risky change, work on a branch:
git switch -c add-currency

# if it goes wrong, go back to the last good commit:
git switch main

Commit when your test cases pass, not when the tool says it is finished. If you cannot use Git yet, copy the project folder with a dated name before each big change. The point is a way back.

Step 7: What should you check before you publish?

Before anyone else uses it, ask the tool a few questions and read the answers. You are not reviewing code line by line; you are checking the three things that go wrong most.

1. Where are the secrets? “List every API key or secret this project uses and where each one is stored. Which ones are visible in the browser?” Any key that is visible should not be a secret one.
2. Who can read and write the data? If there is a database, ask what stops one user seeing another's rows, then test it with two accounts. For Supabase, that means row-level security on every table (Supabase docs).
3. What happens with bad input? Type nonsense, very long text and empty fields, and check nothing crashes or leaks an error trace.

If your project has accounts, payments or personal data, read vibe coding security before you publish, and have someone who reads code look at the parts that handle money. For a no-account tool like the bill splitter, the checklist is short.

Step 8: How do you publish it, and when should you stop?

Browser builders publish to a web address from a button. If you built on your machine, a static page can be hosted free; see how to host a website for free. Send the link to two people and watch one of them use it without helping. What they get stuck on is your next change.

Stop adding features when the tool does the one job in the spec. The urge to add accounts, sharing and a settings page is strong because the tool makes each addition feel cheap. Each one adds code you have not read. Finish the first version, use it for a week, and add only what you missed.

If you have an idea but would rather not build it yourself, post it on the board. Every idea there comes with a generated build prompt that someone can paste into a tool. And if you want something to build, browse the ideas, pick a small one and run this process on it.

What are the most common vibe coding mistakes?

For habits that matter once a project grows, see vibe coding best practices. If you want more reusable wording, vibe coding prompts has a set of templates.