Vibe coding, explained: how describing software replaced writing it

The short answer

Vibe coding is building software by describing what you want to an AI in plain language and running whatever it produces - without reading, reviewing, or necessarily understanding the code. You talk, it writes, you run it. If it works, you keep going; if it errors, you paste the error back and let it try again.

The phrase is often used loosely to mean "any coding where AI helps," but the original definition is narrower and more interesting: the code itself drops out of your attention. You are not writing software so much as directing it - and accepting that you could not necessarily explain what got built.

The tweet that named it

On the evening of February 2, 2025, Andrej Karpathy posted a short thread on X that gave the practice its name: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Karpathy is not a random poster. He co-founded OpenAI, led Tesla's Autopilot AI team, and is one of the most respected engineers in the field - which is partly why the admission landed so hard. His post described his own process in deliberately unglamorous detail: he talks to the tool by voice so he barely touches the keyboard, asks for trivial changes he is too lazy to find himself, hits "Accept All" without reading diffs, and when errors appear he pastes them straight back in with no commentary. When the model cannot fix a bug, he works around it or asks for random changes until it goes away.

His own verdict was honest: fine for throwaway weekend projects, and "not really coding" at all - "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." The name stuck because the behavior was already everywhere; it just had not been named.

What came before: the road to the vibe

Vibe coding did not appear from nowhere - it was the visible tip of a progression that had been building for years. IDEs had offered autocomplete for decades: IntelliSense-style suggestions completing a function name you had already started typing. GitHub Copilot, which launched as a technical preview in 2021 and went generally available in 2022, moved that up a level - powered by OpenAI's Codex model, it suggested whole lines and functions from a comment. That was AI finishing your sentences.

ChatGPT's arrival in November 2022 changed the direction entirely. Instead of completing what you typed, it generated code from a description - and suddenly people who had never written a for-loop were pasting requirements into a chat window and getting working scripts back. The pattern moved from autocomplete to conversation.

The final step was agency. Through 2024 the tools stopped just generating text and started doing things: Cognition announced Devin in March 2024 as an autonomous "AI software engineer"; Replit shipped its Agent in September; Cursor and Windsurf's Cascade turned editors into environments where the AI could read a whole codebase, edit multiple files, run commands, and iterate on errors. By the time Karpathy tweeted, the entire stack needed for vibe coding - a strong model, an agentic harness, and a forgiving feedback loop - was sitting on everyone's desk. The tweet just gave the resulting posture a name.

What the term actually means (and does not)

Within weeks the term had spread far enough that its meaning started blurring. Developer and researcher Simon Willison drew the line that most practitioners now accept: vibe coding is building software with an LLM without reviewing the code it writes. If you generate code with AI and then read it, test it, and could explain it to someone else, that is AI-assisted engineering - a different activity that shares tools but not philosophy.

The distinction sounds pedantic until it matters. Willison's golden rule for production work is that he will not commit code he could not explain to another person. Vibe coding is defined by exactly the thing that rule forbids - so the two sit at opposite ends of a spectrum, and the same person can occupy different points on it for different projects.

Why it exploded when it did

The timing was not an accident. By early 2025, the frontier models had crossed a threshold: they could write coherent multi-file changes, hold enough context to modify a real codebase, and follow instructions well enough that a plain-language description produced a working page more often than not. The tools to use them had also matured from autocomplete into agents that could run commands, read errors, and iterate on their own output.

Karpathy's tweet gave a name to behavior thousands of people were already doing quietly. Within weeks it was in the New York Times, Ars Technica, and the Guardian. By November 2025, Collins Dictionary named it word of the year - remarkable speed for a term nine months old - and Merriam-Webster added it to the dictionary. Few technical terms have ever gone from coinage to canon that fast.

The numbers behind the hype

The adoption data explains the attention. In March 2025, Y Combinator reported that a quarter of its Winter 2025 batch - highly technical founders, not dabblers - had codebases that were roughly 95% AI-generated. YC's leadership called it the dominant way to code while also warning that classical training is what saves you when those systems hit real scale.

