Vibe Coding

A development approach where you describe what you want in natural language and let an AI coding assistant generate the code — the developer guides direction and reviews results rather than writing every line.

What is it?

Vibe coding is a way of building software where the developer works primarily through natural language conversation with an AI coding assistant. Instead of typing code character by character, you describe what you want — “build me a login page” or “add a sorting feature to this list” — and the AI generates the code. You review the result, ask for changes, and iterate through conversation.

The term entered developer culture in early 2025, attributed to Andrej Karpathy describing the sensation of giving high-level direction and “vibing” while the AI does the heavy lifting. It quickly became one of the most discussed concepts in modern software development.

Vibe coding is genuinely powerful for certain tasks: prototyping, learning, small projects, and exploration. But it has well-documented failure modes that become critical as projects grow. Understanding both its strengths and its limits is essential — because knowing when to stop vibe coding and switch to spec-driven-development is one of the most important judgement calls in AI-assisted development.

The core workflow is simple: describe intent, review output, iterate, ship. The complexity lies in knowing when this workflow is sufficient and when it isn’t.

In plain terms

Vibe coding is like giving verbal directions to a talented artist. You say “paint me a sunset over mountains” and they produce something beautiful. For a single painting, this works wonderfully. But if you need 50 paintings that form a consistent series, verbal directions alone will lead to inconsistencies — you’ll eventually need written style guides and reference sheets.

At a glance

The vibe coding loop (click to expand)
graph LR
    A[Describe Intent] -->|natural language| B[AI Generates Code]
    B -->|review output| C[Accept or Refine]
    C -->|looks good| D[Ship]
    C -->|needs changes| A
    style A fill:#4a9ede,color:#fff
Key: The developer stays in the “describe and review” loop. There is no written specification, no formal plan — intent lives in the conversation. This is fast for small tasks but fragile for large projects, because conversations are ephemeral and context windows have limits.

How does it work?

Vibe coding has a characteristic workflow and a set of situations where it excels and where it breaks down. Understanding both sides is what makes you effective.

1. The core loop

The developer describes what they want. The AI generates code. The developer reviews and either accepts or asks for changes. This loop repeats until the result is satisfactory.

"Build a card component that shows a title, description, and image"
  → AI generates a React component
    → "Make the image rounded and add a hover effect"
      → AI updates the component
        → "Looks good, ship it"

The loop is fast — minutes instead of hours. For the right tasks, this speed is transformative.

Think of it like...

Directing a very fast, very literal assistant. They’ll do exactly what you say, impressively quickly. But they won’t ask clarifying questions, won’t remember what you said yesterday, and won’t warn you that your request contradicts something you asked for last week.

2. Where vibe coding excels

Situation	Why it works
Prototyping	Speed matters more than correctness; you’re exploring, not shipping
Small, self-contained tasks	Everything fits in one conversation; no context to lose
Learning	Seeing how concepts translate to code is immediately educational
One-off scripts	Utilities, data transformations, automation scripts you’ll run once
UI exploration	Trying visual ideas quickly before committing to a design system

3. Where vibe coding breaks down

Failure mode	What goes wrong
Context loss	Multi-session projects lose conversational context; decisions drift
Inconsistency	Without a spec, similar features get implemented differently
Black-box dependency	The code works but you can’t explain why — dangerous for debugging
Hidden tech debt	The AI takes shortcuts you don’t notice until they compound
Edge case blindness	The AI handles the happy path well but guesses at error handling and security

The failure mode that matters most

“The code was clean. The tests passed. But I couldn’t confidently explain why it worked the way it did.” This is the black-box dependency problem. When you don’t understand the code you’re shipping, you can’t debug it, extend it, or teach it to anyone else.

4. The spectrum from vibe to spec

Vibe coding and spec-driven-development aren’t binary — they form a spectrum. You can add structure incrementally as a project grows:

Level	What you add	When to add it
1. Pure vibe coding	Nothing — describe and hope	Prototyping, throwaway code
2. + README / PRD	Define what “done” looks like	When the project will span multiple sessions
3. + Spec files	Define behaviour explicitly	When correctness matters
4. + Plan files	Define order and dependencies	When the project has multiple features
5. + Automated tests	Verify against acceptance criteria	When you’ll maintain the code long-term
6. Full SDD	All of the above	Production software

Concept to explore

