Vibe coding is programming by describing what you want to an AI and accepting the code it generates without reading it: if it works when you try it, you move on. It is great for quick prototypes and personal tools. The risk shows up when that code reaches real users without anyone reviewing or properly testing it.
A question from the app. Pick an answer.
The agent replies "Done, it works." What backs that up best?
Sounding sure is not evidence. A model can state something false perfectly calmly.
Editing shows it changed something. To know if it is right, it still has to be checked.
It is a result you can see and repeat. Passing tests back up what they test, not the whole app.
The term took off in early 2025 with a post by Andrej Karpathy, an AI researcher. The idea: you talk to a coding agent, accept every change, and when an error shows up you paste the message back and ask it to fix it. You do not read the code; you judge by how the app looks and behaves.
Not all AI assisted coding is vibe coding. If you ask for a change with a clear prompt, read what it did and run the tests, you are programming with help. The difference is not the tool: it is whether someone understands and reviews what goes in.
For things you can throw away or that only you use: a page to split the bill after a weekend trip, a script that renames your vacation photos by date, a mockup to show a client an idea before investing weeks. There, speed is what matters, and if something breaks, the damage is small.
It also opened the door to people who do not code: someone in sales or design can build the tool they need without waiting for the tech team. That is valuable, as long as the tool does not handle other people's data or money.
Before you start, three questions. Will anyone besides you use it? Does it touch other people's data, like emails, passwords or photos? Does it move money? If all three are "no", go ahead: that is vibe coding territory (still, with test data and everything saved in git). With a single "yes", someone who knows has to read the code and test what happens when it fails.
A script that sorts your photos on your computer: three "no"s. An app where your friends enter their details and pay their share of the trip: three "yes"es. What changes is who pays if it fails.
The code works in the demo and fails at the edges: the form accepts a negative amount, or search crashes on a name with an accent. Nobody saw it because nobody read it. Other typical mistakes: an API key pasted into code the browser can see, or a library the model made up that someone could publish under that name to sneak in malicious code.
The other problem arrives over time. After fifty requests, the project is a pile of patches nobody understands, and every fix breaks something else. By then, the agent is not sure how it fits together either.
Start with something just for you, with made up data and no money moving: for example, a page that splits an expense among friends. Before you ask for it, define a concrete test: "12 split among 4 should give 3". And also try what happens with zero people.
Use a coding agent and ask it for a short plan first (plan mode): check whether it matches your idea. Then go one change at a time and test the result. If you repeat rules in every request, put them in a CLAUDE.md or an AGENTS.md. To learn, ask it to show you in the code how one part works; its explanation can be wrong too.
You can keep the speed and add cheap checks. Ask the agent to write tests for what matters (a negative amount gets rejected) and to run them; look at the output yourself, not its summary. Work in small steps and save each one in git, so you can roll back if something breaks.
Before accepting, skim the diff at least: which files it touched and whether there is anything you did not ask for. And do not give it access to the real database or production keys while you experiment. If the prototype catches on and will have users, that is the moment to read all of it.
You can build a prototype without it. To know whether what the AI did is right, you need the basics. You do not have to write every line, but you do need to see what changed in the diff, know where an API key must never go and tell whether the tests check what matters. That is the difference between vibe coding blind and directing an agent.