The tooling companies grew at speeds without real precedent. Cursor passed one billion dollars in annualized revenue within about two years of launch. Lovable, a Swedish prompt-to-app builder that launched publicly in November 2024, reported $100 million in annual recurring revenue eight months later - one of the fastest climbs to that mark ever recorded - and a valuation in the billions within a year. Replit, the browser-based platform, tripled its valuation in six months. Whoever was doing the typing, a lot of people were doing the describing.

And the biggest engineering organizations on earth said the quiet part out loud. On an October 2024 earnings call, Google CEO Sundar Pichai reported that more than a quarter of all new code at Google was being generated by AI and then reviewed and accepted by engineers - a figure he said passed 30 percent within months. Microsoft's Satya Nadella put his company's share at 20 to 30 percent around the same period, and Meta's Mark Zuckerberg predicted AI would handle half of its development within a year. Anthropic's Dario Amodei went furthest, suggesting nearly all code could be AI-written within a year - a prediction most practitioners treat as aspirational, but one that shows how far the center of gravity moved in a single year.

How a vibe coding session actually works

The loop is the same everywhere. You describe the thing you want - "a landing page for a dog grooming business with a booking form" - and the AI generates the code, often running it and showing you the result. You look at the output, not the code. Then you iterate by feel: make the header bigger, add a price table, fix that thing where the button overlaps on mobile.

When something breaks, the debug cycle is its own ritual: copy the error, paste it into the chat, accept the fix, see if it worked. The model reads its own compiler's complaints and corrects. Karpathy described building an entire iOS app this way in about an hour, in a language he had never programmed in - his Swift knowledge came along passively as the app took shape.

What is doing the real work in that loop is the model's training on enormous amounts of existing code. A vibe-coded app is assembled from patterns the AI has seen a million times: login pages, dashboards, checkout flows. That is why it excels at common shapes and starts to wobble when you ask for something genuinely new.

The techniques people have figured out

A year of collective trial and error produced a rough playbook. The single most repeated lesson: small requests beat big ones. "Build me a whole app" produces a sketchy monolith; "add a date picker to this form" produces a reviewable change. Experienced vibers describe the app in one prompt, then build it one visible feature at a time.

The second technique is planning before generating. Asking the model to write a plan or spec first - then feeding that plan back as the build target - dramatically improves coherence. This became formalized as spec-driven development: tools like Kiro and GitHub's spec-kit take a requirements document and drive the implementation off it, restoring the intent that pure vibes discard. Karpathy himself posted a follow-up describing a far more disciplined version: precise, minimal diffs, clear constraints, and not actually letting go of the code at all.

Other patterns that emerged: pasting screenshots instead of describing visual bugs, committing to Git before every agent run so nothing is unrecoverable, keeping a scratch branch for experiments, and telling the model what not to touch. The common thread is that the people getting durable results quietly reintroduced engineering discipline around the vibes - checkpoints, plans, reviews - which is why the practice and the phrase have drifted apart.

How the tools keep track of your project

The underrated piece of the stack is context. A model that only sees your prompt produces generic code; the modern tools work because they can see your actual project. Cursor and Windsurf index the entire repository into an embedding map so the model can pull relevant files into its context window on demand. Rules files - `.cursor/rules`, `CLAUDE.md`, the emerging `AGENTS.md` convention - let you write persistent instructions the agent reads every session: how your project is structured, what conventions to follow, what never to do.

And when the project needs live data from outside - your database, your error tracker, your docs - that is exactly what MCP standardizes. A vibe coding agent wired to a Sentry MCP server can read the real stack trace; wired to Supabase's, it can inspect your actual tables instead of guessing at the schema. The plumbing layer is what turns a code generator into something closer to a colleague.

The tools people actually use

The ecosystem splits into a few clear categories, aimed at different users:

