What vibe coding actually is, and how to do it well

Vibe coding is building software by describing the outcome you want in plain language and letting an AI model write most of the code. You stay responsible for one thing the model cannot do for you: deciding whether the result actually works.

That sounds loose. In practice the people who get good results run a tight, repeatable loop. The people who get stuck skip steps in it.

What it is not

• It is not "type a sentence, get a business". A sentence gets you a starting point. Working software comes from ten or thirty passes over that starting point.
• It is not code-free. You do not have to write the code, but you do have to read it, or at least read what it does.
• It is not a reason to skip thinking. The model will happily build the wrong thing beautifully. Deciding what to build is still your job.

The loop

Every good session looks like this:

1. Describe one small outcome in a way a stranger could verify. 2. Generate the change. 3. Run it. Click the thing. Submit the form. Look at the real screen. 4. Read what actually happened, including errors, not what you hoped happened. 5. Correct with a specific, narrow follow-up.

The loop is the whole skill. Speed comes later, and it comes from doing fewer wasted passes, not from typing faster.

Start with the thinnest slice that can be used

The first version of anything should be the smallest thing a real person could use once and get value from. Not the architecture. Not the settings page. One useful path, end to end.

For a recipe site, that is: paste a link, see the ingredients, save it. No accounts, no tags, no sharing. Once that path works, everything else is an addition to something real instead of a promise attached to something empty.

A working thin slice beats a broad, half wired skeleton every single time. You can grow the first one. You have to debug the second one.

Say what "done" means before you start

Write the finish line down first, in plain language, as something observable:

• "I can paste a URL, press Save, refresh the page, and the recipe is still there."
• "If the URL is not a recipe, I see a message that tells me what happened."

Now you have a test. Without it, "done" drifts to "the model said it was done", which is not the same thing and is the single most common reason a vibe coded project quietly falls apart.

Read the result, not the promise

The most expensive habit in vibe coding is trusting a summary. A confident "I have added authentication and everything now works" is a claim, not evidence.

Cheap checks that catch most of it:

• Do the thing yourself in the browser, in the state a new visitor would be in. Sign out first.
• Refresh the page. A lot of broken software looks fine until the page reloads.
• Try the empty case, the wrong case, and the very long case. No results. Bad input. A 400 character title.
• Open the browser console and look for red.

Keep every change small enough to undo

Small changes are not a style preference, they are a debugging strategy. When one change breaks the app, you know exactly what caused it. When eleven changes break the app, you are now doing archaeology.

Practical rules:

• One intent per pass. "Add the save button" and "redesign the header" are two passes.
• After each pass that works, note it or commit it. That is your last known good state.
• If two corrections in a row make it worse, stop correcting. Go back to the last good state and describe the goal differently.

What to learn, even if you never write code

You do not need to be a developer. You do need a vocabulary, because vague words produce vague software:

• Frontend and backend. What the visitor sees, versus what runs on a server where secrets can live.
• Database and schema. Where data is stored, and what shape it has.
• Authentication and authorization. Who someone is, versus what they are allowed to do.
• Environment variables and secrets. Keys that must never end up in the browser.
• Deploy and rollback. Publishing a version, and going back to the previous one.

Five concepts. They are the difference between "it broke" and "the save is failing because the database rule blocks it".

A worked pass

Weak request:

Make the recipe app better and add users.

What comes back is a guess: half a login system, a settings page nobody asked for, and a list that no longer loads.

Stronger request:

Add sign in with email so a visitor can save recipes to their own account. Only the person who saved a recipe can see it. Do not change the paste and parse flow that already works. Done means: I sign up, save a recipe, sign out, sign back in, and it is still listed.

Same feature, one tenth of the mess, because the goal, the boundary, and the finish line are all stated.

Failure modes you will hit

• Scope creep in one prompt. Six features in one sentence, none of them finished.
• Silent overwrite. A working flow gets rewritten because you did not say to leave it alone.
• Fake data. A screen filled with placeholders that never came from your database. Always ask where the numbers come from.
• Error blindness. Copying half an error message. Paste all of it, every time.
• No sign out test. Everything works for you, because you are signed in. Visitors are not.

How you know you are improving

You will notice three things: your requests get more specific, your passes get shorter, and you start predicting what the model will get wrong before it does. That is the whole craft. Ship happens, and then you go again.