What Is Vibe Coding? The Term, the Practice, and the Catch
September 21, 2026
Vibe coding is describing what you want in plain language and letting an AI model write the code, without reading most of it. You stay in the loop by testing the result and asking for changes — not by reviewing the diff line by line.
The term came from Andrej Karpathy in February 2025, describing a mode where you "fully give in to the vibes" and "forget that the code even exists." It spread fast enough that Collins named it Word of the Year for 2025.
Three things are worth knowing before you try it:
- It genuinely works for throwaway tools, prototypes, and scripts nobody else has to maintain.
- It degrades badly on code that has to survive, because the failure mode is code you can't read when it breaks.
- The measured productivity gain is smaller than it feels, and in at least one controlled study it was negative.
Where the term actually came from
Karpathy's original framing was specific, and most later uses drop the important half. Karpathy was describing weekend projects — throwaway things where the cost of a bug is that you rewrite the file. The phrase wasn't a claim that this is how production software should be built.
That distinction got lost almost immediately. "Vibe coding" now gets applied to any AI-assisted development, including cases where someone is carefully reviewing every line. Those are different activities. Reviewing AI output is just using a tool. Vibe coding specifically means not reviewing it — accepting code you haven't read because the thing appears to work.
Keeping the two apart matters, because the risks only attach to one of them.
What it's genuinely good for
The honest case for vibe coding is strong in a narrow band:
| Use case | Why it works |
|---|---|
| One-off scripts | Renaming files, reshaping a CSV, scraping a page once. Nobody maintains it. |
| Prototypes and demos | You're testing whether an idea is worth building, not building it. |
| Learning a new library | Getting something running first, then reading how it works. |
| Internal tools with one user | You're the only person who suffers if it's weird. |
| Glue between two APIs | Small surface area, obvious when it fails. |
The common thread: low cost of failure and a short life. When a script breaks and you can just regenerate it, not reading the code costs you nothing. That's a real category, and it's bigger than most developers admit — a lot of useful software is disposable.
It also lowers the barrier for people who aren't developers at all. If you've got a clear problem and can describe it precisely, you can now get working code without learning a language first. That's a genuine change.
The catch: you can't debug what you never read
Here's the part the enthusiasm skips.
When vibe-coded software breaks — and it does — you're debugging a codebase you've never read, written in a style you didn't choose, with structural decisions you weren't party to. The AI that wrote it doesn't remember writing it. You're starting cold on unfamiliar code, which is the single slowest thing in software.
The research doesn't measure vibe coding directly — nobody has a dataset of code its authors never read — but it points the same way for AI-written code in general. GitClear's 2025 research, covering 211 million changed lines, found that the share of changed lines associated with refactoring fell from 25% in 2021 to under 10% in 2024, while copy-pasted lines rose from 8.3% to 12.3%, as AI assistants spread. That's a trend over the period, not proof AI caused it. CodeRabbit's December 2025 report compared 320 AI-co-authored pull requests with 150 human-only ones in open-source projects and found about 1.7 times as many issues per pull request in the AI-co-authored group. Security findings were elevated too, by up to 2.74 times for the worst category. That's a small sample, and those are code that was reviewed, not code nobody read, so treat the numbers as a direction rather than a measurement of vibe coding.
And the productivity story is stranger than expected. A July 2025 METR study ran a randomized trial with 16 experienced open-source developers working on their own large repositories, and found that with early-2025 AI tools they took 19% longer — while believing they'd been faster. METR is explicit that this is one setting and a snapshot in time, not a verdict on all developers, but the gap between the feeling of speed and the fact of it is worth remembering.
None of that makes vibe coding useless. It makes it a tool with a specific shape: fast at producing something that works now, expensive when that something has to keep working.
How to vibe code without regretting it
A few habits separate people who get value from this from people who end up with an unmaintainable mess:
Decide upfront whether the code is disposable. This is the whole decision. If the answer is "someone will maintain this," you're not vibe coding anymore — you're writing software with AI assistance, and you need to read the output.
Keep it small. A 200-line script you can regenerate is fine. A 12,000-line application you've never read is a liability, and it gets there one accepted suggestion at a time.
Test the behavior, not the code. If you're not reading the implementation, your tests are the only thing standing between you and a silent bug. Describe what the thing should do, then check that it does it.
Never vibe code anything touching credentials, payments, or personal data. The elevated security findings above are the reason, and they came from code that was reviewed. A bug in a file renamer is an annoyance; a bug in an auth flow is an incident.
Read the code when it breaks, not before. This is the pragmatic compromise. You don't need to review 2,000 lines that work. You do need to actually read the 40 lines that don't.
Vibe coding vs. the tools around it
The term gets tangled with several adjacent categories, and they're not the same thing:
| Approach | What you do | What you get |
|---|---|---|
| Vibe coding | Describe it, don't read the code | Working code you don't understand |
| AI-assisted coding | Describe it, review every diff | Code you understand, written faster |
| No-code platforms | Assemble from visual blocks | An app constrained by the platform |
| App generators | Prompt a full app into existence | A deployed app on someone's platform |
Tools like Replit and the app-generator category sit closest to vibe coding, and our comparison of Replit and Lovable covers how they differ in practice. Coding agents like Claude Code and Codex can be used either way — vibe coding or careful review — which is part of why the term has gotten so slippery. Our comparison of coding assistants covers what separates them.
The step most people actually get stuck at
There's a gap in the vibe-coding story that the demos skip. Generating code is now the easy part. Getting it running — dependencies, environment variables, API keys, a runtime that matches what the model assumed — is where non-developers still stall. You can produce a working script in ninety seconds and spend three hours failing to execute it.
That's the problem Taku is shaped around: instead of generating something from zero and then fighting the setup, you mirror an AI app or workflow someone already got working into your own desktop workspace and run it there. The free app library is the quickest way to see what that looks like. Taku is in Beta, and the Mac app is available now.
Key points
- Vibe coding means accepting AI-generated code without reading it — not just using AI to help you write code.
- Karpathy coined it in February 2025 for throwaway projects; the caveat got dropped as the term spread.
- It works well for disposable code: scripts, prototypes, internal tools, one-off glue.
- It degrades on anything long-lived, because debugging code you've never read is the slowest work in software.
- The evidence is sobering but indirect: studies of AI-written code in general found more issues and more duplication, and one small trial found experienced developers 19% slower on their own repositories while feeling faster.
- The decision that matters: is this code disposable? If not, read the output.
FAQ
Who invented the term vibe coding?
Andrej Karpathy, in February 2025. Karpathy was describing casual, throwaway projects where you let the model write the code and don't read it. Merriam-Webster picked it up as slang in March 2025 and Collins made it Word of the Year for 2025.
Is vibe coding the same as using AI to write code?
No, and the difference is the whole point. Using AI to write code you then review is ordinary tool use. Vibe coding means specifically not reviewing it. The risks belong to the second one.
Is vibe coding bad?
It's well-suited to disposable code and poorly suited to code that has to last. A script you'd rewrite rather than debug is a fine candidate. An application other people depend on isn't.
Can non-programmers vibe code?
Yes, and that's the genuine shift. The harder barrier now isn't writing the code — it's running it. Dependencies, environment setup, and API keys stop more non-developers than syntax ever did.
Does vibe coding actually make you faster?
Less than it feels, at least for experienced developers on code they know well. A July 2025 METR trial found 16 experienced open-source developers took 19% longer with early-2025 AI tools on their own repositories, while believing they'd sped up. METR frames it as one setting, not a general rule, and the result may differ for unfamiliar work or newer tools.
What shouldn't I vibe code?
Anything handling authentication, payments, or personal data. Studies of AI-co-authored code have found more security issues than in human-only code, even after review, and those are the areas where a defect becomes a real incident.