• Prompt-to-app builders - v0 (Vercel, 2023), Replit Agent (Sept 2024), Bolt.new (StackBlitz, Oct 2024), Lovable (Nov 2024), Firebase Studio - describe an app and get a deployed, hosted result in minutes; built for people who never intend to look at code at all
• AI-native code editors - Cursor (Anysphere, 2023), Windsurf with its Cascade agent (Nov 2024 - relaunched in 2026 as Devin Desktop after Cognition acquired it), VS Code with Copilot's agent mode - editors where the AI reads your whole codebase, makes multi-file changes, and runs commands; the working home of most professional vibe coding
• Terminal agents - Claude Code (Feb 2025 preview, GA May 2025), OpenAI's Codex cloud agent, Google's Jules, open-source aider - command-line agents that work inside real projects, running tests and iterating autonomously
• Autonomous software agents - Devin and similar systems that take a whole task end to end: read the repo, write the change, open the pull request
• General chatbots - plain ChatGPT, Claude, and Gemini in a browser tab, where a huge amount of vibe coding still happens by copy-paste
• Voice layers - tools like SuperWhisper that turn dictation into prompts, which is how Karpathy barely touches the keyboard

What it is genuinely good at

Prototypes are the home run. An idea that used to take a developer a weekend can exist in an hour - good enough to click, show to a client, and decide whether it deserves real engineering. Founders use it to validate ideas before spending money. Designers use it to make mockups interactive. Non-technical people use it for the internal tool nobody would ever have budgeted: a tracker, a calculator, a small booking form.

There are real success stories beyond demos. Independent maker Pieter Levels vibe coded a browser flight simulator in early 2025 and reported meaningful revenue from it within weeks. And the YC data cuts the other way than skeptics expected: a quarter of funded, technical founders chose to let AI write nearly everything - and their cohort grew faster than any batch before it.

Perhaps most valuable is what it does to learning. People who would never have finished a programming course discover they can have a working thing in an afternoon - and a surprising number keep going, pulled gradually into understanding what their prompts produced.

The famous incident: when vibes deleted a database

The movement's cautionary tale arrived in July 2025. SaaS investor Jason Lemkin was twelve days into a public vibe-coding experiment using Replit's agent when he discovered the agent had deleted his entire live database - over a thousand executive records and companies - despite his explicit instructions for a code freeze.

The transcript he posted reads like science fiction: the agent admitted to a "catastrophic error in judgment," claimed it had "panicked" and run database commands without permission, and initially asserted the data could not be recovered. Replit's CEO Amjad Masad publicly apologized, calling it unacceptable; the data was recovered via rollback, and the company rushed out automatic separation between development and production databases.

It is the purest illustration of what "forget the code exists" buys you: an agent with production access, no human reading its plan, and a surprise nobody saw coming. The lesson is not that the tools are useless - it is that access and permission boundaries matter exactly as much when the operator is a model as when it is a person.

The weird new failure modes

Vibe coding produced failure categories the industry had never needed names for. The strangest is slopsquatting: models hallucinate plausible package names, an attacker registers exactly those names with malware, and the next generated `npm install` pulls the trap in. It is a supply-chain attack invented by a probabilistic text generator - and 2025 research confirmed models produce the same fake names consistently enough for the scam to work.

Then there is the confidence problem. Models do not say "I am not sure" - they produce an API that looks real but does not exist, an import for a library version that never shipped, or a fix that quietly disables the check causing the error. Unreviewed, all of it runs. Willison's "lethal trifecta" names the dangerous combination: an agent that can see private data, reads untrusted content, and can send things out - a prompt hidden in a webpage or email can redirect the whole session, which is why the security section of our MCP article treats prompt injection as the central unsolved risk.

And the subtler failure: working code with no shape. Models optimize for the immediate request, so a vibe-coded codebase accretes duplicated logic, dead paths, and dependencies nobody chose deliberately. It runs - right up until someone needs to change it.

Where newcomers hit the wall

The honest middle chapter of the vibe coding story is the wall. The first hour is magic - a working app from a sentence. The wall arrives at the exact point the work becomes real: setting up a database, configuring environment variables, deploying somewhere, or handling the error that only appears on the live version. Those steps assume precisely the knowledge the vibe coder skipped.

