It’s everywhere. It’s the new hotness. If you’re not doing SDD are you even vibing dude?

I first came across the idea from a software library with no code which describes a time conversion library as a markdown spec + test suite, in sufficient detail to allow a coding agent to implement it.

My initial thought was that this seemed a cool idea, but not something that would scale.

Next I came across Software Factories And The Agentic Moment via Simon Willison’s commentary How StrongDM’s AI team build serious software without even looking at the code. StrongDM released Attractor, their coding agent, by only open sourcing the spec. The intent is that you just get Claude Code/whatever to do the actual implementation

  codeagent> Implement Attractor as described by https://factory.strongdm.ai/

And there’s now many more examples including Cloudflare re-writing NextJS from the tests + spec + docs and OpenAI writing about Harness engineering: leveraging Codex in an agent-first world.

Does it work? Sort of. Maybe. It depends. e.g. the NextJS port worked but wasn’t complete and nothing talks about how to maintain the codebase long term. Which is understandable as it’s all so new.

To me, it’s amazing that this process works as well as it does when we’re using models with a ~200k-1m context window and degradation in performance around the 50% mark. That harnesses and tooling can get them to produce these large systems feels like a sign of where we’re going.

The three types of spec-driven development

Then today I came across a really thoughtful article by Thoughtworks distinguished engineer Birgitta Böckeler. She gets to the heart of how people are using the same terminology to mean radically different things and defines three different possible meanings for SDD:

  1. Spec-first: A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.
  2. Spec-anchored: The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.
  3. Spec-as-source: The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.

All ‘spec-driven’ approaches are spec-first, but not all are spec-anchored or spec as source. This then shows up in discussions about how specs should be managed after the initial build e.g. in the GitHub spec-kit repo

It’s even worse than that. Birgitta points out that even the definition of what a spec is is unclear. What level of detail should it have? Who manages it?

The tl;dr is that it’s all rapidly evolving and the tooling is outpacing the terminology, but the method of having the agent write code based on specs seems like it’s here to stay.

Appendix - tooling options

If you want to play with SDD, there’s a lot of options:

Pattern 1 is implemented by multiple tools: I use superpowers in Claude Code, Github has spec-kit and SDD is even directly implemented in some coding agents like AWS Kiro. There are multiple options - pick one and play. Just doing this has given me massive wins over less-structured coding agent use.

Pattern 2 is newer. I’m using lat.md which has bi-directional links between spec and code and hooks to keep everything in sync. But I’ve also only been using it for a week. We’ll see!

Pattern 3 is the full dark factory pattern. I can’t comment on what works here.