跪拜 Guibai
← All articles
AI Programming · LLM · Coding Standards

Spec-Driven Development Is a Document Expansion Movement, Not a New Paradigm

By 桦说编程 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Teams adopting AI coding agents are being sold SDD as the disciplined path forward, but the workflow introduces governance costs that most projects cannot sustain and a documentation layer whose errors are harder to detect than buggy code. The risk is not just wasted effort — it's institutionalizing context decay under the brand of a source of truth.

Summary

SDD packages a reasonable impulse — clarify what to build before an agent starts coding — into a workflow that demands long-term Spec maintenance as a single source of truth. Birgitta Böckeler's analysis splits the practice into three layers: Spec-first (a structured prompt, discardable after the task), Spec-anchored (a living document requiring continuous governance), and Spec-as-source (code becomes a generated artifact from Spec). Most SDD tooling blurs these together, selling the low barrier of Spec-first while promising the grand benefits of Spec-as-source.

The core failure is that natural-language Specs add another knowledge carrier to a codebase that already has PRDs, ADRs, tests, schemas, logs, and Git history. Rather than replacing any of them, a long-term Spec becomes a seventh source that must be kept in sync — and when an AI agent both writes the Spec and writes the code, errors self-reinforce rather than get caught. Legacy projects face the worst of this: reverse-generating a Spec from existing code launders historical accidents into formal requirements.

What actually works is splitting knowledge by lifecycle: short-term task context in planning-with-files, long-term decisions in ADRs, executable constraints in tests and schemas, and product intent in owned requirement systems. SDD's real danger isn't wasted documentation effort — it's the false sense of control that comes from a full directory of Markdown files whose truthfulness no one can verify.

Takeaways
SDD conflates three distinct engineering contracts: Spec-first (a structured, discardable prompt), Spec-anchored (a continuously maintained document), and Spec-as-source (code as a generated artifact from Spec).
Natural-language Specs cannot serve as executable specifications because the path from Spec to code still passes through a probabilistic model; the same Spec can produce different, conflicting implementations.
When an AI agent both writes the Spec and writes the code, errors self-reinforce — a wrong first-round understanding gets locked into the Spec and treated as high-priority instruction in subsequent rounds.
Legacy projects face a specific hazard: reverse-generating a Spec from existing code cannot distinguish business rules from bugs, temporary compatibilities, or dead branches, effectively laundering historical accidents into formal requirements.
OpenSpec's delta-first approach reduces entry cost but does not solve authority, coverage, or truthfulness — the main Spec only covers slices touched by recent changes, leaving the rest as unmarked black boxes.
Birgitta Böckeler's hands-on evaluation found that SDD tools expanded small bugs into four user stories and sixteen acceptance criteria, and the time spent reviewing generated Markdown often exceeded the time needed to just implement the fix.
More formal context does not make models more obedient; large context windows increase input volume without improving the truthfulness of each piece of information or guaranteeing correct conflict resolution.
What deserves long-term maintenance is not a unified Spec but a small set of high-value facts split by lifecycle: task context in planning files, long-term decisions in ADRs, executable constraints in tests and schemas, product intent in owned requirement systems.
Conclusions

The article's central framing — that SDD substitutes 'write clearly' with 'write completely' — identifies a category error that most SDD advocacy papers avoid: clarity and completeness are orthogonal properties, and AI tools reward the latter while governance requires the former.

Böckeler's three-layer taxonomy (Spec-first, Spec-anchored, Spec-as-source) exposes that SDD marketing performs a bait-and-switch: the low-friction entry point and the promised end state are fundamentally different engineering regimes with different cost profiles.

The observation that natural-language Specs are 're-interpretable specifications' rather than executable ones is a precise technical objection that cuts through the industry's loose use of 'executable' to describe any Markdown file an agent reads.

The warning about legacy projects — that reverse-generated Specs perform 'cognitive whitewashing' by renaming historical accidents as formal requirements — names a failure mode that is both common and almost invisible until a downstream system breaks.

The recommendation to split knowledge by lifecycle rather than centralize it in a unified Spec is not a compromise position; it's a direct rejection of the premise that a single artifact class can serve humans, models, and automated tooling simultaneously.

Concepts & terms
Spec-Driven Development (SDD)
An AI-coding workflow where requirements, constraints, and acceptance criteria are written into a Spec document before a Coding Agent plans, implements, and verifies code. Current tools include GitHub spec-kit, AWS Kiro, and OpenSpec.
Vibe Coding
An informal AI-coding style where developers type short, conversational prompts directly into a chat interface and let the model generate or modify code immediately, without structured requirements or formal verification steps.
Context Decay (or Context Corruption)
A failure mode in AI-assisted development where incorrect information gains authority through repeated citation across conversation turns or documents, causing the model to generate increasingly complete but wrong implementations on a false premise.
Planning-with-files
A lightweight alternative to SDD that uses task-scoped files (task_plan.md, findings.md, progress.md) to give a Coding Agent working memory and long-task recovery without claiming to represent permanent system truth.
ADR (Architecture Decision Record)
A lightweight document capturing an important architectural decision, its context, the options considered, and the rationale for the chosen option. Recommended as the correct home for long-term technical decisions rather than embedding them in a unified Spec.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