What Is Vibe Coding? Definition, Risks, and QA Basics

Vibe coding is building software by describing what you want in natural language, letting an AI model write the code, and shipping the result without reading most of it. The term was coined by Andrej Karpathy in February 2025 to describe a workflow where you "fully give in to the vibes" — accepting diffs, pasting error messages back into the model, and judging the output by whether the app appears to work rather than by reviewing what it does. Vibe coding is fast and genuinely useful for prototypes. The risk is structural: when it ships, nobody on the team has read the code now running in production.

Collins Dictionary named "vibe coding" its word of the year for 2025, which tells you how quickly the practice went from one developer's description of a Saturday habit to a default way of building. Cursor, Claude Code, Bolt, Lovable, v0 and Replit Agent are all built around some version of the loop. What has not kept pace is the verification step on the other side of it.

Where did the term "vibe coding" come from?

Karpathy's original framing matters, because it is narrower than how the term is now used. He described it as a mode for "throwaway weekend projects" — code where the cost of being wrong is near zero, so skipping review is a rational trade. He was explicit that he barely touched the keyboard and did not always understand the diffs he accepted.

The term then detached from that caveat. Today "vibe coding" describes the same loop applied to client websites, SaaS MVPs, internal dashboards and payment flows — contexts where being wrong is expensive. The technique did not change. The stakes did.

What does vibe coding look like in practice?

The loop is consistent across tools:

1. Describe a feature in a prompt, in product language rather than technical spec.
2. Accept the generated diff without reading it closely, or at all.
3. Run the app and click through the path you had in mind.
4. If something breaks, paste the error back to the model and accept the next diff.
5. Repeat until the screen looks right, then ship.

The defining characteristic is not that AI wrote the code. It is that the review step is absent rather than lighter. In a conventional workflow, a human reads the change before it merges and a test suite checks it afterwards. Vibe coding removes the first gate, and most vibe-coded projects never had the second.

What kinds of bugs does vibe coding produce?

AI-generated code fails in patterns, not at random. Knowing the patterns is what lets you test a vibe-coded app efficiently instead of auditing every line:

• Happy-path bias. A model writes code that satisfies the example in your prompt. The paths you did not mention — empty lists, zero results, a failed network call, a very long string, a duplicate submit — are where behaviour is undefined.
• Authorization gaps at object level. The endpoint authenticates the user and then fetches the record by the ID in the URL, without checking that this user owns that record. The feature works perfectly in your own account, which is the only account you tested.
• Invented dependencies. Models sometimes import packages that do not exist. This is a documented failure mode, and it has a documented attack built on top of it: adversaries register the hallucinated names so the next install resolves to their code. Any package name you did not choose deliberately deserves a look.
• Divergent state after multi-file edits. When a model edits several files across a session, it can leave two places that both own the same piece of logic. Fixing the bug in one does not fix it in the other, and the second one surfaces weeks later.
• Keys in the client bundle. API credentials put into frontend code work in the browser, which is exactly why they look correct, and are readable by anyone who opens devtools.

None of these show up when you click the path you asked for. All of them show up when a real user does something slightly different.

Is vibe coding the same as using an AI coding assistant?

No, and conflating them is how teams talk past each other. The difference is who reads the diff.

Most working developers are doing the left column. Most non-technical founders shipping with Bolt or Lovable are doing the right column. The same tool supports both, so the label tells you about the process, not the product.

When is vibe coding safe to ship?

Match the verification effort to what breaking costs you:

The honest version of the rule: vibe coding is a prototyping technique. It becomes a production technique only once you add back a verification layer to replace the review you skipped.

How do you QA a vibe-coded app without reading every line?

If you cannot review the code — because there is too much of it, or because you do not read that language — you verify at the level of behaviour instead. Three layers cover most of it:

1. Capture defects with enough evidence to fix them

When something is wrong, the bottleneck is usually the report, not the fix. A screenshot with no URL, console log or browser version turns into a round of questions. Snap captures the page state, console errors and network activity with the report so the ticket arrives reproducible.

2. Have something explore the paths you didn't think of

Your own clicking is biased toward the flows you built. Sims runs AI personas through the app with different goals and behaviours — the impatient user, the one with an empty account, the one who submits twice — which is where happy-path bias surfaces.

3. Lock the fixed behaviour down

Vibe-coded projects regress easily, because each new prompt can rewrite code the last one depended on. AutoSim turns verified flows into end-to-end tests that repair their own selectors when the UI shifts, so a working feature stays working through the next round of generation.

For the step-by-step version of this, see how to QA a vibe-coded app and the vibe coding QA checklist. For the broader category, start with the complete guide to AI QA.

What should you take away about vibe coding?

Vibe coding is a real and legitimate way to build. It removes the slowest part of software development for people who were previously blocked entirely, and it produces working software. What it does not do is produce verified software, and the gap between those two is where client escalations and 2am incidents live. Treat the generated code as a draft from a fast contributor who never tests edge cases, and put a verification layer where the code review used to be.