跪拜 Guibai
← All articles
Artificial Intelligence · AI Programming · iOS

AI Writes Code Faster Than You Can Think — That's the Problem SDD Fixes

By _瑞 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

AI coding tools compress implementation time so aggressively that the bottleneck shifts entirely to requirement clarity. Without a spec-first workflow, teams burn their time savings on correction loops and lose institutional memory when chat sessions disappear.

Summary

The default AI coding loop — prompt, generate, test, find a gap, re-prompt — wastes time because the code arrives before the requirement is fully understood. Specification-Driven Development (SDD) inverts this: a spec, plan, and task list are locked down first, then AI implements against them. The result is fewer rounds of patching and a written record of decisions that survives session resets and agent swaps.

Three major open-source SDD frameworks — GitHub's Spec Kit, Fission-AI's OpenSpec, and gotalab's cc-sdd — all enforce this discipline but optimize for different pain points. Spec Kit checks completeness and consistency across spec, plan, and tasks. OpenSpec models every feature as a discrete change against a living system spec, preserving a full audit trail. cc-sdd treats specs as module contracts and runs isolated agents per task with TDD and reviewer checks.

SDD does not replace TDD; it answers what to build, while TDD verifies how it was built. A team can adopt SDD with nothing more than a docs/specs folder and five rules about when to start coding. The real shift is treating the spec as the source of truth that outlives any single chat session.

Takeaways
AI-generated code often arrives before edge cases, permission failures, and state transitions are considered, forcing multiple correction rounds.
SDD inserts a spec-plan-tasks phase before implementation so that ambiguities are resolved when only a few paragraphs of text exist, not after code is scattered across modules.
Spec, plan, and task files stored in the repo give future AI agents and developers the context that would otherwise be lost in a closed chat session.
Spec Kit focuses on completeness and consistency, offering optional clarify, checklist, and analyze steps to catch gaps.
OpenSpec treats every requirement as an independent change with ADDED/MODIFIED/REMOVED markers, merging back into a living system spec and archiving the full history.
cc-sdd enforces module boundaries and task dependencies so that multiple agents can implement, review, and debug independently without stepping on each other.
SDD and TDD solve different layers: SDD decides what behaviors are correct, TDD ensures those behaviors are correctly implemented in code.
Adopting SDD requires no special tooling — a docs/specs directory and a rule to confirm the spec before coding is enough for small teams.
Conclusions

The three SDD frameworks converge on the same core loop but diverge on what they optimize: audit-trail integrity (OpenSpec), spec-task consistency (Spec Kit), or multi-agent execution safety (cc-sdd). Choosing one is really choosing which failure mode hurts your team most.

SDD's value is proportional to how many decisions a team currently leaves in chat history. Teams that already write thorough design docs before coding will see marginal gain; teams that prompt-and-pray will see the biggest reduction in rework.

The article's observation that AI 'guesses' when requirements are silent is the central economic argument for SDD: every unstated constraint is a lottery ticket, and the house wins over enough iterations.

Concepts & terms
Specification-Driven Development (SDD)
A workflow where a formal specification, technical plan, and task list are written and confirmed before AI or developers write any code. The spec defines what must happen, including edge cases and acceptance criteria, so implementation proceeds against a fixed target rather than evolving through correction loops.
Test-Driven Development (TDD)
A coding discipline that cycles through writing a failing test (Red), writing minimal code to pass it (Green), and refactoring (Refactor). TDD operates inside the implementation phase of SDD: SDD decides which behaviors are required, and TDD verifies each behavior was built correctly.
Constitution (Spec Kit)
A project-level document in Spec Kit that defines standing rules — architecture, tech stack, quality gates, testing requirements, and dependency policies — that every spec and implementation must respect without re-stating them per feature.
Boundary-First (cc-sdd)
cc-sdd's design philosophy where module boundaries and allowed dependencies are locked in the design phase before tasks are assigned to agents. Each task carries explicit _Boundary and _Depends markers so agents cannot modify code outside their contract.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