Spec-driven development: what it is, how I use it, and why now

Writing code has never been faster: AI produces whole screens in seconds. The bottleneck has moved — it’s no longer in writing the code, but in the decision. Spec-driven development (SDD) is an answer to this (r)evolution.

What spec-driven development is

SDD comes down to one inversion: the specification first, the code second. Not an eighty-page frozen requirements document — a short, living spec, versioned alongside the code. It states the intent (the why), the constraints (what is non-negotiable) and the tasks (the how, broken down). The code becomes a derivative of the spec, not the other way around.

Not against agile — a lighter take

SDD doesn’t throw agility out; it keeps its essence and strips the ceremony:

• The backlog still exists, but ultra-simplified: here, a plain ideas document that keeps the big milestones and epics — not a management tool, a list you draw from.
• You still work in short iterations — often shorter than before.
• You still ship one or more deliverables at every increment.

What changes is that the spec replaces the heavy rituals. And because each increment is small and specified, you adapt continuously: to the reality on the ground, to a change of direction, to a market shift. The spec isn’t rigidity — it’s what makes changing course cheap.

How I work, concretely

A cycle, for me, is five beats:

1. I pick a topic — often drawn from that simplified backlog.
2. I explore — with AI agents: dig into the topic, consolidate the leads, break it into smaller increments, surface the trade-offs and the blind spots.
3. I propose — I consolidate the exploration into artifacts (proposal, design, tasks): the what, the how, the steps.
4. I apply — the AI agents move to implementation, but framed by the constraints and the design of the artifacts: that’s what prevents drift.
5. I archive — once the change is validated, the spec joins the source of truth and the code merges into the trunk.

A task looks like this — a real excerpt from one of my changes (the conversation thread of a ticketing tool), readable by a human and by the AI alike:

## Ticket conversation thread

- [x] The customer reads the ticket, but never the team’s internal notes
- [x] An internal user outside the customer’s scope cannot add a note
- [x] Two-tab composer “Comment / Internal note” — note tab hidden on the customer side
- [x] The thread interleaves comments and notes by time; customer side, comments only
- [~] “Updated by …”: a comment bumps the ticket, an internal note doesn’t

Every checked box is a traced decision. Six months later, you know why the product behaves as it does — without having to do any archaeology.

Why it matters — especially now

AI changes the equation, and SDD comes out stronger:

• AI accelerates, the spec steers. A model generates fast but settles neither the architecture nor the security. The spec is the frame it generates within — speed, under control.
• The spec outlives the models. The best models change every six months; the spec lasts. You switch from one to the next without rewriting the product — the asset is the spec.
• Traceability becomes vital. When a machine produces a lot of code, knowing why each decision was made — written, reviewed, versioned — is no longer a luxury: it’s what keeps the product auditable.

Spec first isn’t slowing down for show. It’s moving decisions to where they’re still reversible — and giving the AI a frame where it accelerates without breaking anything.