- Vibe coding means describing what you want and letting a model write the code, then checking the result rather than reading every line.
- The whole thing runs on one habit: small prompts, verified one at a time. Big prompts feel faster and cost more.
- Researchers who recorded real sessions found the skill did not disappear, it moved to context management and rapid evaluation of what came back.
- Asking a model to keep improving code is measurably risky. One controlled study saw critical vulnerabilities rise 37.6 percent after five rounds of refinement.
- Deploy on day one with something ugly. A live URL turns every later prompt into a check you can actually run.
- In our own keyword data the parent term went from 720 monthly searches to 96,200 in eleven months, which tells you how new the vocabulary is, not how new the practice is.
It is Saturday morning. Someone you know runs a bakery two days a week and takes pre-orders through direct messages, which means they lose about a third of them. They have described the problem to you four times. You have never shipped a website. By tonight there is a working order page at a real address, and you did not write a line of code by hand.
That is the promise, and it is mostly true. What follows is the part the promise leaves out: the order of the prompts, what to check after each one, and the four ways beginners lose an afternoon. Nothing here needs prior programming experience. It does need you to be stubborn about verifying things, which is the actual skill.
What is vibe coding, in one paragraph?
You describe the thing you want in ordinary language, a model writes the code, you run it, and you judge the result by whether it works rather than by reading the implementation. The term comes from a post by Andrej Karpathy on 2 February 2025 describing a kind of coding where you give in to the vibes and forget the code even exists. It named something thousands of people were already doing without a word for it.
The research caught up quickly. Advait Sarkar and Ian Drosos analysed more than eight hours of recorded sessions with think-aloud commentary and published a study of the practice in June 2025. Their description of the loop matches what you are about to do: prompt, scan the generated code quickly, test the running thing, edit by hand where needed, repeat. They also found that expertise did not vanish. It shifted toward context management, fast evaluation of output, and knowing when to stop asking and start typing.
Hold onto that last point. Every mistake below is a version of not knowing when to stop asking.
The project, and why this one
One page. A bakery lists what it is baking this weekend, a customer picks items, leaves a name and a phone number, and the order lands somewhere the baker will actually see it.
It is a good first project because it is small enough to finish, real enough to be used on Sunday, and it contains the one thing that separates a toy from a tool: something has to be saved and retrieved. A page that only displays text teaches you nothing about the part that breaks.
What do you actually need before you start?
Less than the tutorials imply. An account with a model that can write code, a browser, and somewhere to put files. That is the whole list.
What you do not need is a decision about frameworks. Beginners lose their first evening choosing a stack, and the choice is close to irrelevant at this size. Ask for plain HTML and CSS in the first prompt precisely because you can read it, and because a single file cannot develop the kind of structural problem that takes an afternoon to unpick. Anything you outgrow can be regenerated in ten minutes once the thing is real.
One preference is worth having in advance, though, and the vulnerability data above is the reason. If a model offers you a choice of language and the project is going to hold anyone's personal details, the measured rates favour TypeScript over Python for this kind of small web work. That is a weak signal rather than a rule, and it is still better than accepting whatever the model reached for first.
Set a stopping time as well. Two hours, then look at what exists. The recorded sessions the researchers analysed show experienced practitioners moving fluidly between generating and editing by hand, and the beginners who struggle are the ones who treat a stuck loop as a reason to prompt harder. A break is a legitimate debugging technique.
The prompts, in order
Type these one at a time. After each, do the check. Do not move on with a failing check, because every later prompt builds on the state of the last one, and a model correcting a mistake it cannot see will invent a plausible reason instead.
Prompt 1: the shape, before anything else
Ask for the smallest thing that can be looked at.
Build a single page for a weekend bakery. It shows a heading with the bakery name, a short line about pickup hours, and a list of four items with a name, a one line description and a price. No ordering yet, no database, just the page. Use plain HTML and CSS so I can read it.
Check: the page opens and you can see four items. That is all. Resist adding anything.
Prompt 2: make it selectable
Add a quantity selector next to each item, starting at zero, with plus and minus buttons. Show a running total at the bottom that updates when quantities change. Keep everything on this one page.
Check: click plus three times on one item and confirm the total matches the price times three. This is the first moment a model can be subtly wrong, usually by recalculating from stale state, and you will catch it in ten seconds by hand.
Prompt 3: the form
Add a form under the total asking for a name and a phone number. Both required. When submitted, show a confirmation message with the order summary. Do not send it anywhere yet.
Check: submit with the fields empty. If it accepts an empty submission, say exactly that and ask for validation again. Models frequently produce a form that looks validated and is not.
Prompt 4: deploy it, ugly and unfinished
This is the step beginners postpone and it is the one that changes everything. Put the code in a repository and get a public URL before the project is good.
Give me the exact commands to put this project in a new GitHub repository, assuming I have git installed and an account. Then tell me the simplest way to get it on a public URL for free.
Check: open the URL on your phone. If the repository step is unfamiliar, the GitHub quickstart for repositories walks through creating one and committing a first change in about five minutes.
Deploying early works because it converts vague questions into answerable ones. Instead of wondering whether something is broken, you load the page. Every prompt after this has a live check attached to it.
Prompt 5: make the order go somewhere
When the form is submitted, save the order so the baker can see it later. Explain my options in plain language first, with the tradeoffs, before writing any code. I want the simplest thing that will not lose orders.
Check: read the options and pick one. This is the prompt where you deliberately slow down, because storage is the decision you will be living with. Asking for the explanation before the code is the single highest value habit in this whole workflow.
Prompt 6: one thing at a time, forever after
The total shows 12 instead of 12.00. Fix only that.
Check: the total, and nothing else. The phrase "fix only that" earns its place because an unbounded request to improve things is how a working page becomes a broken one.
What are the four mistakes that waste the most time?
Every beginner makes at least two of these. They are not skill problems, they are process problems, which is why naming them fixes them.
| Mistake | What it looks like | Why it costs so much | The fix |
|---|---|---|---|
| The wish list prompt | One long message describing the whole app, features included | You cannot tell which part failed, so every debugging attempt is a guess | One capability per prompt, with a check you can run in under a minute |
| Refine until it breaks | Repeatedly asking for improvements without testing between rounds | Vulnerabilities and bugs accumulate across iterations rather than cancelling out | Test after every change. Revert instead of layering another fix |
| Deploying last | Building locally for hours, then trying to publish | The deployment problems arrive all at once, entangled with your code problems | Publish something trivial on day one, then keep it working |
| Accepting the first explanation | Taking a confident answer about why something failed at face value | A model asked why something broke will produce a plausible reason whether or not it knows | Ask it to prove the diagnosis by showing what to observe if it is right |
The second one has real numbers behind it, and they are worse than most people assume.
Why does asking it to fix things again make them worse?
Because refinement is not convergence. A controlled study on security degradation in iterative AI code generation ran 400 code samples through ten rounds of refinement across four prompting strategies, and measured a 37.6 percent increase in critical vulnerabilities after just five iterations.
The shape of the curve matters more than the headline. Early iterations averaged around 2.1 vulnerabilities per sample. By iterations eight through ten that had climbed to roughly 6.2. Vulnerabilities accumulated rather than cancelling out, and the finding that should stop you cold is that security-focused prompts also introduced new problems while fixing the obvious ones. Asking nicely for secure code is not a control.
The authors conclude that human review between iterations is what prevents the drift. For a beginner that translates into something simple: after every change, look at the running page. Not the code, the page. If it works, keep it. If it does not, go back to the last version that did rather than stacking another correction on top.
This is also why the deploy-early step earns its position. A live URL is the cheapest possible human review, and you can run it from a phone in the queue at a coffee shop.
Is the generated code actually safe to use?
Mostly, with a distribution you should know about. A large scale analysis of AI-generated code across public GitHub repositories, published on 30 October 2025, examined 7,703 files and identified 4,241 instances spanning 77 distinct weakness types. The reassuring headline is that 87.9 percent of the files carried no identifiable mapped vulnerability.
The uncomfortable detail is that the rate depends heavily on language. Python files ran between 16.18 and 18.50 percent, JavaScript between 8.66 and 8.99 percent, and TypeScript between 2.50 and 7.14 percent. If your first project handles anything sensitive, that spread is a reason to care which language the model reached for by default.
For a bakery order form the exposure is small but not zero, because you are collecting names and phone numbers. Before it goes live for real, ask the model to check the page against the OWASP Top 10 categories, specifically broken access control and security misconfiguration, and to explain what it found rather than silently patching. You will not understand every answer. You will understand enough to know whether anyone can read the order list who should not.
How did the term go from nowhere to everywhere?
Fast, and the speed is worth seeing because it explains why the advice you find is so uneven. Here is what our own keyword tracking shows for the terms in this space, pulled while writing this piece.
| Point in time | Term | Monthly searches, our data | What it means |
|---|---|---|---|
| Eleven months ago | vibe coding | 720 | A word a small circle used, mostly people who had read the original post |
| Today | vibe coding | 96,200 | A mainstream term, roughly 130 times the earlier volume |
| Today | learn how to vibe code | 70, difficulty 25 | The people who want to do it rather than define it, and a far less crowded question |
| 2 February 2025 | Origin | Not a search term yet | Karpathy's post, before anyone was looking the phrase up |
A term that grows that fast collects a lot of writing produced by people who have not done the thing. That is the main reason to prefer the boring instruction over the enthusiastic one, including this instruction: verify what you read against a page you can load.
When do you have to stop vibing?
Three moments, and they are recognisable in advance.
The first is when other people's money or data is involved. Taking payments, storing anything you would not print on a poster, or holding someone else's customer list all move you out of the zone where "it seems to work" is a sufficient test. The bakery form sits right at that boundary, which is why the security check above is not optional.
The second is when you cannot describe what is broken. Vibe coding runs on your ability to specify the gap between what happened and what should have happened. Once you are reduced to saying it does not work, you are no longer steering, and more prompts will make it worse rather than better. The structured version of that skill is writing the acceptance scenarios before the agent starts, which turns the same instinct into something the agent can check itself against.
The third is when the same fix keeps coming back. A bug that returns after being fixed twice is a design problem wearing a bug costume, and no amount of prompting will move it. That is the point to either read the code properly or ask someone who does.
None of these mean stopping permanently. They mean switching from generating to understanding for a while, which the recorded sessions in the research describe as a normal part of the loop rather than a failure of it.
Keep a plain text file next to the project with two lines per session: what you changed, and what you verified. It takes twenty seconds and it is the difference between reverting to a known good state in one minute and rebuilding an afternoon from memory.
What to do next
Build the bakery page, or your own equivalent, and finish it today rather than making it good. The finishing is what teaches you, because a project that goes live surfaces every problem that a project sitting on your laptop hides.
After that, the interesting question stops being how to prompt and starts being where the result should live. Anything transactional eventually needs a real backend, real storage and an owner who can change it without asking you. If you are weighing tools for that, our comparison of what a generated app should leave you owning sets out the questions worth asking, our head to head of Lovable and Bolt covers how the two differ in practice, and our plans and credits page shows what generation actually costs per project rather than per month. For anyone whose bakery page is turning into a real shop, our look at running a store on code you own covers the tradeoff between renting a platform and keeping the code.
The one habit to carry out of this piece: small prompt, run it, keep it or revert it. Everything else is decoration.