Vibe coding, explained: how to go from a sentence to shipped software

What vibe coding actually means

Andrej Karpathy coined the phrase in early 2025, and it stuck because it named something people were already doing. Instead of typing every line yourself, you describe what you want in ordinary language and let a model write the code. You read the result, run it, notice what is wrong, and ask for the next change. The loop is closer to directing than to typing.

That sounds loose, and in its purest form it is. Karpathy described leaning into the vibes, accepting suggestions without reading every diff, and treating the code as something you converse with rather than author. For a weekend experiment that is fine. For anything that will hold real data or face real users, the interesting question is not whether you can vibe code, but how much of the discipline of normal software you keep while you do it.

It helps to separate two things that often get blurred. The first is the interaction style: talking to a model in plain language. The second is what sits underneath: whether you end up with real source code and a real database, or with a configuration locked inside someone else's product. You can have the friendly interaction on top of either foundation. The foundation is what decides whether the thing you built is still yours in six months.

How the loop runs, step by step

Strip away the hype and a vibe coding session has a rhythm. Once you have done a few, it becomes muscle memory.

1. Describe the outcome, not the implementation. Say what the app should let people do and what data it holds. Say who logs in and what they see. Leave the framework choices to the model unless you have a strong reason not to.
2. Read the first version with fresh eyes. Click every button. Submit the form with empty fields. Log in as a second user and check you cannot see the first user's records. The first build is a draft, and drafts have holes.
3. Ask for one change at a time. Vague, stacked requests produce vague, tangled results. A tight instruction like add a required email field to the signup form and reject duplicates gets you something you can actually verify.
4. Verify before you move on. If you asked for duplicate rejection, try to register the same email twice. Trust nothing you have not seen work with your own eyes.
5. Save a version when something works. A known-good checkpoint is the difference between a bad afternoon and a lost week. When the next change breaks something, you roll back instead of debugging blind.

The people who get good at this are not the ones with the cleverest prompts. They are the ones who test relentlessly and change one thing at a time. The model is fast and confident. Your job is to be the part of the process that is slow and skeptical in the right places.

Where vibe coding quietly breaks

The demos always look effortless. The trouble shows up later, and it tends to show up in the same few places every time.

The confident wrong answer

A model will produce code that looks right and runs and is still wrong. It will invent a library function that does not exist, or handle the happy path beautifully while ignoring the case where a field is empty. The output reads as authoritative whether or not it is correct, so you cannot lean on how sure it sounds. You have to check behavior, not tone.

Security you cannot see

This is the one that costs people real money. It is easy to build a to-do app where every user can quietly read every other user's tasks, because the model wrote the read query without the filter that scopes it to the logged-in person. Nothing on screen tells you. The app works in your demo because you are the only user. Always test access control with a second account, and treat anything touching payments, passwords, or personal data as code you read line by line.

The wall at fifty percent

Getting to something that mostly works is the fast part. The last stretch, the edge cases, the error messages, the state that gets out of sync, is where unstructured vibe coding stalls. If every change is a fresh conversation with no memory of the last one, you go in circles. The way through is structure: a real codebase you can see, versions you can roll back to, and a model that is editing files rather than regenerating the whole thing from scratch each time.

Why this is not the same as no-code

People lump vibe coding in with no-code because both let you skip writing syntax by hand. The difference is what you are left holding.

No-code platforms give you a visual configuration that only runs inside that platform. Stop paying and the app stops working. Your data lives in the vendor's database in a shape you do not control, and export usually means a flat file plus the job of rebuilding everything else from nothing. That is fine until you need something the builder does not allow, and then you are stuck, because there is no code underneath to reach for.

Vibe coding done well produces real source code and a real database. You can read it, change it by hand when you want to, host it, and keep maintaining it with ordinary programming tools. The plain-language interaction is a faster way in. It is not a cage. The single most useful question to ask any tool in this category is simple: at the end, do I have code I own, or a subscription I cannot leave?

How to get a real application, not a demo

The gap between a toy and something you can put in front of customers is mostly discipline, not talent. A few habits carry most of the weight.

• Start narrow. Build the one workflow that matters most and get it genuinely solid before you add the second. A small app that works beats a large one that half works.
• Keep a real data model. Ask early for the entities and how they relate, a customer has many orders, an order has many line items. A clear schema early prevents a tangle later.
• Put auth in from the start. Retrofitting who-can-see-what onto an app that assumed one user is painful. Decide the roles up front.
• Version obsessively. Save a checkpoint whenever something works. Roll back the moment a change makes things worse instead of trying to reason your way out.
• Read the sensitive parts. You do not have to read every line. You do have to read the code that touches money, credentials, and personal data.
• Test like a stranger. Your own click path is too kind. Submit bad input, use a second account, refresh at the wrong moment, and fix what falls out.