Spec-Driven Dev Tools: Spec Kit vs Kiro vs Tessl

What Spec-Driven Development Actually Is

Spec-driven development inverts the default AI coding loop. Instead of prompting an agent and iterating on whatever it generates, you write a specification first, refine that document until it is unambiguous, and only then let the model implement against it. The canonical pipeline is four stages: spec, plan, tasks, implement.

The value proposition is catching ambiguity early. A vague requirement caught in a paragraph costs a one-line edit. The same ambiguity caught after the agent has generated 2,000 lines costs a discarded pull request. GitHub reports that internal teams using Spec Kit ship features with roughly an order-of-magnitude fewer "regenerate from scratch" cycles than ad-hoc prompting. That is the whole game: move correction left, before generation amplifies the mistake.

This loop has obvious roots in how good engineers already work. The difference is that the spec is now a machine-consumable artifact that drives an agent, not just a Notion doc that rots after kickoff. It also pairs naturally with how you configure those agents in the first place; if you are not already using a shared config layer, our breakdown of AGENTS.md for AI coding agent configuration covers the foundation that SDD tools build on top of.

GitHub Spec Kit: Heavy, Flexible, and Prone to Review Overload

Spec Kit is the most visible tool in this space, and the star count earns it the first look. It is a CLI toolkit that scaffolds the full specify-plan-tasks-implement workflow and then hands execution to whichever agent you prefer. Its defining strength is breadth: it works with 30+ AI coding agents, including Claude Code, GitHub Copilot, Cursor, Gemini CLI, and Codex. You are not locked into an editor or a vendor.

The workflow is opinionated. Each spec typically gets its own branch, and the tool generates a set of artifacts (the spec, a plan, a task list, and supporting files) that live in your repository. The commands map directly to the loop:

# Scaffold a spec-driven project
specify init my-feature

# Generate the specification, then the plan, then tasks
/specify  "Add SSO via SAML with SCIM provisioning"
/plan
/tasks
/implement

In Martin Fowler's teardown of the three flagship tools, Spec Kit is the heaviest of the set: branch-per-spec, many artifacts, and a real risk of review overload. That last phrase is the operative one. Because the tool generates thorough, repetitive markdown for every spec, a reviewer can end up reading hundreds of lines of generated planning prose to approve a change that touches three files. The verbosity that makes Spec Kit rigorous on a large feature makes it exhausting on a small one.

Spec Kit is the right call when you have a multi-person team, work that spans several sessions, and a genuine need for auditable artifacts that survive a handoff. It is the wrong call when one engineer wants to ship a contained change this afternoon. If you are evaluating it as part of a broader tooling decision, our enterprise AI coding agent buyer's guide for 2026 places Spec Kit in the context of the wider agent stack and procurement tradeoffs.

Kiro: Three Files and Stay Out of the Way

Kiro takes the opposite stance. Where Spec Kit maximizes artifacts and agent compatibility, Kiro minimizes both. It is the lightest of the flagship tools, built around three markdown files (requirements, design, and tasks) that live inside its IDE next to your code. There is no branch ceremony and no sprawling artifact tree. You open the editor, the spec sits beside the implementation, and the loop stays tight.

This IDE-centric design is the tradeoff. Kiro's lightness comes partly from the fact that it controls the environment, so the spec, the agent, and the code share one surface. That is great for a solo developer or a small team that has standardized on Kiro, and it is friction if you want to keep Claude Code or Cursor as your primary agent. You are buying simplicity with a degree of lock-in.

Kiro's approach is the closest to how most individual engineers actually think: write down the requirement, sketch the design, list the tasks, build. For a single contributor working a feature end to end, the three-file model carries almost no tax. It is worth noting that even lightweight tools carry operational risk when agents act autonomously; we covered one such case in our analysis of an AI agent production safety incident involving Kiro, which is a useful reminder that "lightweight" does not mean "unsupervised."

Tessl: Spec-as-Source and the "Do Not Edit" Boundary

Tessl is the genuinely different one. Spec Kit and Kiro both treat the spec as scaffolding that produces code you then own and edit. Tessl treats the spec as the source. In Fowler's framing, it is the only spec-as-source tool of the three: you write and maintain the specification, and Tessl generates the implementation files, marking them with a header along the lines of GENERATED FROM SPEC - DO NOT EDIT.

The mental model is closer to a compiler than an assistant. You do not patch the generated output. If the behavior is wrong, you fix the spec and regenerate, the same way you would not hand-edit assembly emitted by a compiler. This is intellectually clean and, for the right kind of well-bounded module, genuinely appealing. It also makes the spec the durable artifact, which sidesteps the "code drifts from documentation" problem that plagues every other approach.

