What is Vibe Coding?

Coined in early 2025, "vibe coding" means giving AI a loose description and seeing what happens:

"Build me a todo app with a nice UI"

You don't specify the tech stack, architecture, or requirements. You let the AI make all the decisions and iterate based on what you see.

The vibe coding workflow:

1. Describe what you want in plain English
2. Let the AI generate everything
3. Run it and see what happens
4. Say "make the buttons bigger" or "add a dark mode"
5. Repeat until it looks right

It's like giving directions by feel:

"Go that way until you see a coffee shop, then turn left"

vs. giving coordinates:

"Go to 123 Main Street, Building B, Floor 3"

What is Spec-Driven Development?

The opposite approach — precise specifications before any code is generated:

## Feature: User Authentication
### Requirements:
- JWT-based authentication with refresh tokens
- Passwords hashed with bcrypt (12 salt rounds)
- Login endpoint: POST /api/auth/login
- Token refresh: POST /api/auth/refresh
- Rate limit: 5 failed attempts per 15 minutes
- Token expiry: 15 min access, 7 day refresh
### Tech Stack: Express.js, MongoDB, jsonwebtoken
### Tests: Jest, minimum 90% coverage on auth module

Every decision is made upfront. The AI executes the spec, not its imagination.

When to Vibe Code

Vibe coding works best when the stakes are low and speed matters:

Great for:

• Prototypes and proof-of-concepts
• Personal projects and experiments
• Hackathons and demos
• Exploring a new framework or library
• One-off scripts you'll use once
• Learning — see how the AI approaches problems

Example — perfect vibe coding scenario:

"I need a quick script that reads a CSV of employee names and generates birthday reminder emails. Nothing fancy, just functional."

No spec needed. If it works, ship it. If it doesn't, iterate.

When to Spec First

Spec-driven development is essential when the code matters:

Required for:

• Production systems with real users
• Features with security implications (auth, payments, data handling)
• Code that other developers will maintain
• Systems with compliance requirements (HIPAA, SOC 2)
• Performance-critical paths
• Anything involving money or sensitive data

Example — this needs a spec:

Building a multi-tenant API gateway that handles authentication, rate limiting, and cost tracking across 50 enterprise customers.

Vibe coding this would produce inconsistent, insecure, unmaintainable code.

The Mindset Shift

Traditional development vs. AI-assisted development:

Traditional:

Think → Design → Code → Test → Debug → Ship
(You do everything)

AI-Assisted (Spec-Driven):

Think → Spec → AI Codes → You Review → Test → Ship
(You focus on WHAT, AI handles HOW)

AI-Assisted (Vibe):

Describe → AI Codes → See Result → Iterate → Ship
(You guide by feeling, AI does everything)

The key insight: Your job shifts from writing code to defining problems clearly and reviewing solutions critically. The better you are at articulating what you want, the better the AI output.

The Hybrid Approach

In practice, most experienced developers use both:

Phase 1: Vibe code a prototype (30 minutes)
  → "Build me a dashboard that shows API usage stats"
  → Get a working prototype, see if the concept works

Phase 2: Spec the production version (2 hours)
  → Write detailed requirements based on what you learned
  → Specify data models, API contracts, error handling
  → Define security requirements and test criteria

Phase 3: AI builds from spec (1 hour)
  → Provide the spec + the prototype as reference
  → AI generates production-quality code
  → You review, test, and iterate on specific issues

Rule of thumb: Vibe code to explore. Spec to build. Never ship vibe code to production without a review pass.

Common Mistakes

Pitfalls when choosing between approaches:

Mistake	Why It's a Problem	Fix
Vibe coding a security feature	AI makes insecure default choices	Always spec security requirements
Over-specifying a prototype	Wastes time on throwaway code	Let the AI surprise you
No review of vibe-coded output	Hidden bugs, bad patterns	Always review before committing
Spec without examples	AI misinterprets requirements	Include input/output examples
Never iterating on the spec	First spec is rarely perfect	Update spec based on AI output

The biggest mistake: assuming AI-generated code is correct because it compiles and runs. Always review, especially security-sensitive code.

---quiz question: What is "vibe coding"? options:

• { text: "A strict methodology with detailed specifications", correct: false }
• { text: "Giving AI a loose description and iterating based on what you see", correct: true }
• { text: "Coding while listening to music for inspiration", correct: false }
• { text: "A type of pair programming with another human", correct: false } feedback: Vibe coding means describing what you want in plain English without detailed specs, letting the AI make decisions, and iterating based on the result. It's fast but best for low-stakes work.

---quiz question: When should you always use spec-driven development instead of vibe coding? options:

• { text: "When building personal side projects", correct: false }
• { text: "When building production systems with security implications", correct: true }
• { text: "When using a new programming language for the first time", correct: false } feedback: Production systems — especially those involving security, compliance, money, or sensitive data — require detailed specifications. Vibe coding these would produce inconsistent, insecure, unmaintainable code.

---quiz question: What is the "hybrid approach" to AI-assisted development? options:

• { text: "Using two different AI models at the same time", correct: false }
• { text: "Vibe code a prototype to explore, then write a spec for the production version", correct: true }
• { text: "Writing half the code manually and half with AI", correct: false } feedback: The hybrid approach uses vibe coding for rapid prototyping and exploration, then switches to spec-driven development for the production implementation — getting the speed of vibe coding with the quality of spec-driven work.