Spec Kit, GitHub's kit for working with Spec-Driven Development (SDD), development guided by specifications, is open source, MIT-licensed and, on 15 October 2026, had around 141,300 stars on GitHub. It brings the full workflow: a constitution with the project's principles, the specification, the plan, the tasks and the implementation.
That is good news for any development team, and it has a consequence worth saying out loud: if the template is free and anyone can install it, the template is no longer what sets one team apart from another.
Hence the thesis of this piece: what decides whether a team delivers differently with SDD is what the template does not include. When the full specification is used, how long it can be for someone to read it, what proves the agent followed it and who maintains the project's rules. That cannot be downloaded: it has to be decided.
What the template includes, and what it does not
What SDD is and how it differs from prompt-driven coding is explained in Spec-Driven Development: AI code under control. The essentials are enough here: before the agent writes code, you write what has to be built, why, and against which criteria it will count as done. Spec Kit turns that principle into commands run from the agent's chat, and most SDD tools follow a similar scheme.
What no template can include is the team's context: how big its changes are, how much review time it has, which risks it takes on and who answers for each decision. A template is made to serve anyone, and that is why it knows nothing about anyone.
What those who have tried it report
The most useful account of these tools comes from someone who used them carefully. In October 2025, Birgitta Böckeler, of Thoughtworks, tried Kiro, Spec Kit and Tessl and published what she saw on martinfowler.com. Three observations matter here:
- Size. She asked Kiro to fix a small bug and the workflow was, in her words, "like using a sledgehammer to crack a nut": four user stories with sixteen acceptance criteria. She concludes that a good tool would need to offer different workflows for changes of different sizes and types.
- Review. Spec Kit generated a lot of markdown files for her to review, repetitive and tedious. In her view, an effective SDD tool would have to provide a very good spec review experience.
- Compliance. Despite the files, templates and checklists, she frequently saw the agent ultimately not follow all the instructions.
And still she does not dismiss the idea: she writes that the general principle of spec-first is definitely valuable in many situations. The Thoughtworks Technology Radar said something similar in November 2025, when it placed spec-driven development in the "Assess" ring: the workflows "remain elaborate and opinionated", and some tools "generate lengthy spec files that are hard to review". That entry is no longer in the current edition of the Radar.
None of these criticisms says specifying is unnecessary. They say the tool does not decide for the team when to specify, how much or how to check it.
Four decisions the template does not include
Each of the criticisms above corresponds to a decision the team has to make before the template is of any use:
| Decision | What the template includes | What the team has to decide |
|---|---|---|
| When there is a full specification | A workflow designed for any change | A threshold by size and risk: below it, a short lane; above it, the whole workflow |
| How long it can be | Whatever documents the agent generates | A reading limit: what one person reviews carefully in one sitting. If it is not read, it is not approved |
| What proves it was met | Instructions for the agent | Acceptance criteria that become tests and decide whether the change goes in |
| Who maintains the project's rules | A file of principles (the constitution) | A named person who answers for those rules, and changes approved separately |
onext's own elaboration based on Birgitta Böckeler's observations and the Thoughtworks Technology Radar
The last two rows have their own piece. How an acceptance criterion becomes the merge gate is in your spec is already an eval, and what each person signs off in the cycle, in specs and agents: where you sign off. How SDD relates to writing tests before code, Test-Driven Development (TDD), is covered in SDD, TDD and BDD: what each adds.
The first two are the ones most often skipped, because they do not look like technical decisions. They are. Without a threshold, the team either specifies everything or soon stops specifying, tired of filling in documents for ten-line changes. Without a reading limit, the specification grows until nobody reads it, and then approval is a signature with no reading behind it. If the code is old, the threshold matters even more: you do not specify the whole system, only the part you are about to touch, as we explain in specifying legacy code before AI agents.
Something similar happens with the constitution. A file of principles that the agent reads does not enforce anything on its own: it guides, but it does not prevent. What has to be enforced goes into controls that apply themselves, as we explain in Claude Code for teams: context is not control.
Risk Installing the template without these four decisions gives the appearance of a method: long documents, approvals nobody exercises and an agent that half follows its instructions, all neatly filed.
The tool amplifies what is already there
DORA, Google's research programme on software teams, reached a conclusion in its 2025 report on AI-assisted development that also applies to SDD: "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses." And the greatest returns on AI investment, according to the same report, do not come from the tools themselves.
Applied to SDD templates: in a team that already knows how to break down work, review with judgement and decide who answers for what, Spec Kit brings order and speed. In a team that does not, it produces more documents without changing how work gets done. That is why it pays to check the safety net that catches errors first, as we explain in before the agent, the safety net, and choose the template afterwards.
The template being free has one advantage: the team can switch tools without losing anything, as long as its method does not depend on the tool. If a better kit appears tomorrow, the four decisions still hold.
Where onext fits
In AI-Accelerated Development we build, with your team, the context the AI works in and the process you work with. Both stay with you. A person decides where there is risk. The first step is a free diagnostic, and if the diagnostic shows no difference, there is no Quick-start.
Frequently asked questions
What is Spec Kit?
It is GitHub's open-source kit for working with Spec-Driven Development (SDD), under the MIT licence. It gives coding agents a structured process: a constitution with the project's principles, the specification, the plan, the tasks and the implementation.
If the template is free, why would anyone else be needed?
To install it, nobody is. What takes effort is what the template does not include: deciding when the full specification is used, how long it can be for someone to read it, what proves the agent followed it and who maintains the project's rules. A team can decide this on its own; what matters is that it decides, not that it buys.
Is SDD useful for fixing a small bug?
With the full workflow, usually not. Birgitta Böckeler, of Thoughtworks, recounts that asking Kiro to fix a small bug was like using a sledgehammer to crack a nut: it produced four user stories with sixteen acceptance criteria. That is why it pays to set a threshold: below it, a short lane; above it, a full specification.
How do you avoid writing specifications nobody reads?
By setting a reading limit: what one person can review carefully in one sitting. If the specification goes beyond it, it is split or trimmed. The Thoughtworks Technology Radar already warned that some tools generate lengthy spec files that are hard to review, and a specification nobody reads is not really approved by anyone either.
Does the agent always follow the specification?
No. Böckeler writes that, despite all the files, templates and checklists, she frequently saw the agent ultimately not follow all the instructions. That is why the specification has to carry acceptance criteria that can be checked with tests, not just instructions for the agent.
Which tool should you choose: Spec Kit, Kiro or Tessl?
Method first, tool second. All three start from a specification before the code and differ in their workflow and in how much they keep the specification afterwards. If the team has settled the threshold, the reading limit, the check and who decides, changing tools does not change the way it works.
Sources
- GitHub, "Spec Kit", repository (no visible date; accessed 15 October 2026, around 141,300 stars that day).
- Birgitta Böckeler (Thoughtworks), "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl", martinfowler.com, 15 October 2025.
- Thoughtworks, "Spec-driven development", Technology Radar, Assess ring, 5 November 2025 (not in the current edition).
- DORA, "State of AI-assisted Software Development 2025" (2025; no exact date visible).
- The table of the four decisions and its reading are onext's own elaboration.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →