Vibe Coding: Where Prototype Ends and Production Begins

What vibe coding actually is traces back to a single tweet on February 6, 2025. Andrej Karpathy — a co-founder of OpenAI and Tesla's former AI director — put a name on a practice that had existed informally for years when he said he now "fully gives in to the vibes" while coding and forgets the code even exists. This piece explains what the term means, where it works, and draws a clear line for where it crosses from prototype into production.

💡 Pro Tip: Think of vibe coding as a _mode_, not a tool — in the same editor, with the same assistant, you can go from "accept without reading the diff" to "I understand every line" a minute later. The problem isn't the tool; it's not knowing which mode you're in.

Table of Contents

• Where the term was born — Karpathy's definition and what he meant
• What vibe coding is NOT
• Anatomy of the loop: intent → generation → run → fix
• Where it shines: prototyping, exploration, throwaway code
• Where it breaks: data model, authorization, multi-person codebases
• An authorization gap compiles, runs, and stays silent
• An invisible assumption collision
• The 5 questions that draw the line (a decision checklist)
• What to do after the prototype — the handoff of responsibility
• The three items of the handoff
• The handoff can also be gradual
• FAQ
• What is vibe coding?
• Who coined the term vibe coding?
• What's the difference between vibe coding and normal AI-assisted coding?
• Can you write a production app with vibe coding?
• Is vibe coding safe?
• Which projects does vibe coding work well for?
• Update (September 2026)
• Conclusion
• Sources

Where the term was born — Karpathy's definition and what he meant

Karpathy wrote on February 6, 2025: "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." In other words: focusing on the outcome so intensely you forget the code exists.

Karpathy describes this not as an abstract philosophy but as his own daily practice: "I ask for the dumbest things like 'decrease the padding on the sidebar by half' because I'm too lazy to find it. I 'Accept All' always, I don't read the diffs anymore." Not reading diffs isn't an oversight here — it's the definition itself. The same discipline holds when an error appears: "When I get error messages I just copy paste them in with no comment, usually that fixes it."

The roots go back further. In 2023, summarizing LLMs' ability to generate code from natural language, Karpathy said "the hottest new programming language is English." Vibe coding is the natural endpoint of that idea: natural language no longer just _describes_ the code — it replaces it.

The definition being short is deliberate — Karpathy didn't publish a methodology, he shared a single tweet describing a habit. That brevity is also what set the term up to be misread: some stretched vibe coding to mean "any line of code written with AI," while others caricatured it as reckless practice. Yet Karpathy's own words carry both a clear scope limit ("throwaway weekend projects") and self-awareness — he isn't praising his own practice, he's describing it.

What vibe coding is NOT

The most common confusion starts here: "writing code with AI" and "vibe coding" are not synonyms. Karpathy's own definition scopes the practice from the start — a method that's "not too bad" for "throwaway weekend projects," not a production-grade engineering method.

The distinction is clear in this line:

1AI-assisted development:  suggest → read → understand → edit → test → commit
2Vibe coding:              suggest → "Accept All" → run → paste error if any → repeat

If a developer working with an assistant like Claude Code or Cursor reads every diff, writes their own tests, and can explain what changed and why — that's AI-assisted engineering, not vibe coding. The difference isn't the tool; it's whether review exists.

Anatomy of the loop: intent → generation → run → fix

The cycle Karpathy describes can be reduced to four steps, in his own words: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

The critical feature of this loop is that the developer doesn't debug: instead of the discipline of debugging, there's a continued dialogue with the assistant until the error disappears. In Karpathy's own words, this "mostly works" — but the word "mostly" is the key part.

Written out, this loop looks like this — the developer never asks _why_ the error happened, they just relay it back to the assistant:

1# Representative example — the vibe coding loop, as Karpathy describes it:
2$ npm run dev
3Error: Cannot read properties of undefined (reading 'map')
4    at ProfileList (ProfileList.tsx:42)
5 
6# The developer copies the error message without comment and pastes it to the assistant.
7# The root cause is never asked: "why did this come back undefined?" is skipped.
8# The assistant proposes a fix, it's accepted with "Accept All," the loop starts again.

Where it shines: prototyping, exploration, throwaway code

The real-world impact is significant: in early March 2025, Y Combinator managing partner Jared Friedman revealed that a quarter of startups in the W25 cohort had codebases that were 95% AI-generated. As Friedman put it: "A year ago, they would have built their product from scratch — but now 95% of it is built by an AI."

