Spec-Driven Development Assess
Overview
Spec-driven development uses machine-readable specs, plans, and tasks (for example GitHub spec-kit) as the source of truth agents and humans implement against (spec-kit). The main tools differ in how far they go: Kiro guides a requirements, design, and tasks sequence; spec-kit adds a project "constitution" and configurable steps; Tessl aims for spec-as-source, where humans edit only the spec (martinfowler.com).
Assess when agent workflows need explicit requirements before code. Specs must be reviewed and versioned like APIs, or agents will implement the wrong problem precisely.
Adoption Signals
- GitHub spec-kit had more than 139,000 stars and 12,500 forks on 30 September 2026, is MIT-licensed, and released v1.0.0 on 21 August 2026, with v1.0.13 following on 29 September 2026 (GitHub spec-kit, v1.0.0 release).
- AWS made Kiro generally available on 17 November 2025 with property-based testing against specs, checkpointing, a CLI, and team management through AWS IAM Identity Center (Kiro GA).
- Thoughtworks Technology Radar Vol. 34 (November 2025) placed spec-driven development in Assess (Thoughtworks).
- Böckeler's October 2025 comparison of Kiro, spec-kit, and Tessl introduced the spec-first, spec-anchored, and spec-as-source distinction now used to discuss the practice (martinfowler.com).
- AGENTS.md gives agents a shared, tool-neutral place for persistent project instructions that spec workflows can build on (AGENTS.md).
Risks
- Review load moves, it does not shrink. Generated specs, plans, and task lists can be long, repetitive, and tedious to review (martinfowler.com, Thoughtworks); unreviewed specs give a false sign-off.
- Specs are not enforcement. Agents still skip instructions (martinfowler.com); only executable checks such as tests hold the implementation to the spec.
- One workflow for every task size. Thoughtworks notes the tools behave very differently by task size and type and that it is sometimes unclear who generated PRDs and user stories are for (Thoughtworks); running the full process on small fixes wastes time.
- Spec drift. In spec-first use the spec serves only the task at hand and is not maintained afterwards (martinfowler.com); if stale specs remain in the repository, later agent runs treat outdated intent as current.
- Tool-specific structures. Kiro, spec-kit, and Tessl organise specs differently, so switching tools means reshaping the spec corpus.
Pros & Cons
Advantages
- Requirements, design, and a task breakdown are written and reviewed before the agent writes code, which makes intent inspectable on larger features; Kiro adds property-based tests that check the code against the behaviour defined in the spec.
- Tooling matured in 2026: GitHub spec-kit reached v1.0.0 in August 2026 under the MIT licence and runs as agent skills across several coding agents rather than locking teams into one vendor.
- Specs kept as versioned files in the repository give reviewers and auditors a traceable link from requirement to change, which suits delivery in regulated environments.
Disadvantages
- The workflows generate a lot of text: Birgitta Böckeler found spec-kit produced many repetitive markdown files and concluded she would rather review code.
- Agents do not reliably follow the spec; in the same evaluation the agent ignored notes and created duplicates despite detailed instructions.
- Thoughtworks warns the approach may be "relearning a bitter lesson" that handcrafted rules for AI do not scale, and Böckeler notes that spec-as-source risks combining the inflexibility of model-driven development with LLM non-determinism.
Recommendation
Assess spec-driven development on two or three medium-sized features that span several modules or need stakeholder sign-off, and skip it for bug fixes and small changes. Keep specs short, review them as pull requests like any other change, and pair each spec with executable acceptance or property-based tests, because the tests are what hold the agent to the spec. Record review time and rework against comparable features built without specs.
Regulated teams should look at the spec-anchored variant as a traceability artefact linking requirements to changes. Spec-as-source is not ready for production use. Start with spec-kit if the team already works with several agents, or Kiro if it wants an integrated IDE workflow from AWS.
Sources
Consulting
From radar to implementation
You have assessed the technologies — we help you bring them into production systems safely and measurably.
