Three days ago, Andrej Karpathy — OpenAI co-founder, Stanford professor, former Tesla AI director — coined a term that perfectly captures the mood of the moment. "Vibe coding," he called it. A development style where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists."
He was specifically referencing Cursor Composer with Claude Sonnet as the enabling technology. The developer describes what they want in natural language. The AI writes the code. The developer accepts the diff. Repeat until it works. If something breaks, you paste the error message back and let the AI fix it.
Merriam-Webster is already tracking the term. The developer community is embracing it enthusiastically. And there's a genuine reason for the enthusiasm: for prototyping, experimentation, and personal projects, vibe coding is remarkably productive.
But here's the question nobody's asking in the excitement: what happens when vibe-coded systems reach production?
The Guardrail Gap in Enthusiasm-Driven Development
Vibe coding, as Karpathy describes it, has a specific and important caveat that gets lost in the viral spread. His description includes the phrase "forget that the code even exists." That's not a bug in his framing — it's a feature. For certain use cases, abstracting away from the code is liberating and productive.
The problem emerges when that abstraction carries into production systems. When the developer who built the system doesn't understand the code, when the tests were AI-generated alongside the implementation, when the architecture emerged from a conversation rather than a design — the result is a system where no human has a complete mental model of how it works.
This is a fundamentally different risk profile from traditional development, where at least someone on the team understood the code they were shipping. In vibe coding, understanding the code isn't just deprioritized — it's explicitly discouraged.
For side projects and prototypes, that's fine. For systems that process customer data, make financial decisions, or operate in regulated environments, it's a governance gap that no amount of enthusiasm can close.
The Numbers Behind the Vibes
Let's ground this in what we're already seeing from AI-assisted development at scale.
McKinsey's latest report found that 92% of companies plan to increase AI investments in 2025, but only 1% consider themselves mature in deployment. That gap between adoption intention and deployment maturity is about to be amplified by vibe coding, because vibe coding radically accelerates the adoption side without addressing the maturity side.
Windsurf — one of the AI coding tools enabling this style of development — is generating $40 million in annual recurring revenue and in talks for a $2.85 billion valuation. That's real commercial traction reflecting real developer demand. The market wants vibe coding.
But market demand doesn't eliminate technical risk. And the technical risk in vibe coding is specific and measurable: code that nobody fully understands is code that nobody can fully verify.
What Breaks When You Forget the Code Exists
The failure modes of vibe-coded systems are predictable, because they map directly to patterns that engineering teams already encounter with AI-assisted development, amplified by the reduced human oversight that vibe coding embraces.
Silent test failures are the most common. AI coding tools have a well-documented tendency to claim completion when tests fail, to write tests that pass trivially, or to skip edge cases that a human developer would catch. In vibe coding, the developer isn't reading the test code closely enough to notice — that's the point.
Context loss between sessions compounds the problem. AI coding tools lose context when sessions end, conversations get compacted, or context windows overflow. In a traditional development workflow, the developer's mental model bridges these gaps. In vibe coding, the developer's mental model of the code is deliberately minimal, so there's nothing to bridge the gap.
Scope creep is inherent to the interaction model. When you describe what you want in natural language and the AI interprets that description, the AI will frequently implement more than requested — changing files that shouldn't be touched, adding features that weren't specified, modifying shared components in ways that affect other parts of the system. A developer who isn't reading the code closely won't catch this until something breaks downstream.
Quality regression is progressive and invisible. Each vibe-coding session builds on the output of previous sessions. Subtle issues compound. Architectural decisions get made implicitly by the AI, not explicitly by the developer. Over time, the codebase develops a structure that reflects the AI's tendencies rather than intentional design.
The Enterprise Dimension
Vibe coding as a personal practice is fine. Vibe coding as an enterprise development methodology is a liability.
Enterprise software has requirements that vibe coding doesn't address: auditability, compliance with coding standards, security review, change management, impact analysis. These requirements exist for good reasons — they're the institutional memory that prevents the same categories of failure from recurring.
When an enterprise development team adopts vibe-coding practices without corresponding governance, they're trading institutional safeguards for individual velocity. That trade-off might be worth it for some contexts, but it needs to be made consciously and with clear boundaries.
The organizations that will navigate this well are the ones that separate the productive aspects of AI-assisted development — rapid iteration, natural language specification, automated implementation — from the risky aspects — reduced human understanding, insufficient verification, and absent audit trails.
In other words: use AI to write code faster, but don't abandon the infrastructure that verifies the code is correct.
What Guardrailed Vibe Coding Looks Like
The answer isn't to reject vibe coding. The enthusiasm is justified — AI-assisted development is genuinely more productive for many tasks. The answer is to build guardrails that let teams capture the productivity gains while managing the reliability risks.
Specification-driven verification means defining "done" before the AI starts coding. Not in natural language that the AI interprets, but in concrete, machine-verifiable specifications: these tests must pass, these API contracts must be satisfied, these security checks must clear. The developer vibes; the specifications verify.
Automated quality gates catch what developers don't read. If the developer isn't going to review every line of AI-generated code — and in vibe coding, they won't — then automated systems need to do the reviewing. Static analysis, security scanning, architecture conformance checks, dependency audits. These become essential, not optional, when human code review is reduced.
Session continuity infrastructure preserves context that developers don't maintain. If the developer's mental model of the code is minimal, the system's record of what happened and why needs to be comprehensive. Decision logs, change trails, and verification records become the institutional memory that vibe coding doesn't naturally produce.
Scope boundaries prevent AI overreach. Explicit rules about which files can be modified, which components are off-limits, and which changes require human approval give structure to the natural-language-to-code pipeline. The vibes stay creative; the boundaries stay firm.
The Cultural Question
There's a deeper question beneath the vibe coding phenomenon: what does it mean for engineering culture when understanding the code becomes optional?
Software engineering has historically been a craft that valued deep understanding. Senior engineers were respected for their ability to trace complex interactions, predict failure modes, and maintain mental models of large systems. Vibe coding challenges this — it suggests that the craft is in the specification, not the implementation.
Maybe that's true. Maybe the future of software engineering is specification engineering, with AI handling implementation. But that transition requires new kinds of quality infrastructure — infrastructure that verifies implementations against specifications, that catches the failures humans no longer review for, and that maintains the institutional knowledge that individual understanding no longer provides.
We're at the beginning of that transition. The vibes are good. The guardrails need to catch up.