Vibe coding: what it is, and where it breaks

Last updated: 21 July 2026

Vibe coding is the practice of building software by prompting an AI assistant and accepting whatever it produces, without reading, reviewing or fully understanding the code. The term was coined as a description of a fast, low-stakes way to make throwaway projects. The problem is not the technique itself, it is what happens when the same technique is used to ship software that real people, real attackers and real dependency registries then get to touch. This guide defines vibe coding precisely, separates it from disciplined AI-assisted engineering, and maps the specific, measurable places it breaks once the code leaves the weekend project and reaches production.

Where the term came from

Andrej Karpathy, an OpenAI co-founder and former director of AI at Tesla, coined "vibe coding" in a post on 2 February 2025. His own description is the clearest definition anyone has given:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists... I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it... It's not too bad for throwaway weekend projects, but still quite amusing." [1]

Two things in that quote matter, and both tend to get dropped when the term is repeated. The first is the mechanism: "I don't read the diffs anymore." Vibe coding is defined by the absence of review, not by the use of AI. The second is the scope: "throwaway weekend projects." Karpathy described a way of playing, not a way of shipping. The drift from the first meaning to the second, from a weekend toy to a production system, is where every problem in this article begins.

Vibe coding is not the same as AI-assisted engineering

Within weeks of the term spreading, the software engineer and widely-cited LLM commentator Simon Willison published the clarification that has become the reference definition. He drew the line exactly where it belongs, at review:

"Vibe coding is building software with an LLM without reviewing the code it writes... 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, that's using an LLM as a typing assistant." [2]

This distinction is the whole argument. An AI assistant can write every line of a codebase that a senior engineer then reads, tests and stands behind, and that is not vibe coding, it is engineering with a faster keyboard. Willison later coined a second term, "vibe engineering", for that disciplined end of the spectrum, precisely because the industry had started applying "vibe coding" to serious, shipped software that was never the original claim [2].

	Vibe coding	AI-assisted engineering
Code review	Skipped: accept all, no diff reading	Every change read and understood
Testing	Ad hoc or none	Automated and manual tests maintained
Suitable for	Throwaway prototypes, personal projects	Production software shipped to real users
Accountability	None claimed	A named engineer stands behind every line

Hold on to the right-hand column. Everything Zegaware does is on that side of the line, and everything that follows is a measurement of what happens on the left.

Why this matters now

AI-assisted development is no longer a fringe practice, which is why the failure modes below are no longer edge cases. Google's DORA research, the most substantial longitudinal study of software delivery, found AI adoption among developers rose from 76% in 2024 to 90% in 2025 [3]. Stack Overflow's 2025 developer survey, drawn from a different and larger sample, put AI-tool adoption at 84%, up from 76% the year before [4].

Adoption and trust are moving in opposite directions, which tells you developers already sense the problem. In the same Stack Overflow survey, only around 29% of respondents said they trust the accuracy of AI output, and the single most common frustration, cited by roughly two-thirds, was "AI solutions that are almost right, but not quite" [4]. DORA's conclusion is the most useful frame available: AI is an amplifier. Teams with strong testing, review and version control get faster and stay stable; teams without them ship more and break more [3]. Vibe coding is what the second outcome looks like in practice.

Where vibe-coded software breaks

When code that nobody reviewed meets production, it breaks in a small number of predictable ways. Each of the five below is measured, not asserted.

It ships insecure code by default. Veracode's 2025 GenAI Code Security Report tested more than 100 models across around 80 coding tasks and found that AI-generated code introduced a vulnerability aligned with the OWASP Top 10 in 45% of cases, a rate that did not improve as the models got larger and more capable [5]. Veracode sells application-security testing, so read the figure as vendor research, but the direction is corroborated by independent academic work. A peer-reviewed Stanford study presented at ACM CCS found that developers given an AI assistant wrote significantly less secure code than a control group, and were at the same time more likely to believe their code was secure [6]. The failure mode is specifically uncritical acceptance: the same study found that participants who questioned the AI and reworked their prompts produced fewer vulnerabilities. That these risks are now catalogued formally, in the OWASP Top 10 for LLM Applications, tells you this is an established discipline rather than hand-wringing [7].

It leaves secrets in the source. Hard-coded credentials are one of the most common critical findings in any code review, and AI has made them more common. GitGuardian detected 23.77 million new hardcoded secrets in public GitHub commits in 2024, a 25% year-on-year rise, and in a sample of repositories with an AI coding assistant active it found secrets leaked at 6.4%, against a 4.6% baseline across all public repositories, roughly 40% higher [8]. GitGuardian sells secrets detection, so the incentive is noted, but the pattern matches what we find in audits: a live key committed during a demo, never rotated, sitting in the git history where anyone can retrieve it.

