Vibe Coding Is NOT the Problem — Ignorance Is

Vibe coding went from Andrej Karpathy tweet → Collins Dictionary Word of the Year → internet punching bag in under 12 months. That's an impressive fall from grace.

And honestly? We're blaming the wrong thing.

Here's my hot take: vibe coding isn't the problem. Developer illiteracy around AI coding methods is.

There's a whole spectrum of ways to use AI for coding — and most developers only know about the two extremes. Then they pick a side, plant a flag, and start a Twitter war about it.

Let's fix that.

Watch Full Video

First, why does vibe coding have a bad rap?

To be fair, the critics aren't entirely wrong. A 2025 Veracode study found that a significant chunk of AI-generated code ships with security vulnerabilities — including classic OWASP Top 10 hits. AI models hallucinate packages that don't exist. People accept generated code without reading it and then act surprised when prod breaks.

But here's the thing: none of that is a vibe coding problem. It's a wrong-tool-for-the-job problem.

Using vibe coding to build a healthcare data pipeline with strict compliance requirements is like using a butter knife to do surgery. The butter knife isn't broken. You just made a terrible choice.

The actual spectrum of AI coding (nobody talks about this)

Everyone frames this as a two-horse race:

🤠 Vibe Coding (chaotic, fun, dangerous?) vs. 📋 Spec-Driven Development (serious, responsible, slightly boring?)

But there are four distinct methods, and understanding all of them is the whole point:

1. 🎲 Vibe Coding

"Just tell the AI what you want and see what happens"

Direct prompts, zero formal planning, iterate until it works. This is the default starting point for basically everyone — developers and non-developers alike.

Tools like Bolt, Lovable, Replit, and Base44 have turned this into full app builders where a single prompt can spit out a working product with UI, backend, and deployment. Wild times.

Fun fact: Linus Torvalds vibe coded a component for his AudioNoise project and said it was "basically written by vibe-coding" in the README. If it's good enough for the Linux guy, maybe chill with the discourse.

2. 🤖 AI Code Assistants

"AI helps, but I'm still driving"

GitHub Copilot, OpenAI Codex, Cursor — living inside your editor, autocompleting your thoughts. Code completion, unit test generation, inline review.

Most professional devs are already here and just don't label it. You write the architecture, AI handles the boilerplate. This is the most mature and least controversial point on the spectrum.

3. 📝 Structured AI Coding

"I write context files, AI follows them"

This one doesn't have an official name, which is probably why it gets skipped in every hot take. No formal framework — just the developer writing detailed markdown files upfront: architecture decisions, coding standards, business context, constraints.

The AI doesn't get a spec. It gets a really good briefing. Works great for solo devs and small teams who want structure without the ceremony.

4. 📋 Spec-Driven Development

"Formal specs are the source of truth, code is almost a side effect"

Thoughtworks called this one of the most important practices to emerge in 2025. Tools like GitHub's Spec Kit and AWS Kiro turn detailed specifications into AI-executable task definitions.

The idea: stop treating AI agents like Google and start treating them like very literal junior devs who need exact instructions. Great for enterprise projects, compliance-heavy systems, and large teams. Comes with real overhead though — writing good specs takes serious time and upfront clarity.

Where vibe coding actually belongs (and shines)

Now that we have the full picture, let's be specific about where vibe coding is genuinely the right call — not a compromise, not a shortcut, but the correct tool:

🎨 Creative / UI work — interfaces, design explorations, landing pages. Fewer hard constraints. Small mistakes don't nuke your database. You don't need a spec to know if a button looks good.

🧩 Well-understood problems — want to build Tetris? Every AI model already knows how Tetris works. Writing a formal spec for Tetris is not rigorous, it's just slower. Same logic applies to any standard, well-documented problem domain.

⚡ Prototypes and MVPs — validate the idea first, add structure later. Vibe coding can get you from "shower thought" to "live demo" in a single afternoon.

🔀 Outside your domain — a backend dev who needs to build a frontend isn't going to write a spec for their first React component. They're going to prompt their way through it. That's not laziness. That's pragmatism.

Real talk: most devs already blend these

The developers doing the best work with AI aren't purists. They're switchers. They flow between methods based on the actual problem in front of them.

A realistic workflow might look like:

Start with vibe coding → get a rough UI prototype working

Switch to structured AI coding → feed context files for the backend

Bring in spec-driven practices → just for the payment flow with real compliance needs

Use AI assistants → throughout, for tests and review

No purity. No manifesto. Just pragmatism.

The truly ironic part? Even the most formal spec-driven projects often start with a quick vibe coding session to understand the problem before writing the spec. The method most opposed to vibing... starts with vibing.

The tools, for reference

TL;DR

Vibe coding isn't bad. Spec-driven dev isn't always necessary. They're just different tools for different situations — and treating them as moral opposites is the actual problem.

The dev community loves a villain. This year it's vibe coding. Next year it'll be something else.

Meanwhile, the people actually shipping great software are quietly using whichever method fits the problem. Sometimes that's a one-liner prompt. Sometimes it's a 40-page spec. Most of the time it's something in between.

Learn the spectrum. Match the method to the problem. Stop blaming the hammer for being a bad screwdriver.

What's your go-to method for AI-assisted coding? Drop it in the comments — especially if you've got a workflow that doesn't fit neatly into any of these four categories.