Why did spec-driven development tooling take off in 2025-2026?
Spec-driven development (SDD) tools make a written, versioned specification the working contract for AI coding agents: humans review the spec, the agent generates plans, tasks, and code from it, and drift between the two is treated as a defect. Three tools now define the space, GitHub Spec Kit, AWS Kiro, and OpenSpec.
We covered the why in Spec-Driven Development: Why the Spec Is Now the Source of Truth; this piece goes tool by tool. The short version of the motivation:
- ▸Agents drift on prose prompts. A paragraph of chat instructions leaves the model to invent requirements, and it will, confidently. Vibe Coding Is Not Engineering: The 2026 Reckoning covers what that costs at scale.
- ▸Review has to move upstream. Reviewing a 2,000-line generated diff is hopeless; reviewing the 80-line spec that produced it is tractable.
- ▸Specs are the durable artifact. Models change quarterly; a good requirements file outlives all of them.
All three tools are opinionated scaffolding around that same loop. The differences, artifact structure, agent coupling, brownfield fit, are what decide which one survives contact with your team.
How does GitHub Spec Kit structure the workflow?
Spec Kit is GitHub's open-source (MIT) SDD toolkit: a Python CLI called Specify scaffolds a project, then a fixed chain of slash commands, /constitution, /specify, /plan, /tasks, /implement, runs inside your existing coding agent. It is agent-agnostic: GitHub Copilot, Claude Code, Gemini CLI, Cursor, and a dozen other assistants are supported.
The artifact chain is the core idea:
- ▸constitution.md captures non-negotiables, test coverage floors, approved stacks, licensing rules, that every later phase must respect.
- ▸spec.md (per feature) records the what and why: user journeys, acceptance criteria, and explicitly marked open questions.
- ▸plan.md is the how: architecture, data model, and technology choices, written against the constitution.
- ▸tasks.md decomposes the plan into small, independently reviewable implementation steps the agent executes.
Later additions, /clarify to interrogate underspecified areas and /analyze to check consistency across artifacts before implementation, address the most common failure we see in practice: planning on top of a spec with silent gaps.
Trade-offs to plan around: the ceremony is real (four artifacts before code), which suits new features and greenfield services far better than ten-line fixes, and after a spec edit you must regenerate or reconcile downstream artifacts yourself, the toolkit will not stop you from letting them diverge.
What does AWS Kiro do differently?
Kiro is AWS's take: a commercial agentic IDE (a Code OSS fork, generally available since late 2025 per public reporting) where specs are a first-class mode rather than a bolt-on. A Kiro spec is three files, requirements.md, design.md, and tasks.md, and the IDE executes tasks with the agent running in supervised or autopilot mode.
What stands out:
- ▸EARS acceptance criteria. Requirements are generated as user stories with EARS-syntax criteria ("WHEN a session expires, THE SYSTEM SHALL ..."), which are individually testable and reviewable, the strictest requirements discipline of the three tools.
- ▸Steering files. Markdown in .kiro/steering (product, tech, structure) persists conventions across sessions, so the agent stops re-deciding your stack every conversation.
- ▸Agent hooks. Event-driven automations, on file save, run tests, update docs, scan for accidentally committed secrets, put guardrails outside the model's discretion.
- ▸MCP support wires in external context such as tickets and internal docs without copy-paste.
The trade-off is coupling: Kiro is an IDE your team must adopt, pricing is credit-based across free and paid tiers (verify current limits on the official Kiro site, they have shifted since preview), and while the spec files themselves are portable markdown, hooks and steering only execute inside Kiro. Teams standardized on JetBrains or Neovim will feel that immediately.
Where does OpenSpec fit?
OpenSpec is the lightweight, brownfield-first option: an open-source CLI (installed via npm) that maintains living specs of what your system does today and treats every change as a diff against them. It carries the least ceremony of the three and is the easiest to retrofit onto an existing codebase.
The workflow inverts Spec Kit's:
- ▸openspec/specs/ holds current truth, capability-level specs describing existing behavior.
- ▸openspec/changes/ holds proposals: each change folder contains a proposal, spec deltas (added, modified, and removed requirements), an optional design note, and a task list.
- ▸Review happens on the delta, exactly the way engineers already review code diffs, then the agent implements, and an archive step merges the deltas back into the living specs.
It is agent-agnostic in the same way Spec Kit is (Claude Code, Cursor, Codex, and others via generated instructions), with no runtime dependency in your product.
The honest caveats: it is the youngest project of the three with the smallest ecosystem, and it deliberately ships fewer guardrails, there is no constitution equivalent, so your team conventions have to supply the discipline the tool does not impose.
How do the three compare side by side?
Choose on five dimensions: artifact model, change direction, coupling, governance, and cost. The one-line summary: Spec Kit is feature-forward and agent-agnostic, Kiro is IDE-integrated with the strongest requirements rigor, and OpenSpec is delta-based and built for evolving systems that already exist.
- ▸Artifact model: Spec Kit, constitution plus per-feature spec, plan, and tasks; Kiro, requirements, design, and tasks per spec; OpenSpec, living specs plus change deltas.
- ▸Change direction: Spec Kit and Kiro start from the new feature; OpenSpec starts from current behavior and diffs it.
- ▸Coupling: Spec Kit and OpenSpec run inside whatever agent you already use; Kiro requires its IDE.
- ▸Governance: Kiro's hooks and steering are enforced by the tool; Spec Kit's constitution is enforced by prompt convention; OpenSpec leaves governance to you.
- ▸Cost and licensing: Spec Kit and OpenSpec are MIT open source; Kiro is commercial with a free tier and credit-based paid tiers.
- ▸Lock-in risk: all three keep artifacts in plain markdown under git, so migration cost is mostly workflow retraining, not data.
None of this is a quality ranking. The dimensions interact with your estate: a team of three maintaining a five-year-old Django monolith and a platform team spinning up new services weekly should not pick the same tool.
Which tool fits greenfield versus brownfield work?
Match the tool to your change profile. Greenfield features and new services favor Spec Kit or Kiro, because their pipelines assume you are describing something that does not exist yet. Brownfield changes, the majority of real engineering work, favor OpenSpec, because its spec base describes what already exists.
More precisely:
- ▸Pick Kiro if your team will adopt the IDE, you want EARS-grade acceptance criteria and hook-enforced automation, and commercial support matters more than avoiding vendor coupling.
- ▸Pick Spec Kit if you want maximum agent flexibility, you ship distinct features with real design decisions, and you can absorb the ceremony.
- ▸Pick OpenSpec if most work modifies existing behavior, you need light process a small team will actually follow, and you want reviewable deltas rather than full rewrites.
- ▸Mixed estates are normal. The artifacts are all markdown; some teams run Spec Kit for new services and OpenSpec for the legacy core. The conventions, spec before code, review the spec, gate on drift, matter more than the logo.
Whichever you choose, the spec quality bar is yours to set; How to Write a Software Requirements Document That Actually Ships still applies almost unchanged.
What failure modes show up regardless of tool?
Every SDD rollout we have seen hits the same four traps: spec drift, spec theater, over-specification of trivial work, and unreviewed hallucinations at the plan stage. Tooling reduces all four; none eliminates them, because they are process failures rather than tooling failures.
- ▸Spec drift. Code gets hotfixed without touching the spec; three months later the spec is fiction. Fix: specs live in the same PR as the code they govern, and CI flags changes to governed paths that arrive without a spec delta.
- ▸Spec theater. Engineers write the spec after the code to satisfy process. It is detectable in review timestamps and fatal to the whole point.
- ▸Ceremony on trivial changes. A one-line fix does not need four artifacts. Set an explicit threshold, typically anything under a half-day of work skips the pipeline.
- ▸Hallucinated plans. Agents invent APIs and library behavior at the plan stage just as they do in code, see AI Hallucinations in Software: When Your Copilot Invents an API, so plans need review by someone who knows the real dependency surface.
The pattern: SDD moves human judgment upstream. It does not remove it.
How do you pilot SDD tooling without disrupting delivery?
Run a bounded pilot: one team, two sprints, one tool, an explicit threshold for which changes get specs, and success criteria agreed up front, typically reduced rework rate and reduced review time per change, not raw velocity. Decide adopt, adjust, or drop at the end; do not let it linger as optional.
A shape that has worked:
- ▸Week 1: install, write the constitution or steering docs or baseline specs, and run two real but non-critical features through the full flow.
- ▸Weeks 2-4: all qualifying changes go through the tool; track rework (changes re-opened within 14 days), review latency, and how often implementation diverged from spec.
- ▸Retro: the deciding question is whether reviewers trusted specs enough to review them instead of the diff. If they still read every generated line, the pilot has not paid for itself yet, either the specs are too vague or the threshold is wrong.
How TuniCyberLabs helps
We run spec-driven workflows on our own delivery work for EU and North African clients, agent-assisted builds gated by reviewed specs, drift checks in CI, and requirements standards that survive contact with real codebases. If you are evaluating Spec Kit, Kiro, or OpenSpec, our engineering services team can design, tool, and measure the pilot with you.
Talk to an engineer about your SDD pilot: contact TuniCyberLabs.