Who Coined Vibe Coding — Andrej Karpathy's Original Definition
The Term Everyone Uses and Almost Nobody Defines Correctly
Vibe coding is everywhere. Developers use it to describe building with AI assistants. Founders use it to pitch no-code products. Critics use it to dismiss AI-generated software as unserious. The term has been stretched so far from its origin that most people using it do not know what it originally meant — or who said it first.
Andrej Karpathy coined vibe coding in February 2025 in a post on X. The definition he gave was specific, intentional, and more nuanced than the way the industry adopted it. Understanding the original definition matters — not for trivia, but because the gap between what Karpathy meant and what the term became tells you something important about how the industry processes new ideas.
🎯 Quick Answer (30-Second Read)
- Who coined it: Andrej Karpathy, former Director of AI at Tesla and founding member of OpenAI
- When: February 2025, in a post on X (formerly Twitter)
- Original definition: A mode of programming where you fully give in to the AI, describe what you want in natural language, accept the output without deeply reading it, and essentially stop thinking of yourself as the programmer
- Key nuance: Karpathy framed it as a legitimate and enjoyable mode for certain tasks — not a replacement for engineering judgment
- What the industry got wrong: Treating vibe coding as a methodology for production software rather than a specific, intentional mode for low-stakes exploration
Karpathy's Original Definition
On February 6, 2025, Andrej Karpathy posted on X:
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponential technologies, and forget that the code even exists. You just see what you want, say what you want, and it happens.
He described the specific workflow: using voice input to describe what he wanted, letting the model generate the code, running it immediately, and feeding errors back to the model without reading the stack trace himself. The human in the loop was directing intent — not writing, reading, or debugging code in the traditional sense.
Karpathy was explicit about the context: side projects, throwaway code, and personal tools where correctness and maintainability were not the primary constraints. He described building a small iOS app this way and noted that it mostly worked. He also noted that he sometimes did not know exactly what was in the codebase — and that for this specific use case, that was fine.
What Made the Definition Precise
Three elements of Karpathy's original framing were specific and deliberate:
Full surrender to the AI. Not AI-assisted coding where you read and edit the output — full delegation. The developer describes outcomes, the model produces code, and the developer evaluates results, not implementation.
Intentional scope. Karpathy was describing personal projects and exploration. He was not prescribing this for production systems, teams, or anything with users depending on it.
Acknowledged trade-offs. He noted that bugs exist in the code that he would not catch because he was not reading it. He accepted this trade-off knowingly, for the use cases where it made sense.
The definition was not "use AI to code faster." It was "adopt a fundamentally different relationship with code — one where you stop being the programmer and become the director."
How the Industry Misread It
The term spread faster than the nuance. Within weeks, vibe coding was being used to describe:
- Any use of Cursor or GitHub Copilot
- Non-technical founders building MVPs with AI tools
- AI-assisted development of any kind
- A philosophy for shipping production software quickly
None of these are what Karpathy described. Using an AI coding assistant while still reading, understanding, and modifying the output is not vibe coding — it is AI-assisted development. Building a production SaaS with Cursor and carefully reviewing every generated function is the opposite of vibe coding by Karpathy's definition.
The industry collapsed a precise term into a broad category. Vibe coding became a synonym for "building with AI" — which erased the specific and interesting thing Karpathy was pointing at: the psychological and operational shift that happens when you fully stop engaging with the code as a programmer.
The Right Way to Understand It vs The Wrong Way
The right understanding treats vibe coding as a mode, not a methodology. Karpathy was describing something more like a creative exploration state — the equivalent of sketching instead of drafting. You use it when the goal is to see if something is possible, to build a personal tool quickly, or to explore a problem space without committing to a codebase. The output is disposable or revisable. You are optimising for speed of exploration, not quality of output.
The wrong understanding is treating it as a production development philosophy. Code that nobody reads accumulates bugs that nobody catches. In a personal project with no users, that is acceptable. In a product with paying customers, it is a liability that compounds. The developers who shipped "vibe coded" production systems in 2025 and called the results unacceptable were not disproving Karpathy's concept — they were misapplying it.
The distinction matters because it determines how you evaluate AI coding tools. Judged as vibe coding tools for exploration, they are remarkably capable. Judged as replacements for engineering judgment on production systems, they fall short in predictable ways.
My Take
The reason vibe coding struck a nerve is that Karpathy named something developers were already doing but had no precise language for — the experience of fully delegating implementation to a model and evaluating outputs rather than writing them. The best outcome of that framing is a generation of developers who consciously switch between modes: deep engineering for production systems, vibe coding for exploration and prototyping, with clear awareness of which mode they are in and why. The worst outcome — which is largely what happened — is the term becoming a permission slip to not understand what is running in production, applied indiscriminately across contexts where that trade-off is genuinely dangerous. Right now, the industry is working through the consequences of that misapplication: security vulnerabilities in AI-generated code that nobody reviewed, architectural decisions baked into codebases by models that had no product context, and debugging sessions where nobody on the team understands the code they are maintaining. Where this is heading: the next precise term will not be about how you interact with the AI — it will be about how you verify what it produces. Vibe coding needed a companion concept for vibe auditing, and that framing is overdue.
Real Developer Use Case
A developer building a personal finance dashboard in January 2025 used voice input to describe every feature to Claude, accepted the generated code without reading it, and had a working local app in four hours. No tests, no code review, no understanding of the state management. The app worked for his use case. He used it for six months, never touched the code again, and threw it away when his needs changed.
That is vibe coding as Karpathy defined it. The same developer, six months later, tried the same approach on a client project with real users. Two weeks in, a bug in the payment flow was causing silent failures. Nobody on the team could debug it because nobody had read the code that generated it. They rewrote the payment module from scratch.
Same tool, same approach, different context — completely different outcome. The definition was always context-specific. The industry removed that specificity and paid for it.
Frequently Asked Questions
Did Andrej Karpathy invent vibe coding?
Karpathy coined the term in February 2025. The practice of fully delegating code generation to an AI model and evaluating outputs rather than writing code existed before the term — but he named it, defined it precisely, and gave the industry a shared vocabulary for a specific mode of working with AI.
Is vibe coding a real software development methodology?
Not in the traditional sense. Karpathy framed it as a mode for personal projects and exploration — not a methodology for production software. It becomes a problem when applied to systems with real users, compliance requirements, or the need for maintainability. As a personal productivity approach for low-stakes projects, it is legitimate and effective.
What tools are used for vibe coding?
Any AI coding assistant supports the vibe coding mode: Cursor, GitHub Copilot, Claude, and voice-to-code tools. Karpathy specifically mentioned using voice input with an AI model. The tool matters less than the mode — vibe coding is defined by the human's relationship to the output (director, not programmer), not by which AI is generating the code.
Why did vibe coding become controversial?
Because the term spread faster than its precise definition. Developers applying vibe coding to production systems encountered the predictable consequences of not reading or understanding generated code — security issues, architectural debt, unmaintainable codebases. The controversy was largely a product of misapplication, not a refutation of what Karpathy originally described.
What is the difference between vibe coding and AI-assisted development?
AI-assisted development means using an AI tool while still reading, understanding, and taking responsibility for the output. Vibe coding, by Karpathy's definition, means fully surrendering implementation to the AI — not reading the code, not deeply understanding it, and accepting the trade-offs that come with that. The distinction is the developer's level of engagement with the generated output.
Conclusion
Andrej Karpathy coined vibe coding in February 2025 to describe a specific mode of working with AI: full delegation of implementation, evaluation of outputs rather than code, and intentional acceptance of the trade-offs that come with not reading what the model generates. He applied it to personal projects and exploration — not production software.
The industry adopted the term and stripped it of that precision. Understanding the original definition does not just settle a trivia question — it clarifies what AI coding tools are actually good at, what they are not, and why context determines whether the approach produces a useful prototype or an unmaintainable production system.
Related reads: How AI Coding Agents Write and Debug Code Autonomously · Best AI Coding Tools for Developers 2026 · How Developers Use AI to Build Apps Faster