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

Source
spec-driven-developmentai-codingkirospec-kittesslcode-generationdeveloper-toolsmodel-driven-development

Summary

Thoughtworks’ Birgitta Böckeler evaluates three spec-driven development (SDD) tools — Kiro, spec-kit (GitHub), and Tessl — and finds that while the general principle of writing a structured spec before AI-assisted coding is valuable, the current tooling creates excessive review overhead, a false sense of control, and doesn’t scale well across different problem sizes. The article draws a sharp parallel between SDD’s “spec-as-source” ambition and the historical failure of model-driven development (MDD), warning that LLM non-determinism may compound rather than solve MDD’s original rigidity problems.

Key Insight

  • Three levels of SDD exist and shouldn’t be conflated: spec-first (write a spec, use it for one task), spec-anchored (maintain the spec as a living document for feature evolution), and spec-as-source (spec is the primary artifact, humans never edit generated code). Most tools claim the higher levels but actually only deliver spec-first.
  • Problem size mismatch is critical. Kiro turned a small bug fix into 4 user stories with 16 acceptance criteria. Spec-kit generated so many markdown files for a mid-sized feature that the author never finished the implementation — and estimated plain AI-assisted coding would have been faster and more controlled.
  • Review burden shifts, doesn’t decrease. SDD replaces code review with spec/artifact review, but the generated specs are verbose, repetitive, and sometimes already contain code. The author states plainly: “I’d rather review code than all these markdown files.”
  • False sense of control. Despite elaborate prompts, checklists, and constitution files, agents still ignored instructions (recreating existing classes from research notes) or overshot them (over-applying constitution rules). Larger context windows don’t guarantee compliance.
  • MDD parallel is the key historical lesson. Model-driven development failed for business apps because it sat at an awkward abstraction level. LLMs remove some MDD constraints (no rigid DSL, no custom code generators) but add non-determinism. Spec-as-source risks combining the worst of both: inflexibility AND non-determinism.
  • Tool comparison: Kiro = lightest (3 markdown files, VS Code-based), spec-kit = most customizable but heaviest (many files per spec, CLI-driven), Tessl = most ambitious (1:1 spec-to-code mapping, // GENERATED FROM SPEC - DO NOT EDIT markers, still in beta).
  • The term “SDD” is already semantically diffused — some people use “spec” as a synonym for “detailed prompt,” diluting its meaning before the practice is even established.