What Spec-Driven Development gets right (and wrong) about AI coding

During my daily tech reading this morning, I came across the excellent article by Birgitta Boeckeler on Martin Fowler 's blog titled "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl" that immediately caught my attention and I was intrigued by what this could mean for software engineering practices and culture. Here was someone examining what appeared to be a more mature, production-ready approach to AI-assisted coding—moving beyond what many of us have been doing: the chaotic, hit-or-miss world of "vibe coding."

The article's deep dive into three distinct SDD tools sparked relevant questions: Are we finally finding a systematic way to harness AI for serious software engineering? Or are we repeating past mistakes with shinier tools?

The promise: Moving beyond "Vibe Coding"

We've all experienced it. You describe what you want to an AI coding assistant, get back a block of code that looks right, but doesn't quite work. This "vibe coding" approach—essentially throwing prompts at AI and hoping for the best—has become the default for many developers exploring AI-assisted development. It's fast, it's exciting, but it's fundamentally unreliable for most of production systems.

Spec-Driven Development emerges as a proposed solution: write detailed specifications first, then let AI agents generate code based on those specs.

The specification becomes your source of truth, a North Star guiding both human developers and AI agents throughout the development lifecycle.

What Is SDD, really?

After reading the Bigitta's examination of three major tools claiming to implement SDD—Kiro, GitHub's spec-kit, and Tessl Framework—one thing emerged to my mind: SDD isn't just one thing. It exists on a spectrum with three distinct levels:

• Spec-first: A well-crafted specification is written before development begins, used to guide AI-assisted work on a specific task.
• Spec-anchored: The specification persists after the task completes, serving as living documentation for feature evolution and maintenance.
• Spec-as-source: The specification becomes the primary artifact. Developers edit only the spec; AI generates all code. Think of it as "the code you never touch."

The variation across these approaches is significant. Different tools target different points on this spectrum, creating some confusion about what SDD actually promises to deliver.

The tools landscape: A rapidly evolving ecosystem

Few months before end of 2025, the SDD movement is gaining serious momentum. GitHub 's open-source spec-kit, released in September, now supports multiple AI coding assistants including GitHub Copilot, Claude Code, Gemini CLI, Cursor, Windsurf, and others. Amazon Web Services (AWS) on launched Kiro, a VS Code-based IDE with built-in spec mode. Tessl Framework is exploring the ambitious spec-as-source vision, even marking generated code with "DO NOT EDIT" warnings.

But this is just the beginning. The broader ecosystem shows similar patterns emerging:

• Cursor's Plan Mode auto-generates implementation plans before executing code changes
• Amazon Q Developer emphasizes specification-first workflows in its CLI
• Claude Code and Gemini CLI incorporate planning phases as core features
• OpenAI's next-generation Codex emphasizes structured engineering tasks

The pattern is unmistakable: major players are converging on "intent → spec → plan → execution" as the preferred workflow for AI-assisted development.

Native vs. Bolt-On: The implementation divide

However, it looks that not all tools are embracing SDD equally. A significant divide is emerging between platforms that treat SDD as a first-class citizen versus those adopting it as an afterthought.

GitHub Copilot has gone all-in. As the creator of spec-kit, GitHub has native integration with slash commands like /specify, /plan, and /tasks built directly into Copilot. This isn't a future roadmap item—it's a core feature available now and being actively promoted as the future of AI-assisted development.

Kiro was designed from the ground up for SDD. Its VS Code-based environment has specifications baked into the IDE experience, making it arguably the most committed to pure SDD workflows.

Cursor and Windsurf, however, tell a different story. Neither of them treats SDD as a native, first-class feature. Although developers can use the spec kit with these tools via community integrations and workarounds, the experience feels 'bolted on' rather than built in. Users must manually manage specifications and lose the formal verification workflows that native implementations provide.

Cursor has its Plan Mode, which generates implementation plans before execution—philosophically similar but technically different from formal SDD. Windsurf emphasizes its "Cascade" agent and "AI Flows" for contextual coding, along with a "Memories" system for persistent context, but this isn't the same as maintaining formal specifications.

The question becomes: Will Cursor and Windsurf eventually adopt native SDD support, or are they betting on alternative approaches to the same problem?

