The Term That Made Developers Uncomfortable

In February 2025, Andrej Karpathy — former Tesla AI director, OpenAI co-founder, one of the most credentialed engineers alive — described his new coding workflow and called it "vibe coding." He said he was "fully giving in to the vibes," using voice-to-text to describe what he wanted, watching Cursor implement it, and mostly not reading the resulting code. When something broke, he pasted the error in and let the AI fix it.

The internet had opinions. Some developers cheered: finally, someone with real credentials saying the quiet part loud. Others winced: a machine writes code nobody reads, ships it to production, and that's... good? The debate that followed exposed a genuine fracture in how we think about software quality, professional skill, and what "engineering" actually means when AI removes the hardest parts of the craft.

Vibe coding is real. It's happening at scale. And the consequences for software quality are more complicated — and more serious — than either camp admits.

What Vibe Coding Actually Is

Karpathy's definition is deliberately casual, but the phenomenon it describes is precise: using AI coding assistants so aggressively that the developer stops reading most of the generated code and relies on observed behavior and AI-assisted debugging as the feedback loop. You describe intent, you see output, you test whether it does what you wanted. If not, you describe the failure and iterate.

This is distinct from "using GitHub Copilot to autocomplete functions" or "asking ChatGPT to explain a regex." In vibe coding, the AI is the primary author. The human is the product manager and QA tester. The understanding gap between what was written and what the developer comprehends is intentional and accepted.

By 2026, this is no longer fringe. A significant percentage of startups are shipping products where the founding team — often non-engineers or junior engineers — built the entire backend via AI prompts. Venture-backed companies are running codebases their CTOs have never fully read. Internal tools at large enterprises are being built by analysts who learned to code last quarter by talking to Claude.

The question isn't whether this is happening. It's what the actual downstream effects look like.

The Security Problem Is Worse Than You Think

Security researchers have begun documenting a pattern: AI-generated code tends to reproduce known vulnerability patterns at a higher rate than experienced developers writing from scratch. This isn't because the AI is malicious — it's because the AI is a statistical model trained on the entire history of human code, and a substantial chunk of that code has always been insecure.

SQL injection via string concatenation. Hardcoded credentials that seemed fine in a tutorial. Authentication middleware applied inconsistently across routes. Exposed admin endpoints with no access control. These patterns are common in training data and, in the absence of a developer who recognizes them and pushes back, they make it into production.

The vibe coding workflow makes this worse in a specific way: because the developer isn't reading the code, they can't recognize the vulnerability even if they know what to look for. The feedback loop is "does it work?" not "is it secure?" and those are radically different questions. A SQL injection vulnerability will pass every functional test until it's exploited.

This is creating a generation of applications that work — right up until they're attacked. And attackers, many of whom are now also using AI to accelerate their work, are well aware of this dynamic.

Technical Debt Is Accumulating at a New Speed

Technical debt has always existed. The vibe coding era is distinguished by the rate at which it accumulates and the difficulty of paying it down.

When a developer writes code they understand, the debt accrues in ways they can reason about: "I took a shortcut here, I'll need to refactor this later, this doesn't handle edge cases X and Y." When AI writes code a developer doesn't fully understand, the debt accrues invisibly. The shortcuts aren't named, the edge cases aren't documented in the developer's mental model, and the "I'll fix this later" moment never comes because there's no "this" to fix — just a blob of generated code that works until it doesn't.

Maintenance compounds the problem. When a vibe-coded system breaks in a complex way, the AI can often fix the immediate error. But fixing symptoms without understanding root causes creates tangled codebases where each AI-assisted patch introduces new assumptions that conflict with previous ones. After months of this, you have a system where every new feature request requires extensive AI negotiation because the codebase's internal logic has become too incoherent for any single mind — human or AI — to hold at once.

Senior engineers brought in to audit or extend these systems describe the experience as uniquely disorienting. The code is syntactically correct. It often has docstrings. It follows some conventions. But the architectural decisions don't connect to any coherent theory of the system's behavior. It's technically sophisticated incoherence — the worst kind to debug.

Where Vibe Coding Actually Works

It would be dishonest to write a one-sided polemic, because vibe coding genuinely works well in certain contexts, and those contexts are important.

Prototypes and proof-of-concept demos: if you're trying to show whether an idea is feasible or presentable enough to get funding or stakeholder buy-in, the quality bar is "does it demonstrate the concept?" not "can it scale to a million users?" Vibe coding is exceptional here. The speed advantage — days instead of weeks — is real and significant.

Internal tools with limited users and low security stakes: a data analyst who vibe-codes a dashboard that pulls from internal databases and is used by five colleagues is probably fine. The attack surface is minimal, the maintenance requirements are predictable, and the business value is real.

Personal projects and learning tools: using AI to build things you're curious about, even without deeply understanding the output, accelerates learning by giving you running systems to experiment with. This is genuinely valuable.

Scripts and automation: one-off tools that run locally, do a specific thing, and don't touch sensitive data or systems are low-risk candidates for vibe coding.

The problem is not that vibe coding exists. The problem is the systematic misapplication of vibe-coding workflows to production systems with real users, sensitive data, and complex failure modes — and the industry's current inability to reliably distinguish when that's happening.

The Professional Developer's Dilemma

Experienced developers are navigating a genuinely uncomfortable transition. AI tools make them faster, and using AI aggressively is increasingly an expectation rather than an option. But professional engineers have trained their instincts over years to read code, notice smells, ask "what happens when this fails?" Those instincts are being systematically bypassed when the workflow becomes "prompt, accept, test surface behavior."

There's a real risk that experienced engineers adopt vibe coding workflows for speed and, over time, let those instincts atrophy. The muscle of reading code carefully, reasoning about edge cases, thinking adversarially about failure modes — these require exercise to maintain. If AI handles the output and the feedback loop is purely behavioral, the deep reading skills may weaken precisely when the industry needs them most to audit and fix AI-generated codebases.

Some senior engineers are already describing this: they find themselves reaching for AI to explain code that they would have read and understood themselves two years ago. It's faster. But it means one fewer human who has deeply engaged with the system.

What "Quality" Means Now

The hardest question raised by vibe coding is definitional. If a system works reliably for users, handles its load, and hasn't been breached — does it matter that nobody fully understands its internals? Pragmatically, the answer edges toward "maybe not." But this answer only holds as long as the system operates within the conditions it was tested under.

Software quality has always been about behavior under stress — unexpected load, adversarial input, edge case combinations, years of accumulated changes. These stressors reveal whether there was coherent engineering behind the working system or just a working-in-the-average-case system that will fail in interesting ways at the worst possible moments.

The vibe coding era is young enough that we haven't seen the full lifecycle play out for most vibe-coded production systems. The startups that shipped in 2024-2025 using aggressive AI workflows are entering their adolescence. The security incidents, the maintenance crises, the "we need to rewrite the whole thing" moments — these are coming. The question is whether the industry extracts the right lessons when they arrive.

The Verdict

Vibe coding is a legitimate tool for specific contexts, a dangerous shortcut for others, and a genuine cultural shift in who gets to build software. Treating it as purely dangerous misses the real democratization happening. Treating it as the future of professional software engineering ignores the engineering consequences that are already accumulating in production systems worldwide.

The developers who will navigate this era successfully are those who can be deliberately vibe-y when that's appropriate — prototypes, scripts, demos — and deliberately rigorous when it isn't, without conflating the two. That judgment is, ironically, exactly the kind of thing AI can't teach you and can't do for you.

The skill isn't writing code anymore. The skill is knowing when your code needs to be understood.