What is Vibecoding?

Vibecoding is a way of writing software where you describe what you want in natural language, let an AI write and edit the code, and move forward by accepting or correcting its output without reviewing it line by line. Andrej Karpathy coined the term in early 2025: you "give in to the vibes and forget that the code even exists."

The core shift is one of focus. Instead of writing instructions for the machine, you write intentions for an agent: "make the hero more compact," "the button isn't centered, fix it," "now add a pricing section." The model turns that into code and applies it. You look at the running result, not the diff.

What is it

Vibecoding is the fast, exploratory mode of AI-assisted development. Three traits define it:

• You steer by outcome, not implementation. You describe the goal and the expected behavior; the AI decides how to write it.
• You iterate in natural language. Every adjustment is a short sentence, not a manual edit. The ask → see → ask-again loop takes seconds.
• You relax review on purpose. You don't read every line it generates. You trust what you see working and keep going.

That last point is what separates vibecoding from disciplined AI-First development. Review doesn't disappear; it gets deferred. The trade is explicit — speed now, rigor later — and it only works if you know when to pay that debt back.

Mental model

Think of the difference between a sketch and a blueprint.

You make a sketch quickly, freehand, to see if the idea holds up. You don't hand it to a builder. If it works, you redraw it properly with real measurements. Vibecoding is sketching, but in code: you explore an idea, a screen, a flow, knowing that what comes out is either throwaway material or material you'll harden later.

Where it sits relative to other terms:

• AI-First development is the full paradigm: the human directs architecture and judgment, the AI executes, and everything goes through review.
• Vibecoding is one lane inside that paradigm: the stretch where you lower your review guard to move at the speed of ideas.
• The antipattern shows up when vibecoding is used without judgment: code nobody understands reaching production, the "illusion of speed" that collapses in real applications.

How it's used

Vibecoding pays off when you apply it to a small, low-risk surface with a short iteration loop.

1. Pick the ground. A prototype, a landing page, a screen, a one-off script. Nothing that touches authentication, sensitive data, or business logic.
2. Give context and constraints. Explicit stack, visual references, what you don't want it to touch. "React + Tailwind, Lucide icons, don't add new libraries."
3. Iterate in surgical steps. Instead of regenerating the whole screen, ask for scoped changes: "in Hero.tsx, bump vertical padding to py-20 and center the button."
4. Stop when it works. If the result is disposable, you're done. If it's staying in the project, that's where the other work starts: read what was generated, write tests, separate responsibilities, delete what's dead.

Common tools for vibecoding: Claude Code, Cursor, v0 by Vercel, Bolt, Lovable.

Example

In this React + Tailwind project, create a modular landing page for a
shared-expenses app. Split it into Hero.tsx, Features.tsx, and Footer.tsx.
The Hero has a split calculator. Dark mode, emerald accent.
Start the server when you're done.

The AI generates the three components and runs npm run dev. You open the browser, see the page, and continue with one-sentence adjustments: "make the feature grid 3 columns on desktop and 1 on mobile."

When to use it / when not to

Use vibecoding when:

• You're exploring an idea and don't yet know whether it's worth building properly.
• The output is a prototype, a technical spike, or a demo with an expiration date.
• It's a landing page or visual interface with no critical logic behind it.
• You're learning a new framework and want to see something running fast.
• You can verify the result at a glance or with a quick test.

Don't use vibecoding when:

• The code goes into a production path that others will maintain.
• Security is involved: authentication, secret handling, permissions.
• It's business logic or domain rules, where a subtle bug has real cost.
• It's data migrations or operations that are hard to reverse.
• You have no way to verify whether what it generated is correct. "It works" is not "it's correct."

The real risk of vibecoding is accumulating code you don't understand. Every time you accept output without reading it, you add debt. That's fine while the ground is disposable and you know it's a decision, not an oversight.

History and evolution