How do I vibe code?

What vibe coding actually asks of you

Vibe coding sounds like the absence of method, which is exactly why it goes wrong for so many people. Letting a model write the code removes the syntax problem, but it does not remove the two jobs that were always the hard part: saying precisely what should happen, and checking that it did. Your effort moves rather than disappears — from typing code to specifying and reviewing it. For where the term came from, see vibe coding.

This is why two founders using the identical tool get wildly different results. The one who opens with "build me a marketplace" gets a demo that collapses on the second feature. The one who opens with a paragraph naming the user, the data and the single thing version one must do gets something worth building on. Tool choice matters less than most comparisons suggest — the best vibe coding tools covers how the families differ — because the loop below is the same whichever one you pick.

The loop, step by step

1. Write the spec before the prompt — one paragraph: who uses this, what it must do, what data it stores, and what it explicitly will not do in version one. Ten minutes here prevents the rebuild that happens when the model guesses at everything you left unsaid.
2. Build one slice at a time — ask for the smallest thing that runs end to end, confirm it actually runs, then extend it. A single huge prompt produces a large surface area you have no realistic way to review.
3. Commit every time something works — version control is the undo button for generative work. When the next change breaks three things at once, a known-good commit is the only reliable way back, and it costs one command to make.
4. Read the risky lines yourself — logins, payments, anything touching customer data, and anything that deletes. A model writes plausible code and will not tell you which check it skipped, so those paths get read line by line even when the rest does not.
5. Test it as a stranger — click through as a first-time user: wrong inputs, empty states, the back button, a second account. Generated apps are usually correct on the path the prompt described and thin everywhere else.
6. Keep a change log — ask the model to summarise what it changed and why after each slice, and keep that text with the project. It is the cheapest defence against a codebase you can no longer explain to anyone, including yourself.

Where it breaks

The failure modes are consistent across tools, and none of them is really about the model being bad at code:

• Silent assumptions — the model builds what you asked for, not what you meant. Everything you left unstated gets filled in with something plausible, and you discover the gap when a real user hits it.
• Working things that quietly stop working — generated edits reach further than they appear to. If you cannot run the whole thing after each change, you will not notice what the last change broke until much later.
• Security you never chose — default access rules, over-permissive database policies and keys committed where they should not be are common in generated apps, and nothing warns you. Check those before launch, not after.
• The last twenty percent — the first eighty arrives in an afternoon; the rest is where the model needs you to genuinely understand the system. Either budget for that stretch or scope version one so it does not have one.

What happens after it works

Finishing the loop gets you working software that nobody knows exists, which is now the standard founder situation: building got dramatically cheaper and distribution did not. Before you build more, decide what version one is actually for — that is the whole point of a minimum viable product — and when it works, the next question is how to market a vibe-coded app.

First-party note from building AgentCeres — the AI Growth Officer at agentceres.com: most of our code and marketing pages are AI-drafted and human-reviewed, and the most expensive class of mistake was never bad code. It was work that quietly disappeared. Two changes generated in parallel, each one correct and passing every check against the starting point it was written against, and broken the moment they were combined — because nobody re-ran the checks on the combined result. If you take one habit from this page, take that one: small slices, and verify the thing you actually shipped rather than the piece you just generated.