What Actually Is Vibe Coding, and Why the Term Matters

Back in February 2025, Andrej Karpathy—someone whose opinion on neural networks I’d trust with my mortgage—dropped a two-word term into the discourse that immediately crystallized something I’d been watching happen across codebases for months: “vibe coding.” The phrase describes a particular flavor of AI-assisted development where you essentially outsource code generation to an LLM without reading it deeply, treating the interaction more like a conversation than engineering. You ask Claude or Cursor to generate a feature, it spits back 200 lines, you glance at it, maybe run the tests, and ship it. Vibe: check.

The term stuck because it’s precise. It’s not about using AI tools—I use them daily and ship better code faster because of it. Vibe coding is about the specific abdication of judgment, the assumption that because an AI generated it, it’s probably fine. And that’s where we’ve hit the wall.

The Infrastructure Made Vibe Coding Easy to Fall Into

You can’t separate vibe coding from the tools that made it frictionless. Cursor, the AI-first IDE built atop VS Code, hit 500,000 active developers by mid-2025 and became the primary vehicle for this workflow after raising a $900 million Series B at a $9 billion valuation. Let that sink in: nine billion dollars valuing an editor. The product is genuinely good—the autocomplete is smooth, the chat interface is native to your workflow, and the integration is tight enough that generating code feels as natural as typing.

But smooth integrations cut both ways. When generating code is as easy as pressing tab and accepting the suggestion, the friction that once forced you to understand what you’re shipping disappears. I’ve watched junior developers in code review sessions struggle to explain why they added a particular function—not because they’re incompetent, but because they didn’t write it. They received it. There’s a meaningful difference, and it compounds across a codebase.

The Data Is Pointing at Real Problems

Here’s where I shift from anecdote to something harder to dismiss. The GitClear 2025 AI code quality research analyzed 153 million lines of code and found that AI-assisted codebases showed a 41% increase in what they call “churn code”—code written and then reverted or deleted within two weeks—compared to 2022 baselines. That’s not a rounding error. That’s a signal that something’s being generated that doesn’t survive contact with reality.

Churn code matters because it’s waste. Every line that gets written and deleted is time spent reviewing, testing, and integrating something that added nothing to the system. It’s the digital equivalent of construction crews pouring concrete on Monday and jackhammering it back up on Wednesday. Scale that across thousands of developers and you’re looking at real economic drag, plus the cognitive load of working in a codebase where a significant chunk of the history is just noise.

And then there’s security. The CISA Secure by Design initiative flagged LLM-generated code as a growing attack surface in their 2025 report, noting that AI tools frequently reproduce known vulnerable patterns—SQL injection, cross-site scripting, improper authentication flows—at measurable rates. These aren’t novel vulnerabilities that caught security researchers off guard. These are patterns we’ve been fighting since the 2000s. The fact that LLMs trained on billions of lines of code still emit them regularly is either sad or funny, depending on your disposition toward cosmic irony.

Where the Vibe Coding Practitioners Are Vulnerable

Netlify’s 2025 State of Web Development report found that 67% of frontend developers were using AI to generate entire components. That’s two-thirds of the people building the web. But only 23% reported consistently reviewing generated code for security implications before deployment. That gap—44 percentage points—is the vibe coding problem made concrete. You’re shipping code you didn’t thoroughly examine into production at scale.

I’m not saying AI-generated code is inherently dangerous. I’m saying that the vibe coding workflow treats code generation as fundamentally different from any other piece of critical infrastructure you’d deploy. You wouldn’t pipe environment variables into production without reading them. You wouldn’t auto-merge pull requests from strangers without review. But we’re increasingly treating AI generation like it’s exempt from that scrutiny.

The irony is that developers who complain most bitterly about code review being too strict are the same ones shipping AI-generated code without reading it. That’s not consistency. That’s convenience masquerading as pragmatism.

What Actually Works (And Why It Still Matters That You Think)

Here’s the thing I want to be crystal clear about: AI-assisted development is real and it’s good. I’m faster with Cursor than without it. My code is often better because I can offload boilerplate and focus on the architecture that matters. The tools aren’t the problem.

The problem is the vibe. It’s the assumption that speed is the only variable that matters, that reading code is somehow quaint, that your job is to press tab and keep moving. Real engineers—the ones I respect, anyway—use AI as a thought partner, not a thought replacement. They generate code quickly, then interrogate it. They ask why the suggestion chose that approach over another. They check for edge cases the AI missed. They make sure the generated code aligns with their actual domain constraints.

That takes maybe 15% more time than vibe coding. It catches 80% of the problems before they land in production. It’s the difference between delegating and collaborating, and that difference matters more than any benchmark ever will.

The backlash against vibe coding is justified because it’s not actually about being pro-AI or anti-AI. It’s about whether we maintain the basic engineering discipline that separates a profession from a copy-paste machine. If you’re pushing back on this trend in your own work, I’d like to hear what you’re seeing in your codebases. Drop a comment or send me a note—I genuinely want to know what’s working and what’s not in real production systems.