Vibe coding went from an offhand post in February 2025 to a dictionary word of the year in under a year. The meaning stretched on the way. Some people now use it for any programming done with AI help, and some keep it for the narrow original version, where nobody reads the code at all.
This is an explainer, not a sales page. It covers where the term came from, the definition its own inventor gave it, the jobs it is genuinely good at, the failure modes that show up in published research, and a procedure for trying it without shipping something you cannot fix. If you already know the definition and want the step-by-step for a site, read vibe coding for website building. If you want to pick a tool, read the tool comparison.
QUICK ANSWER
What is vibe coding?
Vibe coding is building software by describing what you want to a large language model and accepting the code it writes without reading it closely. Andrej Karpathy coined the term in February 2025. It is fast and genuinely useful for prototypes and personal tools. The moment you review, test, and understand the code, most practitioners stop calling it vibe coding.
Settle these four things before you type the first prompt
Vibe coding fails in predictable ways, and every one of them is cheaper to prevent than to debug. These are decisions, not software.
- A project where a bug is survivable: Decide what happens if the code is wrong. A personal tracker, an internal calculator, a prototype for a meeting: the damage is your own time. A signup form that stores customer details, a payment page, anything a stranger can reach: the damage is somebody else. Start on the first kind.
- A place the code can actually run: Generated code that never runs teaches you nothing. You need a preview you can open, refresh, and show to one other person. Anything that keeps you copying files between a chat window and your machine will exhaust you before the project is finished.
- A way to undo: The single most common vibe coding disaster is the model breaking something that worked twenty minutes ago. Before you start, know exactly how you get back: a saved version, a snapshot, a git commit, or at minimum a copy of the folder. If you cannot name the mechanism, you do not have one.
- A rule for secrets and personal data: Decide up front what the project is allowed to touch. No API keys pasted into files the browser downloads, no real customer records in a prototype, no production database on the other end of an experiment. This is the one rule that cannot be fixed later, because a leaked key is already leaked.
Three ways people work with an AI coder, and only one is vibe coding
The word is used loosely, which is why arguments about it go nowhere. Simon Willison drew the line that most practitioners now use: "If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding in my book." He calls that using the model as a typing assistant. The distinction matters because the risks are completely different.
| Approach | Best for | Tradeoff |
|---|---|---|
| Pure vibe coding | Throwaway tools, weekend prototypes, personal automations, and learning what a model can and cannot do. | Nobody in the room understands the code. The first bug the model cannot fix by itself becomes a rewrite, because there is no one to reason about the cause. |
| Reviewed AI-assisted development | Anything other people depend on: a live site, a product, a tool your team uses on Monday morning. | Slower, and it needs somebody who can read code. It is also the only version of this that produces software you can still change in six months. |
| Vibe first, review at the boundary | A first version that might turn real. Generate freely, then read and test the parts that touch money, secrets, personal data, and anything a stranger can reach. | It only works if you are honest about when you crossed the boundary. Most projects cross it quietly, on the day the first real user arrives. |
Recommended:For a first project, use the third option deliberately. Vibe the shape of the thing, then stop and review the four risky surfaces before anyone else touches it. Karpathy himself framed the original version as fine for throwaway weekend projects, which is a scope, not a slogan.
How to vibe code a small project without shipping a mess
A tool-neutral procedure for using an AI coder on a first project: pick the stakes, build one slice, review the risky surfaces, break it on purpose, publish behind a link you can pull back, and decide who fixes it.
STEP 01
Write down the one thing it must do
A single sentence describing the job, in the words a user would use. Not a feature list.
Good: "A page where my students book a 30 minute slot and I get an email." Bad: "A booking platform."
Write down what it must NOT do yet. No payments, no accounts, no admin panel. Every item you defer is an entire category of bugs you are not debugging today.
Name the one person who will use it first. If you cannot name them, you are building a demo, and a demo should never touch real data.
Expected result: One sentence and a short not-yet list, written somewhere you can reread when the model starts adding things you did not ask for.
Verify it: Read the sentence to somebody who is not technical. If they can restate what the software does, it is specific enough to prompt with.
STEP 02
Describe one working slice, then run it
Ask for the smallest end-to-end path that produces a visible result, and open it before asking for anything else.
One slice means input to visible outcome: the form appears, you submit it, something comes back. Not the whole product.
Give real content in the prompt. Real names, real prices, real copy. Placeholder content hides layout and length problems until much later.
Resist the urge to queue five changes. Ask for one, look at the result, then ask for the next. Batched prompts are the fastest way to a state where you cannot tell which change broke it.
Expected result: Something you can open and click that does the one thing from step one, even if it looks unfinished.
Verify it: Use it yourself, once, the way the first user would. If you have to explain a step out loud to make it work, it is not done.
STEP 03
Read the code that touches money, secrets, and personal data
This is the moment you stop pure vibe coding on purpose, and it is the whole difference between a prototype and a liability.
Four surfaces are worth reading even if you read nothing else: where keys and passwords live, where user input is validated, where data is stored, and what the app sends to other services.
Ask the model to explain each one in plain language, then check that the explanation matches the file. A model will happily describe a check it did not write.
If a key appears anywhere the browser can download, it is public. Move it to the server side or remove the feature until you can.
This is not paranoia. Veracode's 2025 GenAI Code Security Report, updated in October 2025, tested code from over 100 large language models and found that models got better at producing functional code without getting better at producing secure code.
Expected result: You can say, in one sentence each, where secrets live, what happens to bad input, where data is stored, and who else receives it.
Verify it: Search the project for the words key, token, secret, and password. Anything you find in files the browser loads is a finding, not a false alarm.
STEP 04
Break it on purpose before anyone else does
Generated code is usually correct on the path the model imagined and thin everywhere else. Test the everywhere else.
Submit an empty form, a 500 character name, an email with no at sign, and a negative number in a quantity field.
Do the same action twice quickly. Double submissions are one of the most common defects in generated forms, because the happy path never showed one.
Open it on a phone. Generated layouts look correct in a wide preview and collapse at 375 pixels more often than they should.
Log out, or open a private window, and try to reach the page again. Anything that only works because you are already signed in is a page a stranger may also reach.
Expected result: A short list of the ways it breaks, and a fix for each one that you asked for specifically rather than by saying "make it better".
Verify it: Run the same four inputs again after the fixes. A fix that was not verified with the input that caused the bug is a guess.
STEP 05
Publish behind a link you can take back
Put it in front of one real person on a real URL, with a way to remove it in a minute.
A private or unlisted link is enough for a first user. A search-indexed page for an untested prototype is a decision, not a default.
Check that it works from a device that never saw the project: a phone on mobile data, or a friend's laptop. Half of "it works for me" is browser cache.
Write down how to take it down and how to restore the previous version. Do this before you need it, not during the incident.
Expected result: A working link, one real user on it, and a documented way to remove or roll back the deployment.
Verify it: Open the link in a private window on another device and complete the one job from step one, start to finish.
STEP 06
Decide who fixes it, and how, before you need to
The honest weakness of vibe coding is not generation quality. It is what happens the first time something breaks and nobody understands the code.
Write down the answer to one question: if this stops working on a Friday and the model cannot fix it, what do you do? Rebuild it, pay somebody, or turn it off are all acceptable answers. Not having an answer is not.
Keep the prompts that built it. They are the closest thing to documentation that a vibe-coded project has.
Decide when it graduates. The moment it holds customer data, takes money, or a colleague depends on it, it needs a human who can read the code.
Expected result: A written answer to the Friday question, the prompt history saved, and a named condition that promotes the project out of vibe coding.
Verify it: Ask somebody else to read your Friday answer. If their reaction is a question you cannot answer, the plan is not a plan yet.
Four tests that catch most vibe-coded defects
None of these need a testing framework or any code from you. They are the cases a generated happy path routinely misses.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | Complete the one job the project exists for, exactly the way the first real user would, on a device that never opened the project before. | The job finishes and the result is visible: the record appears, the email arrives, the page updates. No step needs to be explained out loud. |
| invalid input | Submit an empty form, an email with no at sign, a 500 character name, and a negative quantity. | Each one is refused with a message a normal person can act on. Nothing is silently saved, and nothing shows a raw error page. |
| retry | Press the submit button twice within a second, then reload the page and submit the same thing again. | One record exists, not three. The second attempt is either blocked or recognized as the same submission. |
| production smoke | Open the published link in a private window on mobile data, complete the job, and check that the result actually arrived where it should. | It works with no signed-in session and no cached files, and the result lands in the place you will look for it tomorrow. |
The failure modes that show up again and again
These are the recurring ones. The pattern is the same in each: the model optimizes for code that looks right now, not for a system somebody maintains later. Where a number appears below it comes from a dated public study, not from us: METR's randomized controlled trial published in July 2025, and GitClear's code quality analysis of 211 million changed lines.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| It works for you and breaks for the second person who opens it. | State is being kept in the browser or in memory rather than saved anywhere, so it exists only in your session. | Open the same page in a private window. If your data is missing, nothing was ever stored. | Ask specifically for the data to be saved in a database and reloaded on page open, then repeat the private window check. |
| The model fixes the same bug over and over and it keeps coming back. | The conversation has grown past what the model can hold, so each fix is made without the context of the last one. | Ask it to explain what the current code does. If the explanation describes a version that no longer exists, the context is gone. | Start a fresh conversation, paste the current file, and describe the bug with the exact input that triggers it. Do not describe it as "still broken". |
| An API key or password is visible in the published page. | A secret was put in front-end code, where everything is downloadable by anyone who visits. | Open the published page, view source, and search for the key. If you can find it, so can a crawler. | Rotate the key immediately, because it is already exposed. Then move the call to the server side and republish. |
| The bill from a paid API is far higher than expected. | Generated code called a metered service inside a loop or on every render, with no limit. | Check the provider dashboard for request volume, then find every place the project calls it. | Add a hard spending cap at the provider first, since that works even if the code does not, then fix the call site. |
| Nobody can change the project any more, including the model. | Accumulated duplication and patched-over workarounds. GitClear analyzed 211 million changed lines through 2024 and found refactoring falling from about 25 percent of changed lines in 2021 to under 10 percent in 2024, with copy-pasted lines exceeding moved lines for the first time. | Ask the model to list every place a single behavior is implemented. Several answers for one behavior is the signal. | Rebuild the affected slice from the original one-sentence description rather than patching. On a small project this is usually faster than untangling it. |
| It felt fast, and the work still took longer than doing it by hand. | Time moved from writing to reviewing, prompting, and debugging. A METR randomized controlled trial published in July 2025 found 16 experienced open-source developers took 19 percent longer with early-2025 AI tools, while they had predicted a 24 percent speedup. | Time one task honestly, from first prompt to working result, including every fix round. | Use vibe coding where you have no other option to get a first version, and hand-write or review the parts you already know how to do. |
Running a vibe-coded project after it exists
Deploy
Publish one version at a time and note what changed. A vibe-coded project without a version note is impossible to bisect when it breaks.
Keep the last working version reachable. Restoring is the only recovery tool available to somebody who cannot read the code.
Point a real domain at it only after the four tests pass. A public URL invites traffic you have not planned for.
Monitor
Check that the one job still works on a schedule you actually keep, weekly at minimum. Generated projects fail silently because nobody wrote an alert.
Watch the spend on any metered service the project calls, and set a provider-side cap rather than trusting the code.
Ask the first real user to tell you when something looks wrong. For a small project, one honest user beats any dashboard.
Recover
Know the restore path before the incident: which saved point, how to reach it, how long it takes.
Keep the prompt history. Rebuilding a slice from the original description is often faster than repairing a tangle.
If the project holds anything you cannot recreate, export a copy of the data on a schedule. Code can be regenerated; a customer list cannot.
The security part, stated plainly
Generated code is not automatically insecure, and it is not automatically safe either. Published measurement points in the same direction, so treat these as defaults rather than optional extras.
- Never put an API key, token, or password in code the browser downloads. If it was there once, rotate it, because exposure is permanent.
- Validate every input on the server side. A check that runs only in the browser is a convenience, not a control.
- Do not point a prototype at a production database or a real customer list. Use a copy with fake records until the project has been reviewed.
- Assume anything reachable without a login will be found. Search engines and scanners do not wait for your launch date.
- Veracode's 2025 GenAI Code Security Report, updated in October 2025, tested code from over 100 large language models and found that gains in functional correctness did not come with gains in security, and that bigger models were not reliably safer than small ones.
- The same report found generated code introducing a security flaw in roughly 45 percent of its test cases, with Java the worst language measured. A clean-looking result is not evidence of a safe one.
Questions people ask about vibe coding
Who invented the term vibe coding?
Andrej Karpathy, a co-founder of OpenAI and former AI lead at Tesla, in a post in February 2025. He described giving in to the vibes, embracing exponentials, and forgetting that the code even exists, and said it was not too bad for throwaway weekend projects. Collins Dictionary named vibe coding its word of the year on 6 November 2025, which is roughly when the term stopped being a niche joke.
Is vibe coding the same as AI-assisted programming?
No, and the difference is the point. AI-assisted programming covers any use of a model to help write software, including code you read, test, and understand. Vibe coding is the narrower case where you accept the output without reviewing it. Simon Willison put it bluntly: if you reviewed, tested, and understood every line, that is software development with a model, not vibe coding.
Is vibe coding safe for production software?
Not on its own. Willison called vibe coding your way to a production codebase clearly risky, because most software work is changing systems that already exist, where understanding the code matters. The workable pattern is to generate freely, then review and test the parts that touch money, secrets, personal data, and anything a stranger can reach before real users arrive.
Does vibe coding actually make people faster?
It depends on who and on what. A METR randomized controlled trial published in July 2025 found that 16 experienced open-source developers working in their own large repositories took 19 percent longer with early-2025 AI tools, although they expected a 24 percent speedup. The gains are clearest for people who could not have built the thing at all, and for first versions rather than mature codebases.
What kinds of projects is vibe coding good at?
Small, self-contained, low-stakes things: internal calculators, personal trackers, one-off scripts, prototypes for a meeting, landing pages, and the first version of an idea you are still testing. It is weakest on large existing codebases, unusual problems with little public precedent, and anything where a quiet mistake is expensive.
Do I need to understand the code the AI writes?
Not to get started, and that is why the practice spread. You do need somebody who can read it before other people depend on the result. The realistic middle ground is to read four things: where secrets live, how input is validated, where data is stored, and what the app sends to other services.
What happens when a vibe-coded app breaks and nobody understands it?
You have three options: ask the model to fix it, rebuild the broken slice from the original description, or bring in somebody who can read the code. Decide which one applies before it happens. Keeping the prompts that built the project and a restorable saved point makes all three cheaper.
One place to try it
If you want to try vibe coding with the running part attached
Most tools stop at generating code. Playcode builds the project from a description and can also run it, with a backend, a database, hosting, and a saved point you can restore when a change goes wrong. That last part is the one that matters most when you cannot read the code yourself.
See how vibe coding works on PlaycodeNo credit card required. AI credits included to start.