It invents dependencies that attackers can exploit. Coding assistants routinely recommend software packages that do not exist. A peer-reviewed study at USENIX Security 2025 generated 576,000 code samples across 16 models and found that 19.7% of recommended packages were hallucinated overall, with the rate reaching 21.7% for open-source models against 5.2% for commercial ones, and catalogued 205,474 unique fictional package names [9]. Because the same hallucinated names recur reproducibly, an attacker can register one on a public registry such as npm or PyPI and wait for a developer to install it on the AI's say-so, a supply-chain attack now called slopsquatting. A vibe coder who runs the install command without checking has no defence against it.

It accrues maintenance debt faster than anyone pays it down. The structural damage is visible in the code itself. GitClear analysed 211 million changed lines of code from 2020 to 2024 and found that copy-pasted lines rose from 8.3% in 2021 to 12.3% in 2024, while lines associated with refactoring fell from 25% to under 10%; 2024 was the first year in its dataset where duplicated code outnumbered code that was reused [10]. Duplication is how debt spreads: the same logic copied across a codebase means a single bug has to be found and fixed in every copy. We cover the full picture in AI technical debt: what AI coding tools leave behind, and how to pay it down.

It feels faster than it is. The productivity case for skipping review assumes the speed is real. It is not always. In a randomised controlled trial by the research organisation METR, 16 experienced open-source developers completed 246 real tasks with and without AI tools. They forecast that AI would cut their time by 24%, and believed afterwards that it had made them 20% faster. In fact, allowing AI made them 19% slower [11]. If disciplined engineers working in code they know well can be slowed down while feeling accelerated, the time a vibe coder believes they are saving by not reviewing is even less trustworthy.

What we find when we audit vibe-coded software

We run these reviews for a living, and the findings above are not a literature summary, they are the recurring categories that a structured audit surfaces in the first afternoon. Duplicated logic with no single place to change it. Test suites that assert the application started, but never that an unauthorised request is rejected. An authorisation check that is present on one route and quietly missing on the next. A hallucinated package that resolved by luck. A key in the source. None of it is exotic, which is exactly why it is findable, and exactly why it is dangerous when nobody looks.

The point is not that AI writes bad code. Given a reviewed prompt and a senior engineer reading the output, it writes a great deal of good code quickly. The point is that vibe coding removes the one step that catches all of the above. We describe the specific patterns a review turns up in what a vibe code audit actually finds, the checklist a team can apply itself in how to review AI-generated code, and, because we hold ourselves to the same standard, the audit we ran on one of our own internal tools.

Where vibe coding is fine, and where it is not

Vibe coding is a genuinely good way to work in the place Karpathy described it: a throwaway prototype, a personal script, a weekend experiment, a proof of concept you intend to rebuild. When nothing is shipped, no personal data is touched, and the cost of a bug is your own time, the speed is a real gain and the missing review costs you nothing. Use it there without guilt.

The line is crossed the moment the output goes in front of a user, handles someone else's data, takes a payment, or becomes the thing your business runs on. At that point the code has stopped being a vibe and started being a product, and a product needs the discipline in the right-hand column of the table above. Founders get into trouble not by vibe coding a prototype, but by shipping the prototype, because it worked in the demo, without anyone ever reading it. Turning that prototype into something safe is the subject of from AI MVP to production: what it actually takes.

"Nobody reviewed it" is not a defence

For a UK business, the accountability question is not optional, and it does not care who or what wrote the code. Responsibility for shipped software sits with the organisation that ships it. The National Cyber Security Centre and its international partners set out, in the first internationally agreed guidelines for secure AI, that security must be a requirement "throughout the life cycle of the system", not just at the point of writing [12]. In May 2025 the UK government went further, publishing the Software Security Code of Practice through the Department for Science, Innovation and Technology and the NCSC, a baseline for reducing "avoidable weaknesses in software development and maintenance practices" [13]. Software that no human reviewed is precisely the software that code is meant to govern. And where personal data is involved, the Information Commissioner's Office is clear that accountability under UK data protection law rests with the controller organisation regardless of how the processing code came to exist [14].

Even the largest AI adopters state the review step as non-negotiable. Google's chief executive Sundar Pichai told investors that more than a quarter of new code at Google is generated by AI, and described it in the same breath as being "reviewed and accepted by engineers" [15]. As a Google Cloud engineer put it, the bottleneck did not disappear when AI started writing code, it moved from writing the code to the people reviewing it [16]. Vibe coding is the decision to leave that new bottleneck unstaffed.

