Spec-driven development

Spec-driven development means treating a written specification as the source of truth: define the intended behavior first, then implement and validate the code against it.

I find the principle intuitive and exciting, but it has the same problem we've always had with documentation: drift.

No matter how firmly you prompt them, you should expect agents to let the spec and implementation diverge. This is a problem throughout agentic development, especially with tools that document and comment your codebase to death.

Spec drift is more dangerous with agents than with humans because agents will reintroduce old code when it's still described in the documentation. The outdated behavior has been enshrined as the source of truth.

You implement feature A, then modify it. If you fail to update the spec, an agent may later regress the feature by faithfully restoring the original behavior. The documentation intended to preserve progress instead undoes it.

In some ways, spec-driven development has a better chance of avoiding this problem because it makes the specification a first-class part of the workflow. But it also raises the stakes. The more authority you give the spec, the more damage it can do when it's wrong.

So what's the answer? I don't know.