Is vibe coding bad?
Short answer
Vibe coding is fine for throwaway prototypes and risky for code other people run: in a 2022 study, assistant users wrote less secure code yet felt more confident.
Merriam-Webster defines vibe coding as writing code in a somewhat careless fashion, with AI assistance. A 2024 study found models recommending packages that do not exist, and the US Copyright Office said in January 2025 that prompts alone do not make you the author. Ship generated code only after you have read it, checked its dependencies and licence, and written down how it was made.
What the evidence says
- Less secure Participants with an AI assistant wrote significantly less secure code, and were more likely to believe it was secure, in a 2022 user study. Perry et al., arXiv 2211.03622
- 19% Longer to finish issues for 16 experienced open-source developers allowed AI tools, in METR's July 2025 trial. METR now marks these results as out of date. METR, 10 July 2025
- 21.7% Average share of hallucinated package recommendations from open-source models in a 2024 study of 576,000 samples; at least 5.2% for commercial models. Spracklen et al., arXiv 2406.10279
What is vibe coding?
Vibe coding means asking an AI assistant for a program in plain language and accepting what it writes without reading it closely. Merriam-Webster's slang entry defines it as writing computer code in a somewhat careless fashion, with AI assistance, and adds that the coder does not need to understand how or why the code works and often has to accept some bugs and glitches. The same entry credits the term to Andrej Karpathy, quoting his post of 2 February 2025 about a new kind of coding where you fully give in to the vibes and forget that the code even exists.
That last clause is the whole question. Using an assistant to write code is ordinary now; forgetting the code exists is the part that carries the risk. A reader who pasted a script from a library page into a personal site twenty years ago did something similar: took working code from somewhere else and trusted it because it ran. The difference is volume. An assistant can produce a whole application in an afternoon, and every line of it is yours to answer for once it ships.
Is vibe coding bad for every kind of project?
No. It depends on who will run the result and what it can touch. A personal script that renames files on your laptop, a prototype shown to a colleague and then deleted, a game built for fun on a Sunday: in each case the only person exposed to the bugs is you, and you can see them happen. Speed is a fair trade there.
The trade changes the moment someone else is on the receiving end. A web page serves its code to every visitor. An app with a login stores other people's passwords. A library you publish ends up inside other people's projects. Each of those needs a person who has read the code and can explain it.
What do you take on when you ship generated code?
Security flaws you did not notice. In the 2022 user study Do Users Write More Insecure Code with AI Assistants?, Perry, Srivastava, Kumar and Boneh found that participants with access to an assistant based on the codex-davinci-002 model wrote significantly less secure code than those without it, and were more likely to believe their code was secure. Participants who trusted the assistant less and worked harder on their prompts produced code with fewer vulnerabilities.
Dependencies that are not what they seem. In a 2024 arXiv paper, Spracklen and colleagues used 16 models to generate 576,000 code samples and found that at least 5.2% of recommended packages from commercial models, and 21.7% from open-source models, were hallucinated, with 205,474 unique invented names. The authors describe this as a new form of package confusion attack.
Licence terms that travel with copied code. GitHub's documentation on Copilot code referencing says that when an accepted inline suggestion matches public code, the log records the matching file URLs and the licence found, and that such matches typically occur in less than one percent of suggestions. Rare is not never.
Ownership you may not have. On 29 January 2025 the US Copyright Office released Part 2 of its AI report, concluding that AI outputs can be protected only where a human author has determined sufficient expressive elements, which does not include the mere provision of prompts.
Does vibe coding make developers faster?
Not always. In a randomised controlled trial published on 10 July 2025, METR recruited 16 experienced developers from large open-source repositories and had them work on 246 real issues. When allowed AI tools, they took 19% longer. Beforehand they expected a 24% speed-up, and afterwards they still believed AI had sped them up by 20%.
Read that result with its limits. METR's page now carries a note that these results are out of date and links a 2026 update. The study measured experienced people on codebases they knew well, which is not the same as a beginner building a prototype. What it does show is that perceived speed and measured speed can differ.
How do you vibe code without regretting it?
Keep vibe coding for work where mistakes are cheap and visible: code that runs only for you, touches no real data or credentials, and can be thrown away. Before anything handles real users or data, read every line, look up every new dependency on its registry, search the code for keys and tokens, and check whether any block matches public code.
Then write down how the code was made: which assistant, roughly when, what you asked for, and what you changed. Nobody can reliably prove from the code alone that it was generated, and you cannot prove it was not, unless you kept a record at the time.
An assistant can write the code in a minute; the person who ships it answers for it for years.
How we checked
Checked on 2026-10-15 by the CodeLifter editors: the Merriam-Webster slang entry for vibe coding, the arXiv abstract pages for papers 2211.03622 and 2406.10279, METR's study page of 10 July 2025, GitHub's Copilot code referencing documentation and US Copyright Office NewsNet issue 1060. Karpathy's post is quoted as Merriam-Webster reproduces it. We used only figures stated on those pages, and CodeLifter has not run any study of its own. Drafted with AI assistance; every claim checked against its source.
Questions and answers
Is vibe coding bad?
Not for throwaway work. It becomes risky when other people run the code: in a 2022 user study by Perry and colleagues, assistant users wrote less secure code while believing it was more secure.
What does vibe coding mean?
Merriam-Webster defines it as writing computer code in a somewhat careless fashion, with AI assistance, and credits the term to Andrej Karpathy's post of 2 February 2025.
Is vibe coding safe for a production app?
Only after a human review. Generated code can contain injection flaws, hard-coded secrets and imports of packages that do not exist; a 2024 study found open-source models recommending hallucinated packages 21.7% of the time on average.
Does AI make developers faster?
Not always. In METR's July 2025 trial, 16 experienced open-source developers took 19% longer when allowed AI tools, though they believed they were faster. METR now marks those results as out of date.
Do I own code I vibe coded?
Possibly not all of it. The US Copyright Office said in January 2025 that AI output is protected only where a human determined sufficient expressive elements, and that prompts alone are not enough.
Is vibe coding the same as using GitHub Copilot or Cursor?
No. Those are tools, and vibe coding describes one careless way of using them. A developer who reads, tests and edits every suggestion is using an assistant, not vibe coding in Merriam-Webster's sense.
Should I disclose that code was vibe coded?
Yes, where a project, course or client asks, and it is good practice everywhere else. A short note in the commit message stating the tool and what you changed is enough for most projects.
Sources
An editor checked every claim on this page against these sources on 2026-10-15. If a source has changed since, the source is the authority.