The honest caveat is maturity. Tessl is still in beta as of 2026, and spec-as-source asks a lot of both the tooling and the discipline of the team. The moment someone needs to hand-tune the generated code (for a performance hot path, a tricky integration, an edge case the spec did not anticipate) the "do not edit" boundary becomes a real constraint rather than a guideline. Adopt Tessl where the generated code is a black box you are happy never to open, and be cautious where you expect to live inside the implementation.

BMAD and OpenSpec: Where the Method-Heavy Options Fit

Beyond the three flagship tools, the independent comparison now circulating among teams (the spec-compare project benchmarks six tools head to head: Spec-Kit, Spec Kitty, BMad, OpenSpec, Kiro, and Tessl, with git-worktree analysis and an explicit decision framework) surfaces two more worth naming.

BMAD (the Breakthrough Method for Agile AI-Driven Development) is less a CLI and more a methodology. It layers agent personas onto your workflow: an analyst, a product manager, an architect, a scrum master, each with defined responsibilities in the spec-to-code pipeline. If your organization wants AI development to mirror a full agile process with roles and ceremonies, BMAD gives you that structure. The cost is weight. BMAD is opinionated about process in a way that suits teams who value the ceremony and frustrates teams who just want artifacts.

OpenSpec sits between the lightweight and method-heavy camps, focused on an open, portable spec format rather than a particular agent or IDE. It appeals to teams who want the discipline of written specs without committing to one vendor's workflow.

Here is the practical placement: BMAD and OpenSpec are for teams that have already decided SDD is worth real process investment. They are not where you start. If you are still proving the value of writing specs at all, a method-heavy tool front-loads cost before you have evidence it pays off. The existence of a six-tool head-to-head comparison with worktree analysis tells you something on its own: there is real practitioner confusion here, and the confusion is a signal that most teams are over-buying structure before they understand their own needs.

A Decision Framework: Match Tool Weight to Team and Task

The single most useful lens is weight. Every tool in this space trades simplicity against rigor, and the right answer is whichever sits closest to the actual coordination cost of your work. Below is how the main options line up.

Three rules fall out of this:

This is also where a focused engagement helps. Particula Tech's AI development tooling practice spends a lot of its time on exactly this calibration: auditing how a team actually works, then matching SDD weight to that reality instead of defaulting to the most-starred repo. The most common finding across the agent systems we have reviewed is over-tooling, not under-tooling.

The Shared Verbosity Tax and How to Avoid SDD Overkill

Every current SDD tool shares one complaint: verbosity. Spec Kit draws the loudest criticism because it generates excessive, repetitive markdown that produces review overload and feels like overkill for small tasks, but the pattern is general. The act of formalizing a spec produces text, and text has to be read, reviewed, and maintained by humans whose time is the scarce resource.

The failure mode is mechanical. An engineer adopts an SDD tool, loves it on a real feature, then reflexively applies the full specify-plan-tasks-implement loop to a one-line bug fix. Now there is a branch, a spec, a plan, a task list, and a reviewer reading 300 lines of generated prose to approve a change that should have been a 30-second diff. The tool that saved time on the feature is now a tax on every trivial task, and the team quietly abandons it.

The fix is a triage rule, applied before you reach for any tool:

Use full SDD when ALL are true:
  - the work spans multiple files or multiple sessions
  - more than one person will touch or review it
  - the requirements are genuinely ambiguous and worth arguing about

Skip SDD (just prompt and review the diff) when ANY are true:
  - the change is under a few hundred lines
  - the task is well understood (bug fix, config, single function)
  - writing the spec would take longer than the implementation

The discipline that makes spec-driven development pay off is not writing more specs. It is knowing when not to write one. The order-of-magnitude reduction in regeneration cycles that GitHub reports is real, but it lives entirely in the non-trivial work. Apply the loop there and nowhere else.

A related lever is parallelism. Once you are running structured specs and tasks, you can fan multiple agents across isolated working trees, which is where the spec's task decomposition becomes genuinely powerful. Our walkthrough of the parallel coding agents worktree pattern shows how task-level decomposition (the third stage of the SDD loop) maps cleanly onto parallel execution without agents stepping on each other.

The Bottom Line for 2026

Spec-driven development is a real improvement on ad-hoc prompting for non-trivial work, and the tooling has matured to the point where you have genuine choices rather than one option. But the choices are not interchangeable. Kiro is the lightest and most IDE-bound. Spec Kit is the heaviest, the most flexible across agents, and the most likely to bury you in markdown. Tessl is the boldest, treating the spec as source, and the least mature. BMAD and OpenSpec are where teams go once they have already decided process is worth the investment.

Pick by weight, not by star count. Match the tool to your team size and the task in front of you, start lighter than your instincts suggest, and reserve the full loop for work that genuinely spans files, sessions, and people. The single highest-leverage habit is not adopting an SDD tool at all. It is the discipline to skip it when the task never needed one. For the broader landscape these tools sit in, our AI development tools pillar maps how spec-driven workflows connect to the rest of the modern coding stack.