Understanding Spec-Driven-Development: Kiro, Spec-Kit, and Tessl (martinfowler.com)

Thoughtworks’ exploration of “spec-driven development” (SDD) unpacks a rising pattern in AI-assisted coding: write structured, behavior-oriented specs first and let AI agents generate or modify code from them. The author tested three SDD tools—Kiro, GitHub’s spec-kit, and the Tessl framework—to surface what “spec” means in practice and to map out three implementation levels: spec-first (write a spec before code), spec-anchored (keep specs as living artifacts during maintenance), and spec-as-source (specs become the primary editable artifact). This matters for the AI/ML community because SDD reframes developer-AI interaction: specs act as the “memory bank” or constitution that constrains generation, improves repeatability, and shifts verification burden onto humans and workflows rather than raw prompt tinkering. Technically the tools differ. Kiro is lightweight and opinionated (Requirements → Design → Tasks in markdown, plus a “steering” memory with product.md/structure.md/tech.md). Spec-kit is a CLI-driven workspace scaffold that treats a constitution as an immutable rules file, instantiates many spec-related files and checklists, and even creates branches per spec—leaning toward spec-first/spec-lifetime-per-change. Tessl (private beta) explicitly experiments with spec-anchored and spec-as-source: a CLI/MCP server maps specs to code (1:1 today) and emits // GENERATED FROM SPEC markers; tags like @generate/@test guide outputs, but nondeterminism remains and iteration on spec precision is necessary. Across all three, evaluation is time-consuming, brownfield integration is tricky, and workflows can feel over-engineered for small fixes—highlighting trade-offs between automation, governance, and the human verification needed for reliable AI-driven development.