This fragmentation isn't just about tools—it reflects a deeper uncertainty about how we build software in the age of AI. Underneath the debate about SDD implementation lies a more fundamental question: can a specification-first mindset truly coexist with the iterative spirit of modern software development?

Is there an elephant in the room: SDD vs. Agile

Here's where things get a bit uncomfortable. SDD's emphasis on upfront specifications appears to contradict one of software development's most fundamental shifts of the past two decades: Agile methodology.

Agile taught us to embrace change, to work iteratively, to value working software over comprehensive documentation. We learned the hard way that extensive upfront planning often leads to waste when requirements inevitably shift. So why are we now advocating for detailed specifications before writing a single line of code?

Ouf, the tension is a bit overstated.

Modern SDD proponents argue that specifications can be iterative too. GitHub's spec-kit explicitly promotes updating specs and regenerating implementations as a lightweight change process. The specifications aren't waterfall-style requirements documents locked away in a drawer—they're living artifacts that evolve with your understanding.

However, questions remain:

• How do we balance specification detail with the need for rapid iteration?
• At what problem size does SDD provide value versus creating overhead?
• Can specifications truly remain in sync with evolving codebases, or will they become yet another form of documentation that drifts out of date?

The uncomfortable parallels: Have we seen this before?

For those with longer memories, SDD might trigger an uncomfortable sense of déjà vu. In the early 2000s, Model-Driven Development (MDD) promised similar benefits: write high-level models (specifications), generate code automatically, focus on intent rather than implementation.

MDD largely failed for business applications. It sat at an awkward abstraction level, created overhead, and imposed constraints that limited flexibility. Yet LLMs remove some of MDD's key obstacles—we no longer need parseable DSLs or custom code generators. Natural language specifications can drive code generation directly.

But we're also losing MDD's upsides: the tool support, validation, and consistency that came with structured, machine-readable specifications. Are we getting the downsides of both worlds—MDD's inflexibility combined with LLM's non-determinism?

So, there are some questions we should be asking about SDD

1. Are we optimizing for the wrong thing? Current SDD tools generate extensive markdown files for review. Multiple documents, verbose descriptions, repetitive content. Ironically, it's often easier to review actual code than to wade through walls of specification text.

2. Do the workflows fit real problem sizes? Using elaborate SDD processes for small bug fixes feels like using a sledgehammer to crack a nut. But even for mid-sized features, the workflow overhead can be substantial. What problem sizes actually benefit from SDD?

3. Does this create a false sense of control? Despite detailed specs, elaborate templates, and explicit checklists, AI agents still frequently ignore instructions or misinterpret context. Large context windows don't guarantee AI will properly utilize everything in them.

4. Who is SDD really for? Many SDD tutorials include product-level concerns like defining feature goals and user stories. Are we expecting developers to do product work? Or should product managers learn SDD tools? The target user remains unclear.

The path forward: pragmatism over dogma

SDD is neither a silver bullet nor a useless fad. The principle of "spec-first"—carefully crafting specifications before asking AI to generate code—has clear value in many situations. Practitioners consistently ask for guidance on structuring specifications and memory banks for AI agents.

But the term is already experiencing semantic diffusion. I've heard people use "spec" as simply a synonym for "detailed prompt." Without clearer definitions and proven patterns, SDD risks becoming another buzzword that means everything and nothing.

After reading the initial article from Birgitta and diving on some related connections, the pragmatic approach seems wisest:

1. Embrace spec-first thinking for complex, production-critical work
2. Keep specifications as lightweight as possible while maintaining clarity
3. Stay iterative—small, reviewable changes over elaborate upfront design
4. Recognize that specifications are tools, not religion
5. Learn from both the successes and failures of past "specification-driven" movements
6. Remain skeptical of tools that promise to solve all problems with one workflow

The AI coding revolution is real. But revolution doesn't mean abandoning everything we've learned about software engineering. It means applying those hard-won lessons with new tools, remaining critical even as we explore enthusiastically.

Spec-Driven Development might be part of that future. But only if we approach it with eyes wide open, learning from history rather than repeating it.

What's your experience with AI-assisted coding? Are you seeing value in structured specification approaches like SDD, or are they creating more overhead than benefit? Happy to read your thoughts in the comments!

#SpecDrivenDevelopment #AICoding #SoftwareEngineering #AgileMethodology #DeveloperProductivity