The Cons of Vibe Coding (And Why "It Works" Isn't the Same as "It's Done")

Vibe coding, the practice of describing what you want in plain language and letting AI generate the code, has made building software faster than at any point in the industry's history. It's also quietly building one of the largest unmanaged risk surfaces software has ever seen. The term itself is barely two years old, coined by Andrej Karpathy in early 2025 to describe a deliberate departure from reading and reasoning through code, in favor of "giving in to the vibes." What's happened since is a genuinely useful productivity shift, sitting directly on top of a genuinely serious quality and security problem. Both things are true at once, and most coverage only tells you one half.

The vulnerability numbers are not small

Start with the security data, since it's the most measurable part of this story. Independent testing across more than 100 large language models on security-sensitive coding tasks found that close to half of AI-generated code samples introduce OWASP Top 10 vulnerabilities, a pass rate that hasn't meaningfully improved across multiple testing cycles even as general coding benchmarks kept climbing. In other words, models have gotten better at writing code that runs. They haven't gotten meaningfully better at writing code that's secure, and those are different skills the benchmarks mostly aren't measuring.

The enterprise data tells the same story at scale. One security analytics firm tracked code commits across tens of thousands of repositories at Fortune 50 companies and found that AI-assisted developers shipped code three to four times faster than their peers, but their monthly security findings rose roughly tenfold over six months. Speed went up. So did the rate of mistakes, faster than review processes could catch them.

A separate audit of over 1,400 vibe-coded production applications found that the majority had security issues, with a significant share containing at least one critical vulnerability, including hundreds of exposed secrets and personally identifiable information like financial account data sitting in plain view. Researchers tracking CVEs specifically attributable to AI-generated code have watched that monthly count climb sharply month over month in 2026, and they believe the true figure across the broader open-source ecosystem is several times higher than what's been formally documented, simply because most AI coding tools don't leave a clear trail showing which lines came from a model.

The debt is harder to pay down than normal technical debt

Every engineer has shipped a quick, imperfect solution under deadline pressure. That's normal technical debt, and it's manageable because you know it's there and you remember why you made the tradeoff. Vibe coding debt is structurally different: the code works, you don't fully understand why it works, and when it breaks in production at an inconvenient hour, you're debugging logic nobody on your team actually wrote or reasoned through.

This shows up clearly in the data on what AI coding tools are doing to existing codebases. Code duplication has risen sharply since AI tool adoption accelerated, refactoring activity has collapsed, and code churn, the rate at which code gets rewritten shortly after being written, has climbed as well. That combination is a specific signature: more code being generated, less of it being cleaned up, and more of it needing to be rewritten almost immediately. It's the opposite of what "faster development" is supposed to deliver.

There's also a quieter ownership problem underneath the technical one. When code comes from a prompt rather than a person, responsibility gets fragmented across the person who wrote the prompt, the AI agent that generated the output, whoever reviewed it (if anyone did), and whoever eventually owns the service in production. The person shipping the feature often can't fully explain how it works if asked, not because they're careless, but because they never wrote it line by line in the first place. When something breaks, fixing it becomes less like debugging and more like a scavenger hunt through code with no clear author.

"It passes the tests" is a lower bar than it sounds

One of the more unsettling findings from security researchers studying AI-generated code is that the vulnerabilities are often invisible by design. They're not bugs that throw errors or crashes that show up in normal testing. They're logical flaws, like an API endpoint that correctly checks whether a user is logged in, but never checks whether that specific user should have access to the specific resource they're requesting. Code like this passes every test you'd normally write, looks completely reasonable in a code review, and only reveals the flaw under conditions nobody thought to test for. Vibe coding doesn't just produce more code, it produces more code that looks finished without actually being finished.

This is what makes vibe coding genuinely different from past waves of "make development easier" tooling. It doesn't break existing review processes outright, it just pushes far more change through them, far faster than those processes were ever designed to handle. The result isn't one catastrophic failure. It's hundreds of individually reasonable, fast decisions, made under pressure to ship, that quietly compound into a codebase nobody fully understands.

The junior developer pipeline problem nobody's talking about

There's a second-order consequence worth taking seriously, and it's a longer-term one. A meaningful share of engineering leaders now say they plan to hire fewer junior developers as a direct result of AI coding tools. That's a reasonable short-term cost decision. It's also exactly backwards from what fixing this problem will require, because the judgment needed to clean up AI-generated technical debt is precisely the judgment engineers develop by spending years debugging code, including their own mistakes. If organizations stop hiring and training junior engineers now, the mid-level engineers needed in a few years to clean up today's vibe-coded systems simply won't exist with the experience required to do it.

None of this means avoid AI coding tools

The honest conclusion isn't "don't vibe code." It's that vibe coding is a tool with a clear, bounded use case, and a clear, bounded set of situations where it's actively dangerous. Security researchers studying this in 2026 have converged on a rough but useful line: scaffolding around already-validated components, fine; small, reviewable changes to existing code, fine; novel security implementations nobody on the team can independently verify, no; entire production codebases generated from scratch and shipped without dedicated review, only acceptable if you're genuinely willing to treat the result as disposable.

For prototyping, internal tools, and bounded low-stakes tasks, vibe coding is a legitimate productivity gain and not a controversial one. The danger is specifically in treating it the same way for payment processing logic, authentication systems, or anything touching customer data, where the cost of an invisible flaw is measured in breached accounts and regulatory exposure, not a failed unit test.

What this means practically

A few principles that hold up across the research, regardless of team size:

• Match the review intensity to the risk, not the speed of the tool. A vibe-coded internal dashboard and a vibe-coded payment endpoint do not deserve the same level of scrutiny, and treating them the same is how the riskiest code ends up with the least review.

• Track the leading indicators, not just whether the feature works. Code churn, duplication, and security findings trending upward over time are a sign that velocity gains are illusory, even while everything still technically runs.

• Build the skill of reading AI-generated code critically, not just writing prompts. This is trainable in a matter of hours, not years, and it's quickly becoming one of the highest-leverage skills on a development team.

• Don't let AI hollow out your junior pipeline. The people who'll be capable of fixing tomorrow's AI-generated mess are the people getting that debugging experience today, and that experience doesn't come from prompting.

• Treat AI as a fast, capable junior developer, not an autonomous engineer. Powerful and quick, genuinely useful, but not yet trustworthy enough to operate without supervision on anything that matters.

Vibe coding isn't wrong. It's incomplete. Speed without review isn't really speed, it's just a faster route to the same failure, arriving with less warning and a codebase nobody can fully explain.