Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Birgitta Böckeler works through three spec-driven tools and, more usefully, separates three things the term is being used for: spec-first, where you write a spec and then develop from it; spec-anchored, where the spec is maintained afterwards; and spec-as-source, where the spec is the artifact and humans never edit the generated code.

Against that, Kiro is the lightest, running requirements to design to tasks inside VS Code, though she found it verbose enough to turn a small bug into 16 acceptance criteria. GitHub’s spec-kit produces extensive markdown across multiple files and, despite the ambition, its branch-per-spec shape keeps it spec-first. Only Tessl really attempts spec-anchored and spec-as-source, generating files marked “GENERATED FROM SPEC - DO NOT EDIT”.

Her scepticism is the part worth keeping. She would rather review code than verbose markdown, and questions whether long specs give real control or just the feeling of it, noting that agents variously ignored instructions or followed them too literally. The warning underneath is that spec-as-source risks repeating model-driven development’s failure, combining inflexibility with non-determinism. Compare Huzzah, which arrives at a similar place from the informal end.