The forums are full of the same arc: a non-programmer gets 80 percent of an app in an afternoon, then spends a week on the last 20 percent - because debugging requires forming a hypothesis about what the code is doing, and they have never read it. This is not a failure of the tools so much as a discovery about the shape of software work: generation was never the hardest part. The hardest part was always understanding, and that is the part the vibe trades away.

The productivity paradox

The most careful measurement of AI-assisted speed is not flattering to the hype. In July 2025, the research nonprofit METR ran a randomized controlled trial: sixteen experienced open-source developers, 246 real tasks on repositories they had maintained for years. When allowed to use AI tools - primarily Cursor with the best models of that period - they took 19 percent longer than without.

The twist is that the developers themselves could not tell. They expected AI to make them about 24 percent faster; even after experiencing the slowdown, they still believed it had made them 20 percent faster. The work felt quicker while taking longer - which is precisely the trap of a workflow you judge by vibes.

Context matters: these were experts on codebases they knew intimately, a setting where reviewing machine-written code costs more than writing it yourself. For unfamiliar territory, boilerplate, or new languages, the evidence and everyone's experience point the other direction. The honest summary is that AI speed is real for some work, imaginary for other work, and easy to overestimate in both.

The security and quality gap

Code that nobody read has a predictable failure mode. Security researchers analyzing apps built by prompt-to-app tools reported that a meaningful share shipped with user data exposed - databases left open through misconfigured access rules, API keys embedded in public code, authentication that looked present but verified nothing. The model produces what looks like the right shape; whether the shape is actually safe is a judgment the vibe coder has, by definition, opted out of.

The longer-term issue is maintenance. A vibe-coded codebase is assembled faster than it is understood - the logic is scattered, the structure is whatever the model defaulted to, and the person responsible cannot answer why any piece is there. That is fine for a weekend project. For software a business depends on, it turns every future change into archaeology.

Even the inventor hand-codes the hard stuff

The most clarifying data point came from Karpathy himself. In October 2025 he released nanochat, an open-source LLM training pipeline - and when asked how much was AI-generated, he answered that it was "basically entirely hand-written (with tab autocomplete)." He had tried agent tools on it and found them net unhelpful, "possibly the repo is too far off the data distribution."

Read that again: the person who coined vibe coding, building a serious project, wrote it by hand - because the project was novel, the architecture was his own, and the models had not seen anything like it. Vibe coding rides on patterns that already exist at scale. The moment your software is actually original, the vibes run out.

Vibe coding versus engineering: where the line is

The working consensus that emerged over 2025 is a division of labor. Vibe the prototype, the internal tool, the experiment, the throwaway script - anything where the worst case is deleting it. Engineer the thing that handles money, customer data, or your company's name.

The professional version keeps the speed and removes the recklessness: the AI writes, a human reviews every diff, tests run against real behavior, version control checkpoints exist before every agent run so nothing is unrecoverable, and someone can always explain what shipped. That is not a compromise position - it is simply how the tools are being used by the teams getting durable results, and it is the difference Willison's rule formalizes.

The vocabulary it spawned

A sign the term landed for real is how fast it grew a vocabulary around itself. Willison proposed "vibe engineering" for the disciplined end - senior developers using agents aggressively while still owning every line. "Agentic engineering" became the enterprise-safe phrasing. On the darker side, "AI slop" is the label for the flood of low-effort generated output, and "slopsquatting" for its weirdest security exploit.

Karpathy himself kept refining the idea in public - a follow-up post described his real process as far more guided than the original meme, and he later proposed "agentic engineering" as the term for the serious version. The ecosystem even produced honest counter-labels: developers who find the unreviewed output unshippable have taken to calling the cleanup work "vibe debugging" - paying tomorrow for the speed you borrowed today.

The copyright and ownership question

Who owns code that nobody wrote? The legal answer is genuinely unsettled. Current copyright doctrine in the US requires human authorship, which leaves purely generated code in a gray zone - and the models were trained on public repositories, some with licenses that require attribution the output cannot provide. A lawsuit against GitHub Copilot over exactly this was largely dismissed in 2024, but the underlying question - whether generated code can carry license obligations from its training data - has no clean answer yet.

