What is vibe coding?

TL;DR. Vibe coding is writing software by describing what you want in plain English and letting an AI write the code — without reading or reviewing most of what it produces. The term was coined by Andrej Karpathy in February 2025 in a tweet describing how he'd been building apps. It works well for prototypes, personal tools, and low-stakes software; it breaks down when correctness matters more than vibes.

Where the term came from

Andrej Karpathy (formerly of OpenAI, Tesla, and Stanford) posted in February 2025 that he'd started building software in a new way — describing what he wanted, letting Cursor write the code, accepting most of it without reading, and iterating by describing what felt wrong. He called it "vibe coding," half-joking. The tweet went viral.

His framing: the feedback loop wasn't "write code, compile, test, fix." It was "describe intent, see result, adjust vibes." Not literally ignoring the code — when something broke he'd look — but the normal expectation of "you own everything you ship" was suspended in favor of "you own the intent; the AI handles the rest."

What it actually means

Vibe coding is a workflow, not a tool. It describes how you interact with an AI coding assistant, not which assistant you use. The defining characteristics:

• Intent is the input. You describe outcomes, not implementation. "Build a habit tracker" not "create a React component with useState for habits."
• Code isn't reviewed line-by-line. You accept or reject the result based on whether it works, not based on reading the code.
• Iteration happens in natural language. When something's wrong, you describe it ("the header is too cramped") and let the AI fix it.
• Correctness is tested by running, not by reading. "Does it do what I wanted?" replaces "does this code compile / match the spec."

The name "vibe" is important. It signals that the method isn't rigorous. You're operating on feel. That's intentional — the whole point is to skip the overhead of formal specification when the stakes don't require it.

When vibe coding works

It works well for:

• Personal tools. A habit tracker, a family chore app, a hobby dashboard. If it breaks, the cost is low.
• Prototypes and demos. Proving an idea works doesn't require production-quality code.
• Internal team tools. A form that captures vendor requests, an internal CRM for a 5-person team. Low-stakes, low-scale.
• One-off scripts. Data extraction, file processing, migration helpers — scripts you'll run once or twice.
• Exploration. "What would this design feel like if the sidebar were on the other side?" Questions that are faster to answer by trying than by planning.

The common thread: the cost of being wrong is low, and "it feels right" is a sufficient quality bar.

When vibe coding breaks down

It breaks down for anything where correctness matters more than vibes:

• Financial code. If a rounding error means someone loses money, "looks right" isn't enough.
• Security-sensitive features. Auth, cryptography, anything dealing with secrets. The AI can produce code that looks fine and has a subtle vulnerability.
• Code that will be maintained by others. If the next person to read it isn't you-plus-AI, they need code written to be understood, not just to work.
• High-scale systems. Performance issues often hide in the code you didn't read. At scale, "the vibe was right" won't save you from a subtle N+1 query bug.
• Domain-specific correctness. Medical calculations, legal compliance, accessibility requirements — the AI is generally good but "generally" isn't sufficient for domains where specific correctness matters.

The honest rule: the less reversible and less fixable a mistake is, the worse vibe coding suits the job.

Vibe coding vs. traditional AI-assisted coding

Both use AI, but the posture is different:

The tools that enable it

Vibe coding isn't specific to one tool, but the tools matter. The ones most associated with the workflow:

• Cursor — "Composer" mode where AI edits multiple files at once.
• Claude Code — terminal-based; strong at multi-step plans.
• Lovable / Bolt.new / v0 — app-generation tools that produce full apps from prompts.
• Hatchable — hosts the output of whatever AI you vibe-code with.

Earlier-generation tools (GitHub Copilot, original Cursor autocomplete) are traditional AI-assisted — they suggest, you approve. Newer agent-style tools enable vibe coding by doing more of the work in larger steps.

Is vibe coding a good thing?

It depends who you ask. The range of honest opinions:

In favor: vibe coding democratizes building. People who can't or don't want to learn React can now build working apps. Most software doesn't need production-grade engineering — a one-family chore app doesn't need code review. Letting the AI handle details means humans spend time on the interesting parts (what to build, not how to build it).

Against: vibe coding accumulates technical debt invisibly. Code you don't read has bugs you don't see. At scale, someone eventually pays the cost. Teaching people that "code is a vibe" trains them out of the rigor that real software engineering requires. The AI is good, not infallible, and "mostly works" software at scale causes real problems.

Both are right. The practical answer is that vibe coding is a tool with a specific use case, not a general replacement for software engineering. The skill is knowing when it's appropriate.

How to vibe code effectively

A few things that separate good vibe coding from bad:

1. Start with a specific description. "Build a habit tracker" is vague; "build a habit tracker where I can add habits with a color and see a monthly grid with checkmarks" is specific. Specificity up front beats correction later.
2. Iterate by describing behavior, not code. "The header is cramped" is better than "change the margin-top on h1." Let the AI make the specific code change.
3. Read the code when something feels off. Trust-but-verify. If the app looks right but is slow, glance at the code — you don't need to read every line, just the part that's likely slow.
4. Keep scope narrow. Vibe-coding a 20,000-line project is harder than vibe-coding a 200-line one. The approach scales sub-linearly.
5. Be honest about the stakes. If the app is handling money, reviewing medical data, or running in production with real users — the stakes aren't vibe-coding stakes anymore.

The cultural moment

Vibe coding is partly a joke and partly a real shift. The joke is that "coding by vibes" is how beginners accidentally worked all along — they just didn't have the quality of output that AI enables. The shift is that now even experienced engineers do it for certain tasks, and the output quality is often good enough.

Andrej's framing captured something that had been quietly happening for a few years: the barrier between "I have an idea for a tool" and "I have a working tool" has collapsed. That collapse changes what's worth building — projects that weren't worth the engineering cost before are now worth trying. Most of them will be small, personal, and unimportant. Some will turn out to be big. Either way, more people will try.