Vibe Coding Is Quietly Breaking Production Systems — Here's the Evidence

AI coding tools are genuinely extraordinary. In the hands of an engineer who understands what they are doing, they accelerate delivery, eliminate boilerplate, and surface options that might have taken hours to find manually. That is real, and it is not going away.

Vibe coding — the practice of describing what you want, accepting AI-generated output, running it to see if it appears to work, and shipping it without reading, understanding, or owning it — was named by AI researcher Andrej Karpathy in February 2025. His description was disarmingly casual: "You fully give in to the vibes, embrace exponentials, and forget that the code even exists."

For a throwaway prototype, that trade-off is defensible. The moment that workflow enters a production system — one handling real users, financial transactions, patient data, or regulated records — it becomes one of the most reckless practices the industry has normalised in years.

This article is not an argument against AI tools. It is an argument against the absence of engineering judgement in using them — and a detailed examination of what that absence actually costs.

What is vibe coding? Vibe coding is the practice of using AI tools to generate code based on natural language prompts, accepting the output without reading or fully understanding it, and shipping it based on surface-level testing. The term was coined by Andrej Karpathy in February 2025.

1. What Vibe Coding Actually Produces — and Why It Is Unreliable

To understand why vibe-coded output is structurally unreliable, it helps to understand what an LLM is actually doing when it generates code.

A large language model does not reason about a problem and derive a correct solution. It predicts the most statistically likely sequence of tokens given the prompt, based on patterns learned from billions of lines of code scraped from across the internet — including production systems, tutorial blogs, Stack Overflow threads from 2012, deprecated libraries, and codebases riddled with known vulnerabilities.

When the model produces code that appears to work, it is because similar patterns appeared in its training data and led to working outcomes in those contexts. When those patterns carry embedded assumptions, anti-patterns, or security weaknesses from those training sources, the model reproduces those too — with full confidence.

The developer who accepts the output without reading it has no mechanism to catch this. The code looks plausible. It runs without errors in the happy path. It passes the shallow smoke test. And it ships.

"The most dangerous output from an AI coding tool is not code that fails visibly — it is code that succeeds silently while doing something catastrophically wrong."

2. Vibe Coding Security Risks: What Peer-Reviewed Research Found

This is not a matter of opinion or anecdote. Multiple peer-reviewed studies have examined what AI coding tools produce when security is at stake, and the findings should be mandatory reading for any engineering team adopting these tools.

Study 1 — NYU / IEEE S&P 2022

Hammond Pearce et al. at New York University evaluated an AI coding assistant across 89 scenarios specifically constructed to probe common vulnerability classes. Their paper, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions" (arxiv.org/abs/2108.09293), found that approximately 40% of generated code contained exploitable security vulnerabilities — across SQL injection, buffer overflows, path traversal, hardcoded credentials, and insecure randomness.

Study 2 — Stanford / USENIX Security 2023

Neil Perry et al. conducted a controlled user study where participants were given security-sensitive programming tasks, one group with an AI assistant and one without. Their paper, "Do Users Write More Insecure Code with AI Assistants?" (arxiv.org/abs/2211.03622), found two things:

• Participants using the AI assistant produced significantly more insecure code than those working unaided.
• Those same participants rated their code as more secure than the control group rated theirs.

The tool did not just introduce vulnerabilities. It introduced false confidence that made developers less likely to look for them.

Study 3 — University of Quebec 2023

Tony et al., in "LLMs Cannot Reliably Identify Vulnerable Code" (arxiv.org/abs/2308.09262), found that when LLMs were asked to identify whether code was vulnerable, they performed below chance on several vulnerability classes — confidently classifying vulnerable code as safe and safe code as vulnerable at rates that make them unreliable as a security review mechanism.

The compounding implication is severe: these tools generate insecure code, make developers feel confident about it, and cannot reliably identify the vulnerabilities when asked to review.

3. The OWASP Vulnerabilities AI Code Generation Keeps Reproducing

The vulnerabilities produced by AI-generated code are not exotic or rare. They are the same categories that have powered the majority of public breaches for two decades — the OWASP Top 10. The following appear with documented regularity:

A developer who does not understand why these vulnerability classes exist will not recognise them in AI output. They will run the code, observe that it works, and ship it — because it does work. It simply also happens to be exploitable.

4. The Real Cost of Insecure AI-Generated Code: $4.88M Per Breach

The abstract becomes concrete when you look at breach economics.

IBM's Cost of a Data Breach Report 2024 (ibm.com/reports/data-breach) puts the global average cost of a single data breach at $4.88 million USD — a figure that has increased for three consecutive years. In financial services the figure exceeds $6.1 million. In healthcare, $9.77 million. These figures cover detection, containment, notification, regulatory fines, litigation, and reputational loss. They do not fully account for customer churn or long-term brand damage.

A single exploitable SQL injection endpoint — reproducible from AI-generated database access code in seconds — is sufficient to exfiltrate an entire user table. A single hardcoded API key committed in a generated configuration file can expose cloud infrastructure to complete takeover.

"A single hardcoded API key in an AI-generated file committed to a public repository is not a hypothetical risk. It is a documented attack vector with a measurable mean time to exploitation — measured in minutes, not days."

The GitGuardian State of Secrets Sprawl Report 2024 (gitguardian.com/state-of-secrets-sprawl) found that over 12.8 million secrets were exposed in public GitHub repositories in 2023 alone — API keys, database credentials, cloud provider tokens. AI coding tools that generate and suggest configuration code without enforcing secrets management are a direct contributor to this pattern.

5. Why Vibe-Coded Codebases Become Unmaintainable in Months

Security is the most acute problem. Maintainability is the most chronic one.

When an engineer writes code they understand, they are making decisions — about data structure, control flow, error handling, abstraction boundaries, naming. Those decisions encode understanding. When something fails six months later, the author or a teammate can trace the logic, identify where an assumption broke down, and fix it correctly.

AI-generated code accepted without understanding encodes no decisions. It encodes statistical patterns averaged across training examples, with no awareness of the system it is being dropped into. Over time, a vibe-coded codebase develops predictable characteristics:

Inconsistency at scale. A function generated in sprint two and a function generated in sprint twelve share no design intent. Different error handling patterns, different naming conventions, duplicate logic with subtle differences, conflicting assumptions about data shape. As the codebase grows, these inconsistencies compound rather than converge.

No mental model to debug from. When vibe-coded code fails, the developer has no foundation to reason from. They do not know why the code does what it does, so they cannot reason about why it is doing something wrong. The typical response is to prompt the AI again — generating a new block that may fix the visible symptom while introducing three new problems elsewhere.

Confident handling of the happy path, silent failure on the edges. AI models generate code that handles expected inputs reliably. Unusual inputs, boundary conditions, race conditions, and system-specific failure modes are exactly the places where generated code most frequently fails.

A 2023 GitLab survey of over 1,000 senior engineering and security professionals found that 79% reported security had become harder to manage as AI-generated code entered their codebases, with code accepted without full understanding cited as the primary cause (about.gitlab.com/developer-survey).