AI Coding's Vibe Problem: Why Spec-Driven

There's a moment in every developer's AI coding journey where the magic turns into a slot machine. You prompt the model for a login page, get something workable. Run it again with the same prompt, get something different. Third time? Different again. Welcome to what IBM's Cedric Clyburn calls "vibe coding"—and according to his recent explanation of spec-driven development, it's a symptom of skipping the parts of software engineering that used to keep us sane.

The term "vibe coding" is perfect because it captures exactly what's happening: you're vibing with an LLM, iterating on prompts until something feels right. No formal requirements. No design document. Just you, the model, and a conversational loop that might eventually produce what you want. "We could do a hundred different tries of this implementation of the app we want to create. We might get a different result every time," Clyburn notes. "And that frustrates a lot of people."

But the frustration isn't just about inconsistency. It's about losing traceability. When the model makes a decision, you often can't track why it made that choice. Was it the training data? Your phrasing? Pure randomness in the sampling? This matters less for throwaway prototypes and more as you build production systems where "it just worked this time" isn't a debugging strategy.

The Old Guard Returns

Spec-driven development is essentially the software development lifecycle (SDLC) dragged back from the retirement home. Remember when projects started with requirements documents? When you'd plan, design, implement, test, deploy, and maintain in somewhat orderly phases? That whole structure largely evaporated in the AI coding era because LLMs could jump straight from casual request to working code.

Clyburn's pitch is to resurrect that structure, but adapted for AI agents. Instead of prompting for implementation ("build me a login page"), you prompt for specification ("the system should authenticate users via POST request to /login, accepting username and password parameters"). That spec becomes the contract that drives everything downstream—design documents, implementation, test cases, documentation.

The appeal is clear: less ambiguity, more control, better auditability. You define what you want the system to do rather than how to do it, then let the AI agent work from that specification. If something goes wrong, you can trace it back to the spec rather than trying to reverse-engineer why the model chose option B over options A, C, and D.

"AI models are all about proper instructions," Clyburn emphasizes. "So having a spec like this is much better than having the LLM guess what solution is going to hopefully best fit the user's request."

The Unasked Questions

What's interesting is what this approach assumes about the problem. Spec-driven development treats AI coding's main issue as insufficient structure—that developers need to provide more formal requirements upfront. But there's another possibility: maybe the problem is that LLMs are fundamentally unsuited for tasks that require consistency and traceability in the first place.

Consider what happens in Clyburn's spec-driven workflow. You still start with a prompt, just a different kind of prompt. That prompt gets interpreted by the model to generate requirements. If you're happy with those requirements, you approve them, and they become the design document. But you're still trusting the model to correctly interpret your specification prompt, correctly transform it into requirements, and correctly implement those requirements in code.

The model is still a black box. You've just added more formalized checkpoints where you can inspect its output before it moves to the next phase. That's valuable—catching problems at the requirements stage beats catching them in production. But it doesn't solve the underlying question of whether LLM outputs are deterministic enough for critical systems.

There's also a workflow question that the video doesn't address: who writes these specs? In traditional SDLC, requirements documents came from product managers, business analysts, sometimes clients. They were written in natural language precisely because the people defining what to build weren't always the same people defining how to build it. If developers are now writing formal specs to feed to AI agents, have we just shifted the work rather than reducing it?

Clyburn positions spec-driven development as "test-driven development and behavior-driven development on steroids." That's a generous framing. TDD and BDD succeeded because they changed how developers thought about code—tests first meant designing for testability, thinking about contracts and interfaces. Spec-driven development might achieve something similar by forcing upfront clarity about requirements. Or it might just be additional ceremony that feels productive but slows down the very thing that made AI coding attractive: speed.

Where This Actually Helps

Here's what I find genuinely useful about this approach: it creates deliberate decision points. In vibe coding, you're making micro-decisions constantly—should I accept this implementation? Should I tweak the prompt? Should I try again? It's cognitively exhausting and makes it easy to settle for "good enough" when you're just tired of iterating.

Spec-driven development front-loads those decisions. You decide what you want once, in the requirements phase. Then you decide if the design matches those requirements. Then you let implementation happen. Each phase has a clear exit criterion. That's legitimately valuable for complex projects where keeping the full context in your head becomes impossible.

It's also valuable for team environments. Vibe coding is inherently solo—it's you and the model in a conversation that's hard to share or review. Spec-driven development produces artifacts (requirements, design docs) that other developers can read, critique, and build on. The spec becomes shared understanding, not just between you and the AI, but between you and your team.

For security-critical code, which is most code worth deploying, having that audit trail matters. You can point to the requirement that said "sanitize all user input" and trace whether that requirement made it into the design, the implementation, and the tests. In vibe coding, best practices like input sanitization might or might not emerge depending on what the model happened to include that iteration.

The Real Test

The question isn't whether spec-driven development is better than vibe coding in theory. The question is whether developers will actually use it when the deadline is Tuesday and vibe coding can get something working by Monday evening. Process only works if it's worth the friction it creates.

Clyburn's framework is rigorous, and rigor is exactly what gets abandoned under pressure. If spec-driven development can demonstrate that its upfront investment actually saves time over the full project lifecycle—fewer bugs, less rework, easier maintenance—it'll win. If it turns out to be another layer of process that mostly generates documents nobody reads, it'll join the long history of software methodologies that sounded great in conference talks but died in production.

What's clear is that purely conversational coding with LLMs has real limitations. Whether the answer is more structure or better models or entirely different tools is still being worked out. But the conversation has shifted from "AI can write code!" to "how do we write code with AI in a way that doesn't make everything worse?" That's progress, even if we haven't figured out the answer yet.

— Rachel "Rach" Kovacs, Cybersecurity & Privacy Correspondent