Vibe Coding. The Paradigm Where You Describe Software Instead of Writing It

Vibe coding is the practice of describing a software project in natural language and letting an AI system, usually a large language model connected to a code editor or agent, generate and run the code, with the human reviewing outcomes and steering by conversation rather than typing every line. Computer scientist Andrej Karpathy coined the term on February 2, 2025, in a post on X, writing that he "fully gives in to the vibes, embraces exponentials, and forgets that the code even exists." Collins Dictionary named vibe coding its 2025 Word of the Year, and the term has since become the root of a broader "vibe" family (vibe creating, vibe marketing, vibe scripting, vibe design) that extends the same describe-and-direct pattern beyond software into other creative and professional work.

The paradigm sits on a spectrum. At one end is what practitioners call full vibe coding, where a builder accepts AI output with light or no code review, judging success by whether the app works rather than by reading every function. At the other end is human-led vibe coding, where a developer treats the AI as a collaborator, actively reading, testing, and refining what it produces. Both ends share the same starting move: a plain-language description replaces a blank code editor as the entry point.

What Vibe Coding Actually Is

At its core, vibe coding is a conversation-first way of building software. A person states an intent ("build me a habit tracker with a streak counter and a calendar view"), a large language model translates that intent into working code, and the person tests the result, gives feedback, and asks for changes, repeating the loop until the software does what they wanted. The defining shift is that natural language becomes the primary interface to the computer, and traditional syntax becomes something the AI handles rather than something the human types.

Karpathy's original framing was closer to an extreme than a formal methodology. In his February 2025 post, he described using Cursor Composer (powered by Anthropic's Sonnet models) paired with the voice-transcription tool SuperWhisper, so that he was talking to the editor more than typing into it. That post reached over 4.5 million views and set off a debate that has not fully settled, whether vibe coding is a legitimate way to build production software, or a shortcut suited only to throwaway prototypes. Merriam-Webster listed "vibe coding" as a slang and trending term in March 2025, just weeks after the post. By November 2025, Collins Dictionary had named it Word of the Year, citing the way it captures a broader shift toward natural language as a control surface for machines.

It is worth separating vibe coding from AI-assisted coding more generally. Using autocomplete suggestions from an AI pair-programmer while still writing and reviewing most of your own code is a different practice, closer to traditional development with a faster typing hand. Vibe coding specifically describes handing the LLM the authorship of the code and evaluating by outcome (does the app run, does the feature work) rather than by reading the diff line by line.

How Vibe Coding Works

The workflow has a repeatable shape across tools, whether the interface is a chat window, a code editor with an embedded agent, or a browser-based app builder.

Describe. The builder states what they want in plain language, sometimes just a sentence, sometimes a longer brief with constraints (framework, data model, visual style). No knowledge of syntax is required to start.

Generate. The AI system writes the code, often across multiple files, and in agentic tools it can also run the code, read the resulting errors, and revise on its own before showing the human a working state.

Review and steer. The builder tests the output (clicking through the app, checking behavior, reading code where they choose to) and gives follow-up instructions in the same natural-language register, adjusting the direction rather than editing code directly.

Iterate. The loop repeats, each round narrowing the gap between the described intent and the working software, until the builder is satisfied or the project graduates to more traditional development practices for production hardening.

Vibe Coding vs Traditional Coding

The comparison table above captures the mechanics, but the deeper difference is philosophical. Traditional programming treats upfront planning, architecture decisions, and code review as the way risk gets managed before software ships. Vibe coding treats fast iteration and live testing as the way risk gets managed, deferring architecture decisions until the working prototype reveals what actually matters. Neither approach is universally correct. Traditional coding remains the standard for systems where a subtle bug is expensive (payment processing, medical software, safety-critical infrastructure), because the discipline of planning and review catches classes of errors that "does it run" testing does not. Vibe coding earns its place where speed to a working version matters more than architectural certainty on day one, such as prototypes, internal tools, hackathon projects, and increasingly, early versions of products that get hardened with traditional practices before they scale.

The two approaches are converging in practice more than the binary framing suggests. Professional developers increasingly vibe code a feature's first draft, then apply traditional review and testing discipline before it ships.

