By ByteBot
Nine months ago, vibe coding was revolutionizing software development. This week, it’s dead. AWS launched Kiro into general availability on November 17, positioning spec-driven development as the cure for vibe coding’s chaos. GitHub released Spec Kit. Fifteen platforms now push specs-first workflows. However, the industry has pivoted hard.
But critics see trouble. “The Waterfall Strikes Back,” warned developer François Zaninotto on November 12. Moreover, Martin Fowler expressed cautious skepticism about tools creating “inflexibility and non-determinism simultaneously.”
Did we fix vibe coding’s problems? Or are we repeating the Big Design Up Front mistakes that killed Waterfall in the 1990s?
The Spec-Driven Development Pitch
Spec-driven development means writing specifications in markdown before AI generates code. First, you create requirements.md describing what you want. Then, the AI generates a design document. Next, it breaks the design into tasks. Finally, it implements each task, guided by your specs.
Kiro attracted 250,000 developers in its first three months. The promise is compelling: specs provide structure that vibe coding lacked. Additionally, they align stakeholders, guide AI agents, and transform development “from an ad-hoc exercise in prompt engineering to deliberate, tracked work,” according to AWS.
GitHub’s Spec Kit toolkit calls specifications “living, executable artifacts.” Update the spec, regenerate the plan, let the agent handle implementation. Furthermore, Red Hat argues specs improve AI coding quality by giving agents clear requirements.
After vibe coding’s collapse—developers couldn’t debug code they never understood—some structure seems necessary.
The Waterfall Echo
Except we’ve heard this pitch before.
Big Design Up Front promised the same benefits in the 1970s. Complete your design, perfect your documentation, then implement. Nevertheless, Waterfall methodology assumed detailed specifications eliminated uncertainty.
It didn’t. Requirements changed. Users provided feedback only at the end, when fixing issues cost exponentially more. Consequently, designers couldn’t foresee all problems without prototyping. Winston Royce’s 1970 diagram introducing Waterfall warned the approach had “major flaws”—yet the industry adopted it anyway and spent two decades learning why he was right.
The Agile Manifesto, created by 17 developers in February 2001, was a direct reaction to Waterfall’s bureaucracy. Its core values directly contradict spec-driven development:
- “Working software over comprehensive documentation”
- “Responding to change over following a plan”
Spec-driven development prioritizes comprehensive specs and requires following the plan. That’s not iteration. That’s regression.
“Agile methodologies freed us from the bureaucracy of waterfall,” Zaninotto writes. “Coding agents supercharge Agile.” Therefore, spec-driven development, he argues, resurrects the bureaucracy Agile killed.
Seven Ways Spec-Driven Development Fails
Zaninotto identifies specific problems already emerging:
Context Blindness: Like earlier coding agents, spec-driven agents discover context through text search and file navigation. They miss existing functions needing updates, requiring expert review anyway—the same burden as before.
Markdown Madness: Tools generate excessive documentation with verbose, error-prone design phases. Fowler turned a simple bug fix with Kiro into 16 acceptance criteria. “Using a sledgehammer to crack a nut,” he called it. Indeed, “I’d rather review code than all these markdown files.”
False Security: Agents don’t always follow specifications. Fowler observed “persistent non-determinism even with highly specific specifications.” You write detailed specs, the AI ignores half of them. Ultimately, you’re back to reviewing implementation anyway.
Diminishing Returns: The approach breaks down on large, existing codebases—precisely where you’d expect rigorous specifications to help most.
The fundamental issue, Zaninotto argues, is that spec-driven development assumes “documentation eliminates uncertainty.” But software development is “fundamentally a non-deterministic process.” Reality changes. Assumptions prove false. Natural language specs remain inherently ambiguous. AI can’t overcome that.
The Optimists’ Defense
To be fair, spec-driven proponents argue it’s different this time.
AI can adapt specs faster than Waterfall-era humans could. Specs are lightweight markdown files, not heavyweight UML diagrams. Meanwhile, the tools support iteration and checkpointing. GitHub emphasizes specs as “living artifacts” that evolve, not static documents locking you into early decisions.
And vibe coding genuinely failed. Large teams do need alignment. AI agents do need some structure. Indeed, compliance-heavy industries require governance. Spec-driven development solves real problems—prompting chaos at scale, misaligned implementations, lack of stakeholder visibility.
The question isn’t whether spec-driven development solves problems. It does. Rather, the question is whether it creates worse problems in the process.
The Pendulum Problem
This isn’t the first time the industry has swung from one extreme to another.
Waterfall was too rigid, so we embraced Agile. Agile sometimes felt too loose, so vibe coding removed all structure. Then, vibe coding created chaos, so we’re back to comprehensive specifications. Each generation believes “this time it’s different.” Subsequently, each generation rediscovers the same tradeoffs.
Too much planning makes you inflexible. Too little planning makes you chaotic. Therefore, the missing conversation isn’t “vibe or spec”—it’s “how much specification is enough?”
Kiro generates 16 acceptance criteria for bug fixes. That’s excessive. However, zero structure for a large team project is reckless. Where’s the line?
The industry keeps presenting false binaries: Waterfall or Agile. Vibe or Spec. Chaos or Bureaucracy. Meanwhile, developers just want common sense: some structure for complex problems, minimal overhead for simple ones. Right-sizing matters more than methodology religion.
Developer sentiment reflects this exhaustion. Some feel relieved by structure after vibe coding chaos. Others feel wary—”this feels like Waterfall again.” Indeed, many express tool fatigue: “Another methodology, another failed promise?”
What Developers Should Do
Test spec-driven tools carefully before committing. AWS, GitHub, and Microsoft are betting billions on this approach, which creates momentum but doesn’t guarantee correctness. Nevertheless, history teaches that Big Design Up Front failed for fundamental reasons—ambiguous requirements, changing reality, false assumptions. AI doesn’t automatically solve those problems.
Remember the Agile Manifesto’s wisdom: “Responding to change over following a plan.” Spec-driven development works against that principle. If your work involves rapidly changing requirements, exploratory prototyping, or novel algorithms, rigid specifications may create more friction than value.
Use common sense over hype. Specs probably help for large team projects requiring alignment and governance. However, they probably hurt for small bug fixes and experimental work. Match your process to your problem size, not to industry trends.
And stay skeptical of pendulum swings. We abandoned Waterfall for good reasons. We shouldn’t resurrect it just because we slapped “AI” on the label.