See spec-driven-development for the structured end of this spectrum — what to do when vibe coding is no longer enough.

Why do we use it?

Key reasons

1. Speed. Vibe coding produces working code in minutes. For prototypes and explorations, this speed is unmatched. You can try five approaches in the time it would take to write one specification.

2. Low barrier to entry. You don’t need deep expertise in a language or framework to produce working code. Natural language is the interface. This democratises software creation.

3. Learning accelerator. Seeing your intent translated into code teaches you how the technology works. You learn patterns by seeing them generated, then understanding why they work.

4. Exploration. When you don’t yet know what you want, vibe coding lets you experiment cheaply. Build it, see it, decide if it’s what you need. This is valuable at the start of any project.

When do we use it?

When exploring a new idea and you don’t yet know if it’s worth building properly
When building a prototype to test feasibility or get feedback
When working on small, self-contained tasks that fit in one session
When learning a new technology by building something with it
When writing one-off scripts or utilities you won’t maintain

Rule of thumb

Vibe code to explore, spec to build. If you’ll use the code once, vibe it. If you’ll maintain it, spec it. If you’re unsure, start vibing and add structure the moment you decide to keep the code.

How can I think about it?

The jazz improvisation

Vibe coding is like jazz improvisation. A jazz musician doesn’t read from sheet music — they feel the key, hear the chord changes, and play what sounds right in the moment. The result can be brilliant and surprising. But it’s hard to reproduce, hard to teach to others, and only works when the musician deeply understands the underlying theory.

The musician’s ear = the developer’s review of AI output

The key and chord progression = the programming language and framework constraints

A brilliant solo = a working prototype built in minutes

“Play that exact same solo again” = the reproducibility problem

A symphony orchestra = a production codebase (needs sheet music / specs)

Jazz is wonderful. But you don’t improvise a symphony.

The sketch vs. the technical drawing

An architect sketches ideas on a napkin during a coffee meeting. Quick, loose, exploratory — great for communicating a vision and testing ideas. But nobody builds a skyscraper from a napkin sketch. At some point, the sketch needs to become a technical drawing with precise measurements, materials specifications, and structural calculations.

Napkin sketch = vibe coding (fast, exploratory, disposable)

Technical drawing = spec-driven development (precise, testable, permanent)

The napkin = a conversation with an AI (ephemeral)

The blueprint = a written specification (version-controlled)

Knowing when to switch = the key skill in AI-assisted development

Concepts to explore next

Concept	What it covers	Status
spec-driven-development	The structured approach that evolves from vibe coding	complete
prd	The first document that adds structure to unstructured work	stub
prompt-engineering	How to write better prompts for AI coding assistants	stub
technical-debt	The hidden cost of shortcuts that compound over time	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Test yourself (click to expand)

Explain what vibe coding is to someone who has never used an AI coding assistant. What does the workflow actually look like?

Name three situations where vibe coding is the right approach and three where it’s dangerous. What distinguishes the two groups?

Distinguish between vibe coding and spec-driven development. What does SDD add that vibe coding lacks?

Interpret this scenario: a developer vibe-codes a web application over three weeks. In week three, they add a feature that breaks something from week one, but they don’t notice because they can’t remember how week one’s code works. Which failure mode is this?

Connect vibe coding to iterative-development. Where on the iterative cycle does vibe coding work best, and where does it need to be replaced with more structure?

Where this concept fits

Position in the knowledge graph
graph TD
    ID[Iterative Development] --> VC[Vibe Coding]
    ID --> SDD[Spec-Driven Development]
    ID --> WS[Walking Skeleton]
    ID --> VS[Vertical Slices]
    VC -.->|evolves into| SDD
    style VC fill:#4a9ede,color:#fff
Related concepts:

spec-driven-development — the structured evolution of vibe coding; what you switch to when the project outgrows conversations

prd — the first written artifact that bridges vibe coding and structured development

walking-skeleton — can be vibe-coded initially, then solidified with specs

Yiuno

Explorer

Vibe Coding

Vibe Coding

What is it?

At a glance

How does it work?

1. The core loop

2. Where vibe coding excels

3. Where vibe coding breaks down

4. The spectrum from vibe to spec

Why do we use it?

When do we use it?

How can I think about it?

Concepts to explore next

Check your understanding

Where this concept fits

Further reading

Graph View

Table of Contents

Backlinks