What it actually is
You describe what you want. A model writes the code. You look at the result, decide whether it is what you meant, and say what to change. Repeat until it is real. That is the whole practice, and it works shockingly well. People with no engineering background are shipping products that would have taken a small team a year in 2019.
What is genuinely new is that the cost of a first draft has gone to zero. What has not changed at all is everything downstream of the first draft: knowing whether the thing is correct, whether it is safe, whether it will survive a stranger, and whether it does what you told people it does.
Those judgments were always the expensive part of software. They are still yours. The model will not make them for you, and (this is the part that surprises people) it will not tell you that it has not made them.
The loop that works
There is a build loop that keeps projects moving, and a build loop that quietly consumes a weekend and ends in a folder you never open again. They look almost identical from the inside. The difference is entirely in step three.
1. Say what you want, in writing, before you prompt
Not a paragraph of vibes. A description precise enough that someone else could tell whether the result is right. “A place to save links” is a mood. “A signed-in user can paste a URL, we fetch its title, and it appears in their private list, which persists across logout” is a specification. The second one can be checked; the first cannot, and anything that cannot be checked cannot be finished. This is the whole subject of the speccing chapter.
2. Build the smallest version that is genuinely end-to-end
Not the prettiest version, not the most complete. The one that goes all the way through. One real user, signing in for real, saving one real thing to a real database, and still seeing it after a hard refresh. That thin vertical slice is worth more than a beautiful dashboard full of placeholder data, because it proves the parts connect. Placeholder data proves nothing, and as the demo-to-production gap covers, it has an ugly habit of surviving all the way to launch.
3. Verify it yourself. This is the step people skip.
The model says it is done. It is confident. The code looks plausible, and plausible is exactly what a language model is optimised to produce. Do not take its word. Click the thing. Refresh the page. Sign out and sign back in. Open the database and confirm the row is actually there, with the fields you expected, containing what you expected.
Skipping this feels efficient, and for about four hours it is. Then you discover that the last nine features were all built on a broken one, and you cannot tell which of the nine is lying. Everything after that point is archaeology.
4. Commit, in small pieces, constantly
Every time something works, commit it. Not at the end of the day, at the end of the thing. Git is the only reliable undo button you have, and its value is at its absolute highest during a doom loop, which is precisely when you will not have the presence of mind to create it. A commit is a save point in a game where you cannot predict the boss fight.
The three habits that separate shippers from restarters
We look at a lot of AI-built apps. The ones that make it to real users are not built by better prompters. They are built by people with three specific habits.
They keep the project small enough to hold in their head
Not the codebase. The project. They can state, in one sentence, what the app does and who for. When they cannot, they cut something. Scope creep in vibe coding is uniquely dangerous, because adding a feature is so cheap that you stop noticing you are adding them. The cost never shows up at build time. It shows up later, all at once, when you are trying to work out which of your eleven features broke the twelfth.
They read the code, even when they cannot fully write it
This is the single highest-leverage skill in vibe coding, and it is far more achievable than people assume. You do not need to be able to author a React component from memory. You need to be able to open a file the model wrote and answer three questions. Does this talk to the database? Does this check who the user is? Is there a key in here that looks like a password?
That is a reading skill, not a writing skill, and reading is enormously easier. You also have an infinitely patient tutor sitting right there. Asking “explain what this file does, line by line, like I have never seen it” is one of the best uses of a model there is.
They assume the model has not thought about security. Because it has not.
Unprompted, models generate the permissive version. Open database rules, because restrictive ones would have broken your app during development and generated a support burden the model has no way to anticipate. Keys in the frontend, because that is where the code that needs them happens to run. Admin checks in the UI, because that is where the button lives.
None of this is malice or even sloppiness. Each individual decision is locally the fastest path to a working demo. It is just that nobody in the loop was ever asked to think about the stranger who arrives later, and that stranger is the subject of Part III.
What you actually need to get started
Less than you think. Concretely:
- An AI coding tool. Cursor, Claude Code, Windsurf, Copilot, or a chat window and copy-paste. The agentic tools, the ones that can read and edit your files directly, are meaningfully better than copy-paste, because they can see the code they are changing rather than the fragment you happened to paste.
- A stack the model knows cold. This matters far more than beginners expect, and it is the whole of the next chapter.
- Git. Even if you never touch a branch. See above.
- Somewhere to deploy. Vercel, Netlify, Firebase, Railway. Deploy on day one, while the app does nothing, so that “it works on my machine” never becomes a category of bug you have to debug under pressure at launch.
You do not need a computer science degree, a systems design course, or permission. You do need to accept that the model is a brilliant, tireless, extremely fast collaborator with no stake in the outcome and no memory of the stranger who is going to try your app at 3am.
Where to go next
If you are about to start building, read Choosing a stack next. It is the decision with the longest half-life you will make.
If you already have something working and a nervous feeling about it, skip straight to Where apps actually break. That nervous feeling is usually correct, and it is usually about one of ten specific things.