Vibe coding, meaning accepting AI-written code without reading it, is reasonable where failure is visible and cheap, and not acceptable once the code touches other people’s data, money or credentials.
- It means not reading the code. Using AI to write code and then reading it is a different practice with different risks.
- It suits throwaway work. One-off scripts, prototypes, personal projects with no users or data, and anything with a test that fails loudly.
- Unread code has hidden costs. Security flaws you cannot see, dependencies you did not choose, and bugs you have to read your way out of later.
- Repeated self-fixing can make it worse. A model patching its own code works from the same picture that produced the bug.
- Read before it matters. Generate freely, but read it, or have someone read it, before it handles anyone else’s data.
"Vibe coding" means building software by describing what you want and accepting what the AI produces — without reading the code.
It often works, and that is its appeal. The question is what you have actually shipped when you cannot say what it does.
What the term actually describes
It is not “using AI to code.” Most developers now use AI tools, and most say vibe coding is not part of their professional work. Vibe coding is the specific practice of not reading it — you describe, it builds, you check whether it appears to work, you ship.Stack Overflow, 2025 Developer Survey, AI section, read at source 23 Sep 2026: “84% of respondents are using or planning to use AI tools in their development process”, and “Most respondents are not vibe coding (72%), and an additional 5% are emphatic it not being part of their development workflow.” The survey defines vibe coding more broadly than this page, as “the process of generating software from LLM prompts”; it did not ask whether developers read every line.
The distinction matters because the risks belong entirely to the second version.
Where it genuinely works
- Throwaway tooling. A script you run once. If it is wrong you notice immediately and the cost is a re-run.
- Prototypes you will not ship. Proving a shape before committing to build it properly.
- Personal projects with no users and no data. The blast radius is you.
- Anything with a test that fails loudly. The test is doing the reading you are not.
Every case where it works has the same property: failure is visible and cheap.
What it costs when those conditions do not hold
Vulnerabilities you cannot see
Published rates for security flaws in AI-generated code run roughly 40% to 70% depending on model, language and method. The widely quoted 40% traces to a 2022 Copilot study.Pearce et al., Asleep at the Keyboard?, 2022: “we found approximately 40% to be vulnerable”. Veracode, 2025 GenAI Code Security Report: “45% of code samples failed security tests”, with Java at “a 72% security failure rate across tasks”. Both as read at source for Auditing AI Work, 11 Sep 2026.
Code nobody read is code nobody checked. That is not a probabilistic statement — it is a description.
Dependencies you did not choose
Generated code imports things. Some of those packages do not exist and get invented; some exist and are abandoned; and an attacker can register a name a model tends to hallucinate, so the invented package exists the next time.Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025, read at source 23 Sep 2026: across 576,000 code samples from 16 models, “the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models”; the paper calls this “a novel form of package confusion attack”. The abandoned-package case is this site’s reasoning, not from the paper.
You inherit every one of them without deciding to.
You cannot debug what you cannot read
The moment it breaks in a way the model cannot fix, you are reading it anyway — under pressure, without the context you would have built by writing it.
The reading was not avoided. It was deferred to the worst possible moment.
It can get worse with each pass
Asking a model to fix code it wrote, repeatedly, is a loop with no outside information in it. The patch is generated from the same picture that produced the bug. In one controlled test of repeated “improvement” passes, critical vulnerabilities rose rather than fell.Shukla, Joshi & Syed, Security Degradation in Iterative AI Code Generation — A Systematic Analysis of the Paradox, 2025, read at source 23 Sep 2026: over 400 code samples and 40 rounds of “improvements”, “Our findings show a 37.6% increase in critical vulnerabilities after just five iterations”. One controlled experiment, not a law of every model. See also Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024, read at source 23 Sep 2026: “LLMs struggle to self-correct their responses without external feedback”. See loops that improve and loops that degrade.
The honest position
Vibe coding is a legitimate technique with a narrow correct application, being applied broadly because it feels like leverage.
- If nobody's data touches it, vibe away. The practice is fine.
- If it handles anyone else's data, read it — or have someone who can.
- If it touches money, auth or personal records, it is not a vibe-coding task. No framing changes that.
- If you are selling it, you have a disclosure obligation — see what you owe a client.
The practical middle is generate freely, then read before it matters. The security checklist is what "read" means in practice.