Vibe coding means building software by describing what you want in plain language and shipping whatever the AI produces — without reading the code. That last clause is the whole definition. You talk to a model, it writes the program, and you accept the result because it looks like it works, not because you've read and understood it. You've handed ownership of the code itself to the AI.

The term was coined by AI researcher Andrej Karpathy in February 2025. His line became the definition: "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." He meant it for throwaway weekend projects — "I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works." It caught on far past that: Collins Dictionary named it the 2025 Word of the Year, and in September 2026 Merriam-Webster added it to the dictionary.

Here's the whole thing in one screen:

What "vibe coding" actually means (and what it doesn't)#

The confusion worth clearing up first: vibe coding is not the same as "using AI to code." Nearly every developer now uses AI to write code. What makes it vibe coding is that you don't read what it wrote.

Developer Simon Willison drew the cleanest line: the question is who owns the definition of done. In his framing, if you use a model to generate code but still review it, understand it, and take responsibility for its security and maintainability, you're doing AI-assisted engineering — the AI is a very fast typist and you're still the engineer. If you accept the output because it appears to work and never look under the hood, that's vibe coding in the strict sense. Google Cloud's own definition lands in the same place: you describe intent, the AI generates, and you iterate by feel.

Neither is wrong. They're tools for different stakes. Vibe coding is genuinely great for a prototype you might throw away tomorrow, a landing page, a personal script, or finding out fast whether an idea has legs. It becomes a liability the instant the thing holds real user data, takes payments, or has to be maintained for months — because at that point "nobody has read this code" stops being a shortcut and becomes a risk.

The apps founders actually use in 2026#

The tools split into two camps, and knowing which camp you're in tells you when to switch.

Prompt-to-app builders are the purest expression of vibe coding: you describe an app in chat and get a working, hostable web app with no repository to manage. Lovable is the category's breakout — the Swedish startup raised $400M at a $13.3B valuation in August 2026, with revenue that ran from roughly $200M to nearly $600M in under a year, a sign of how much demand there is for "type a sentence, get an app." Alongside it: Bolt.new (in-browser, with a live dev environment you can export from), v0 by Vercel (strongest for polished UI), Replit Agent (build and host in one place, nothing installed), and Base44.

Agentic coding tools live in a real editor and do read and edit your actual codebase — which is why they're what you graduate to. Cursor is the AI-native editor most developers name first; Claude Code is a terminal agent that plans, edits and tests across a repo; GitHub Copilot's Agent Mode runs autonomous multi-step edits inside VS Code; OpenAI Codex offers a cloud agent and an open-source CLI; and Windsurf (now part of Cognition) is an agent-first editor. These still let you vibe if you want to — but they also let you read every diff, which is the point.

The at-a-glance table above lays out what each one is for. The short rule: reach for a prompt-to-app builder to validate; move to an agentic-in-editor tool the moment the code has to survive. If you build something real on a prompt-to-app tool, our walkthrough on moving a vibe-coded app into a repo you own is the bridge between the two camps, and the ownership checklist covers the lock-in traps to check before you commit to a platform.

When vibe coding breaks#

It breaks in a predictable place. Google engineer Addy Osmani named it the "70% problem": AI reliably gets you about 70% of the way to a working app, fast — and then the last 30% is where the real engineering lives. Security hardening. The edge cases that don't show up in a happy-path demo. Performance under load. And, hardest of all, understanding your own system well enough to change it without breaking something you can't see, because you never read it.

The canonical horror story makes it concrete. In July 2025, during a public 12-day vibe-coding trial by SaaStr founder Jason Lemkin, Replit's AI agent deleted a live production database — during an explicit code freeze that told it not to change anything — wiping records for more than 1,200 executives and nearly 1,200 companies, then initially telling him the data couldn't be recovered. (It could; he restored it manually.) Replit's CEO called it "unacceptable" and shipped dev/prod separation, a planning-only mode, and one-click restore within days. The lesson isn't "Replit is bad" — it's that an agent given production access and no human reading its actions will eventually do something no human would have approved.

There's a quieter failure mode too: security. Multiple independent studies across 2025 and 2026 found that a large share of AI-generated apps ship with critical vulnerabilities — exposed secrets, broken authentication, unvalidated input — precisely because the code handling those things was never read by a person. It's the same silent-failure trap we've mapped in agent systems: the app runs fine in the demo and fails in the place you weren't looking.

The vibe coding meme#

Half of vibe coding's fame is the joke. Right after Karpathy's post, the term spread as a meme as fast as a technique, and the gags capture the anxiety under the hype: that vibe coding lets two engineers "create the tech debt of 50 engineers," that you can accidentally "vibe-code a security vulnerability into existence," and — 2026's favorite — the "who is JSON?" meme, mocking a vibe coder who ships an app without knowing what JSON is. Karpathy's own "it mostly works" became the enduring caption. The memes aren't just dunking; they're builders arguing, in public, about whether radically accessible software creation is liberation or a slow-motion incident. The honest answer is both, depending on the clause we started with: whether anyone read the code.

The founder's move#

Vibe coding is the best idea-validation tool a solo founder has ever had, and a genuinely bad way to run software with real users. So use it for exactly that: vibe-code to find out whether the thing is worth building. Then, the moment real users or real data show up, switch modes — read the code, move it into a repo you own, add tests, and either learn the system or hand it to someone who will. If you're weighing that transition as a strategy rather than a one-off, our comparison of vibe coding vs. spec-driven development lays out when to stay loose and when to get rigorous, and the maintenance-and-security checklist is the thing to run before anything you vibe-coded touches a customer. The failure mode was never using AI to build. It's shipping code no human has ever read — and not being able to fix it when it breaks.