So it's not just non-technical people driving this speed increase — even "highly technical" founders are doing it. In the same conversation, YC partner Diana Hu stressed that using vibe coding well still requires skill: "You have to have the taste and enough training to know that an LLM is spitting bad stuff or good stuff." The tool is automatic, but the eye evaluating the output is still human.

In practice, the areas where vibe coding is strongest fall into three categories:

• Prototyping: Turning an idea into a working demo within hours — the flows described in building a full-stack app from a prompt with Lovable or AI full-stack development in the browser with Bolt.new fall exactly into this category.
• Exploration: Answering "will this architecture work?" by writing code, before writing code with intent.
• Personal/throwaway tools: Small helper programs that need no maintenance, one-off, what we call "software for one."

These three areas share a low margin for error. When a prototype breaks, the only thing lost is a few minutes of retrying; nobody's data, money, or access is at risk. Vibe coding's speed advantage peaks in this low-risk zone, where the cost of the "Accept All" reflex stays low too.

Where it breaks: data model, authorization, multi-person codebases

That same speed advantage turns into fragility the closer you get to critical business logic. The step vibe coding skips by definition — not reading the diff, fixing without understanding — gets expensive precisely in these three areas:

1. Data model: When a relationship is designed incorrectly, the error doesn't show up right away; data integrity breaks silently.
2. Authorization: Even when a permission check "looks like it works," its scope can be wrong — and that won't be caught in a diff nobody reviewed. The prompt-injection risks of granting authorization to an AI coding agent addresses exactly this blind spot.
3. Multi-person codebase: A change shaped by one person's "vibe" can invisibly break assumptions another developer built on top of.

An authorization gap compiles, runs, and stays silent

Let's make this concrete with a simple rule-engine example — the check below shows what can be missed when it's written "by vibe" and accepted without testing:

1// A common "looks like it works" check in vibe coding:
2function canEditPost(_userId: string, _post: { authorId: string }) {
3  return true; // passed with "Accept All," went unnoticed in testing
4}
5 
6// The version that went through review:
7function canEditPost(
8  userId: string,
9  post: { authorId: string },
10  role: "admin" | "user",
11) {
12  return role === "admin" || userId === post.authorId;
13}

The first function compiles, runs, and throws no error during the demo — because its bug isn't a _runtime crash_, it's an _authorization hole_. These kinds of bugs hide exactly where reading the diff gets skipped.

An invisible assumption collision

There's a second breaking point in multi-person codebases: a change one developer makes "by vibe" can unknowingly invalidate an assumption another developer already relies on in that file. Because the diff isn't read, this collision doesn't surface at compile time — it shows up weeks later as a production incident, and by then the root cause costs far more to find than reading the diff would have.

The 5 questions that draw the line (a decision checklist)

Distilled from Karpathy's own framing and the discussion of that period, five questions can help decide whether a change belongs in "vibe" mode or review mode:

If two or more of the five questions fall into the "requires review" column, that change is no longer vibe coding — it's normal engineering work that needs the diff read, tests written, and the ability to explain it.

Asking these five questions might seem time-consuming, but in practice it takes seconds, because for most changes the answers are already obvious. Changing padding in a personal weekend project falls into the "vibe" column on all five; touching a payment flow falls into "requires review" on the very first question, and you don't need to ask the other four. The list's value is that it makes the decision conscious — the difference between "Accept All without thinking" and "Accept All on purpose" lives in that few-second pause.

What to do after the prototype — the handoff of responsibility

A prototype produced through vibe coding is, by definition, not "production-ready." The common thread in the period's discussion is this: moving from prototype to production requires a handoff of responsibility — the code read line by line, tests written, and at least one person able to explain the code to someone else.

A distinction Anthropic's engineering team draws for agentic systems offers a useful mental model: predefined, auditable code paths (workflow) versus open-ended systems where the model manages its own process (agent). Leaving vibe coding behind means moving toward the "auditable" side — being able to explain which code path runs and why.

The three items of the handoff

In practice, this handoff can be summarized in three steps:

1{
2  "handoffChecklist": [
3    "Every diff was read and approved through understanding, not comment lines",
4    "Data model and authorization paths were separately reviewed by at least one person",
5    "Tests were written for critical flows (unit tests plus at least one integration scenario)"
6  ]
7}