Where Vibe Coding Fits

Non-technical builders and founders. A person with no programming background can describe an app idea and get a working prototype without hiring a developer first, which is why vibe coding has become closely associated with solo founders validating an idea before committing engineering budget.

Professional developers. Experienced engineers use vibe coding to scaffold boilerplate, generate a first pass at a feature, or explore an unfamiliar framework quickly, then apply their own review and testing standards before the code ships to production.

Internal tools and prototypes. Teams that need a working dashboard, an internal script, or a quick proof of concept lean on vibe coding because the cost of a bug is low and the value of speed is high.

Learning environments. Some builders use vibe coding to learn programming concepts by studying working code generated from their own descriptions, though this remains debated among educators who worry it can substitute for understanding rather than build it.

Adoption data should be read carefully, since most numbers in circulation come from tool vendors or aggregators with a stake in the category looking large. With that caveat, one industry roundup reports 90% of developers regularly used at least one AI coding tool at work as of January 2026, up from 85% in mid-2025, and a related figure puts daily AI coding tool usage among US developers at 92%, though only a minority say they fully trust that code. The same sources report a majority of active vibe coding users, cited around 63%, are non-developers, consistent with the split between developer-facing code editors and app builders aimed at non-technical founders.

Tools That Enable Vibe Coding

No single tool defines vibe coding. The landscape splits roughly into AI-native code editors built for developers, and natural-language app builders aimed at people who may not write code at all, plus a newer category of autonomous coding agents that can plan and execute multi-step engineering work with less supervision.

A common working pattern is to combine tools rather than pick one, prototyping an idea quickly in a natural-language app builder, then moving the project into a developer-oriented editor once it needs production-grade structure, testing, and review.

Risks and Criticisms

Vibe coding's speed comes with a documented cost, and a page that defines the paradigm honestly should cover it rather than sell past it.

Security vulnerabilities. Multiple security research reports found AI-generated code contains more flaws than human-written code, one industry analysis cites roughly 2.74 times more security flaws, and a scan of 5,600 publicly deployed vibe-coded applications reportedly found more than 2,000 high-impact vulnerabilities and over 400 exposed secrets. The models are not careless by design, they optimize for code that runs and matches the stated intent, not for security review, and they can reproduce insecure patterns present in their training data.

Unreviewed dependencies. AI coding tools frequently pull in open-source packages automatically to satisfy a request. Without a human validating each addition, a project can inherit outdated, vulnerable, or unnecessary dependencies, a known way software supply chain risk expands.

Debugging debt. Fast generation does not always mean fast delivery. Some developers report spending more time debugging AI-generated code than they estimate they would have spent writing the original code themselves, especially once a vibe-coded prototype needs to scale past its first working version.

Reduced authorship and accountability. A subtler concern raised by security researchers is psychological. When code is "vibed" into existence rather than typed by the person responsible for it, that person can feel less ownership over the result, which can weaken the accountability that catches problems before they reach users.

None of this makes vibe coding unusable, it makes it a tool with an operating envelope. The pattern that recurs across postmortems and vendor guidance alike is to vibe code the first draft, then apply the same review, testing, and security discipline traditional software already requires before anything ships to real users.

Getting Started

A first vibe coding project does not require choosing the "right" tool from a long list. A few practical steps get most builders to a working prototype.

1. Pick one small, well-scoped idea rather than a full product. A single-page tool or small internal utility is easier to describe precisely than a sprawling app.
2. Write the description as if briefing a capable junior developer, naming the core feature, the rough visual style, and any hard constraints (a specific framework, a data source, an integration).
3. Generate a first version and test it by using it, not by reading the code line by line, unless you already know how to read code and want that layer of confidence.
4. Give follow-up instructions in the same conversational register ("make the button larger," "add a login step") rather than trying to hand-edit the generated code.
5. Before anything reaches real users, apply a review pass, even a lightweight one, for security-sensitive areas like authentication, payments, and data handling, exactly where AI-generated code has been shown to carry more risk.

Related Reading

• Vibe coding on Wikipedia

Resources