Frequently asked questions

What is vibe coding?

Vibe coding is building software by prompting an AI assistant and accepting its output without reading, reviewing or understanding the code. Andrej Karpathy coined the term in February 2025 to describe fast, low-stakes work on throwaway projects. It is defined by the absence of review, which is what separates it from disciplined AI-assisted engineering.

Is vibe coding safe for production software?

No, not on its own. The technique is fine for prototypes and personal projects, but shipping unreviewed AI code introduces measurable risk: a Veracode benchmark found 45% of AI-generated code carried an OWASP Top 10 vulnerability, and academic research links AI assistance to less secure code and false confidence. Production software needs a review step vibe coding removes.

What is the difference between vibe coding and AI-assisted engineering?

The difference is review. In vibe coding, nobody reads the AI's output before it ships. In AI-assisted engineering, an AI may write every line, but a senior engineer reviews, tests and understands all of it and stands behind it. As Simon Willison puts it, reviewed AI code is not vibe coding, it is using an LLM as a typing assistant.

Why does vibe coding produce insecure code?

Because the model optimises for code that plausibly satisfies the prompt, not for code that is secure or fits your system. It learned from public code full of shortcuts and reproduces them confidently. Without review, insecure defaults, hard-coded secrets and hallucinated dependencies all ship unchallenged. A Stanford study found the failure mode is uncritical acceptance of that first output.

Can we still use AI coding tools safely?

Yes. The tools genuinely accelerate delivery and are worth keeping. DORA's research shows the difference between teams that improve with AI and teams that destabilise is not whether they use it, but whether they have strong testing, version control and a review gate. Keep the speed, restore the discipline, and put a senior engineer between generation and production.

The honest answer

Vibe coding is a real and useful way to build throwaway things quickly, and it was described that way by the person who named it. The trouble starts when the weekend prototype gets shipped, because the one thing vibe coding leaves out, a person who has read and understood the code, is the one thing that shipped software cannot do without. Every failure mode above is a measurement of that missing step.

If you have built something with AI and are not sure whether it is safe to put in front of customers, that is exactly the question a senior engineer can answer. Book a Vibe Code Audit and we will read the code, tell you honestly what we find, rank it by what it is costing you, and put our name to the verdict. For the broader question of readiness, start with whether AI-generated code is safe to ship.

Sources

1. Andrej Karpathy, post on X, 2 February 2025. https://x.com/karpathy/status/1886192184808149383
2. Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", 19 March 2025. https://simonwillison.net/2025/Mar/19/vibe-coding/
3. DORA / Google Cloud, "State of AI-assisted Software Development 2025", 2025. https://dora.dev/dora-report-2025/
4. Stack Overflow, 2025 Developer Survey, AI section, 2025. https://survey.stackoverflow.co/2025/ai/
5. Veracode, "2025 GenAI Code Security Report", 2025. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
6. Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh, "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023, arXiv:2211.03622. https://arxiv.org/abs/2211.03622
7. OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2025", announced 17 November 2024. https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/
8. GitGuardian, "The State of Secrets Sprawl 2025" and "Yes, GitHub's Copilot can Leak (Real) Secrets", March 2025. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/
9. Joseph Spracklen, Raveen Wijewickrama, A. H. M. Nazmus Sakib, Anindya Maiti and Bimal Viswanath, "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", USENIX Security 2025, arXiv:2406.10279. https://arxiv.org/abs/2406.10279
10. GitClear, "AI Copilot Code Quality: 2025 Research", February 2025. https://www.gitclear.com/ai_assistant_code_quality_2025_research
11. Joel Becker, Nate Rush, Elizabeth Barnes and David Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", METR, July 2025, arXiv:2507.09089. https://arxiv.org/abs/2507.09089
12. National Cyber Security Centre and CISA, "Guidelines for Secure AI System Development", 27 November 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
13. Department for Science, Innovation and Technology and NCSC, "Software Security Code of Practice", 7 May 2025. https://www.gov.uk/government/publications/software-security-code-of-practice
14. Information Commissioner's Office, "Guidance on AI and data protection". https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
15. Sundar Pichai, "Alphabet Q3 earnings call: CEO Sundar Pichai's remarks", Google, 29 October 2024. https://blog.google/inside-google/message-ceo/alphabet-earnings-q3-2024/
16. Lee Boonstra, "When AI writes the code, who reviews it?", Google Cloud, 28 April 2026. https://cloud.google.com/transform/when-ai-writes-the-code-who-reviews-it-cto-google-cloud