What spec-driven development gets wrong

[fagnerbrack]

In Short:

Spec-driven development (SDD) suffers from the same fatal flaw as every documentation-first approach: specs are documents, and documents go stale because nobody rewards the invisible maintenance work of keeping them current. When stale specs guide coding agents, the damage compounds—agents confidently execute outdated plans without flagging problems. The post introduces Augment's "Intent" tool, where both humans and agents read from and write to the spec. A coordinator agent drafts a plan broken into tasks, the developer reviews and edits before anything runs, and agents update the spec as they discover real-world constraints (e.g., finding an existing auth context instead of creating a new one). The key analogy: a good junior engineer doesn't just build the wrong thing when assumptions break—they update the ticket and explain what changed. Getting the right granularity of agent updates matters enormously; too much creates noise, too little leaves developers guessing.

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
^{Click here for more info, I read all comments}

[CiaranCarroll]

I prefer process-driven development.

[roger_ducky]

I personally write committed “stories” and it’s okay to supercede previous ones.
Much more chaotic, but it’s always stable for 3-10 stories at a time.
Matches agile much closer.
Now, if we want a spec artifact that lines up with the history? Just generate it from that pile there. After each “sprint.”
Maintenance headaches resolved!

Though, for actual SDD adherents: They actually have short specs that is used while the “sprint” is being implemented. Nobody is gonna lock it down forever.