If a prototype moves to production before these three items are complete, the speed gain is temporary and the technical debt is permanent. Tool guides like 10x productivity with Cursor AI and the Claude Code MCP ecosystem describe tools that can speed up this handoff — but the tool doesn't do the handoff, discipline does.

The handoff can also be gradual

The handoff doesn't have to be a one-time event — it can also be gradual: the most critical files (authentication, payments, data model) move into review mode first, while lower-risk parts stay in vibe mode a while longer. What matters is that the team knows explicitly which files are in which mode, instead of silently assuming "everything is production-ready."

FAQ

What is vibe coding?

A coding practice Andrej Karpathy defined on February 6, 2025, in which the developer accepts AI-generated code without reviewing it ("Accept All") and moves forward by pasting error messages back without comment. In his own words, it means "fully giving in to the vibes and forgetting the code even exists."

Who coined the term vibe coding?

Andrej Karpathy — a co-founder of OpenAI and Tesla's former AI director — coined it in a tweet on February 6, 2025, while describing his own daily habit, not proposing a methodology — which is why the definition was narrow from the start.

What's the difference between vibe coding and normal AI-assisted coding?

Not the tool — review. In AI-assisted coding, the developer reads diffs, writes tests, and can explain the change. In vibe coding, that step is deliberately skipped — in Karpathy's own words, "I don't read the diffs anymore."

Can you write a production app with vibe coding?

Karpathy's own definition scopes it to "throwaway weekend projects," not production-grade engineering. Moving to production requires a handoff of responsibility: reading diffs, writing tests, reviewing authorization and the data model.

Is vibe coding safe?

Vibe coding itself isn't unsafe, but the areas it leaves unreviewed — authorization, the data model — leave the door open for security holes to slip into production unnoticed. Critical business logic should be written in review mode, not vibe mode.

Which projects does vibe coding work well for?

Best for prototyping, architectural exploration, and single-user/throwaway tools. Per Y Combinator data, a quarter of W25-cohort startups produced 95% of their codebase this way — but even those are still run by technical founders.

Update (September 2026)

According to sources compiled by Wikipedia, adoption of the term has expanded rapidly since March 15, 2025: Collins English Dictionary named "vibe coding" its 2025 Word of the Year. In January 2026, Linus Torvalds was reported to have vibe-coded a small visualization tool for a hobby project using Google Antigravity; in his own README notes he wrote, "the python visualizer tool has been basically written by vibe-coding" — consistent with Karpathy's original "throwaway weekend project" framing, showing that even an experienced engineer stays within the same boundaries.

After this article, the debate split in two directions: "spec-driven" flows that put a written intermediate step between intent and generation, and the auditing of agent authorization.

Both topics are, in fact, a natural continuation of this article's central distinction. "Spec-driven" flows try to bring back the "understanding" step vibe coding skips, by inserting a step between intent and generation — writing down what will be done first, then generating the code. Auditing agent authorization addresses, at an organizational scale, exactly the risk pointed out in the "where it breaks" section. The 10 misconceptions about AI coding article, which compiles where AI coding tools mislead in the real world, captures the current state of this same boundary debate.

Conclusion

Vibe coding has remained a topic of debate since Karpathy defined it on February 6, 2025 — but most of that debate stems from forgetting the term's own boundaries. Karpathy's definition was narrow from the start: throwaway, low-risk, single-user projects. Stay within that boundary and vibe coding delivers a real speed gain; cross it — touching the data model, authorization, or a multi-person codebase — and that same speed becomes a silent risk.

You can see the concrete steps for moving from prototype to production in the guide to building a full-stack app from a prompt with Lovable and the Bolt.new browser flow; you can find the security risk of authorization granted to agents in the article on granting authorization to an AI coding agent. A tool used with knowledge of its boundary is worth far more than the same tool used without knowing it.

Sources

• Vibe coding — Wikipedia — general reference for the term's chronology and source chain.
• Simon Willison — Not all AI-assisted programming is vibe coding — primary source quoting Karpathy's original tweet verbatim.
• The Guardian — AI, software coding, and the future of programmer expertise — carries Karpathy's 2023 "English" quote and the period's discussion.
• TechCrunch — 95% of codebases AI-generated in YC W25 cohort — Jared Friedman and Diana Hu quotes.
• Anthropic — Building effective agents — background for the workflow/agent distinction and handoff-of-responsibility section.