Spec-driven development

Spec-driven development means the specification is the durable artefact and the code is downstream of it. Not a document written to satisfy a process — a document precise enough that a competent engineer, or a competent agent, could implement from it and arrive somewhere you would recognise.

This is not new as an idea. What is new is the economics. Writing the code used to be the expensive part, so specifications were a tax you paid to avoid rework. Now the code is cheap and the thinking is not. A prompt produces a branch; it does not produce agreement about what should exist. The agreement is the scarce thing, and it needs somewhere to live that is not a chat log.

The practical shape most teams land on is two documents and a gate between them: requirements, which answer what and why, and an implementation plan, which answers how. The gate matters more than the documents. A specification nobody has to approve is a suggestion.

The current wave has a short and traceable history. Kiro shipped the three-document shape — requirements, design, tasks — as files beside your code. GitHub's Spec Kit turned the same loop into an open toolkit, with a constitution constraining what the agent is allowed to decide for itself. Both made the same bet: that the artefact the agent needs and the artefact the team needs are the same artefact.

Separately, the Model Context Protocol solved the other half. An agent that can only read a chat window has to be told the state of the world every time. An agent speaking MCP can read the spec, the review notes and the code, and write back into them. That is the difference between an assistant you brief and a colleague who checks.

What none of that settles is who is accountable. A toolkit can generate a plan; it cannot record that a named human read it and stood behind it. That gap is where RelayWork sits.

Give an agent write access to your specs and two things happen. The good one: drafts stop being the bottleneck, because a first pass at requirements takes a minute instead of an afternoon. The bad one: volume. Nobody reads 1,400 words of generated implementation plan carefully, and a spec nobody reads carefully is worse than no spec — it launders a decision nobody made.

So the constraints matter more than the capability. Enforce length limits on the documents. Reject paragraph-long bullets. Make the agent cite the code it is talking about. And keep approval strictly human — not permission-gated, but absent from the tool surface entirely, so there is no configuration mistake that lets a machine sign off its own work.

Most writing about this assumes a team, which misses the half of the value that matters most to one person working with agents: durable memory. A model has no recollection of yesterday's reasoning. An approved spec with code refs pinned to commits is exactly the context it needs to pick the work back up — and it is what stops you re-litigating a decision with your own agent next week.

Approving your own spec is not theatre. It is the moment you stop and read what you asked for before something builds it, and the version binding still catches the case where you changed the plan mid-flight and forgot. Bugs and chores skip all of it — they are tasks with no documents and no gates, because ceremony belongs only where being wrong is expensive.

The shape scales without being redesigned. When the second and third engineer arrive, the specs they need in order to be useful already exist; the approver simply stops being you.