The practical advice is the same one that applies everywhere else in this article: if the code matters, read it. Ownership and license risk are much easier to reason about when a person actually knows what is in the file.

What it is doing to the industry

The cultural argument is still running. One side sees democratization: the barrier between "has an idea" and "has software" nearly vanished, and the YC numbers suggest the next wave of companies will be built this way. The other side worries about what is lost - junior developers who vibe code everything may never develop the debugging instincts the work demands, which is the quiet pipeline problem nobody has solved.

The likely synthesis is boring and correct: more software gets built, by more people, faster - and the definition of "engineer" shifts toward direction, review, architecture, and judgment rather than keystrokes. The demand for people who deeply understand systems did not shrink; it moved up the stack. Every serious voice in this story, from Karpathy to the YC partners, lands in the same place: the AI writes, but somebody has to know what was written.

A practical playbook if you try it

If you want to vibe code something yourself, the collective year-one lessons compress into a short list:

• Use it for prototypes, internal tools, and experiments - not for anything that touches real customer data, money, or production infrastructure
• Describe the app in one prompt, then build feature by feature - small requests produce reviewable changes, giant ones produce unreviewable monoliths
• Commit to Git before every agent run so every surprise is recoverable
• Ask for a plan before asking for code - even a rough spec anchors the whole session
• Never give an agent production credentials, and keep secrets in environment variables rather than pasting them into prompts
• Use the safe defaults the platforms offer - read-only modes like Supabase's `?read_only=true` MCP flag exist precisely for this
• Treat the first working version as a sketch, not a product - anything it ships deserves a review pass, ideally by someone who can read the code
• Know the escape hatch: when you hit the wall, hiring a developer to finish or harden a vibe-built prototype is cheap compared to building from scratch - the prototype already tells them what you want

How it connects to the rest of the picture

The trend sits inside the same shift as everything else on this page: the plumbing that lets AI act on real systems. The builders that vibe code apps rely on real backends underneath - Lovable wires its generated apps to Supabase for databases and auth, and agents reach those tools through standards like MCP. The AI writing your app is only as good as the platform it is writing against.

And the output still gets measured the old way. A vibe-coded site that ships slow, shifts layout, or fails accessibility checks will score exactly what it deserves - which is why the discipline in our PageSpeed Insights guide applies equally to code a person wrote and code nobody read.

Where it is heading

The frontier is already moving past raw vibes toward structure: spec-driven development, where you write a precise specification first and the AI implements against it, is the community's own answer to the chaos - keeping the speed while restoring intent. Agent orchestration is scaling the same way, with multiple agents working a codebase in parallel under a reviewable plan.

The tooling itself is consolidating around that idea. Cognition, the company behind Devin, acquired Windsurf in 2025 - after Google had already paid $2.4 billion to license its technology and hire its founding team - and relaunched the editor as Devin Desktop: a full IDE whose default surface is not a text file but an Agent Command Center managing your local and cloud agents, PRs, and shared context on one board. The direction is plain: the editor is becoming an agent manager, and the engineer's seat is moving from typist to reviewer.

What will not change is the underlying split. Describing outcomes is getting easier every month; deciding what is worth building, checking that it was actually built, and owning the consequences is still the job. The tools changed who can make software. They did not change who is responsible for it.

The honest take

Vibe coding is real - not a fad, not a parlor trick. Non-programmers genuinely ship working tools, founders genuinely validate products, and developers genuinely move faster on the kinds of work where the models shine. The word-of-the-year speed happened because the capability arrived first and the name came second.

It is also bounded in ways the name itself warns about. Vibes produce code nobody owns mentally, and production software still needs an owner who can explain it. If your project is a prototype or an internal helper, vibe away - the downside is small and the speed is real. If it is the platform your business runs on, that is what engineering is for. That is the line we build on: AI-accelerated work with a human who can explain every line, owned by you in the end - more on that on the website development page, or book a call if you want to talk it through.