OpenSpec vs Spec Kit vs Kiro: Which Spec-Driven Workflow Should You Actually Use? Transcript, AI Summary & Key Points

00:00 If you're a lean startup wiring up Cursor or Claude Code, pick OpenSpec. If you're an enterprise team standardizing on GitHub Copilot, pick Spec Kit. If you're building AWS-native and want the agent living inside the IDE, pick Kiro. That's the verdict — now let's earn it. All three tools chase the same promise: stop vibe-coding, start speccing. Instead of describing what you want in a chat window and hoping the agent gets it right, you write the requirement down first, as a file, in your repository — and the agent

00:00 builds against that file instead of your last message. Three tools, one philosophy, three different bets on how to implement it. Over the next few minutes we'll run OpenSpec, GitHub Spec Kit, and Kiro through the same five criteria — spec format, agent integration, drift handling, lock-in, and cost — so by the end you know exactly which one matches how you build.

00:57 Why does spec-driven development matter at all? Because the real failure mode of agentic coding isn't bad code — it's the agent confidently building the wrong thing for an hour before you notice. I covered that problem in an earlier video on OpenSpec: vibe-coding drifts because there's no persistent record of what you actually asked for. Spec-driven development fixes that by putting the requirement in a file the agent has to read before it writes a line of code.

01:23 Let's meet the three contenders. OpenSpec comes from Fission A.I., an early-stage startup out of Y Combinator's winter twenty twenty-six batch. It's open-source under the MIT license, and its one-line pitch is a lightweight, tool-agnostic spec framework that checks straight into git. GitHub Spec Kit comes from GitHub, under Microsoft — also MIT-licensed, also open-source, and its pitch is a structured, standardized planning toolkit built to work with any coding agent.

01:23 Kiro comes from Amazon Web Services. It's proprietary — a full agentic IDE and CLI, not just a set of templates — and its pitch is that specs, hooks, and cloud deployment all live in one integrated environment. Same problem, three very different organizations backing three very different answers. Here's how I'm judging them, on five criteria, one round each.

02:13 Round one: spec format — what the requirement file actually looks like. Round two: agent integration — how many coding agents plug in, and how. Round three: drift handling — what happens when the code and the spec disagree, which is the differentiator that matters most in practice. Round four: lock-in — what it costs you to leave. And round five: cost and maturity — what you pay, and how battle-tested each project is.

02:13 Five rounds, one scorecard at the end. Round one: spec format. OpenSpec stores its specs under an openspec folder, written in plain Markdown, using RFC twenty-one nineteen keywords like SHALL and MUST, with acceptance scenarios in given, when, then form. GitHub Spec Kit stores its specs under a hidden dot-specify folder, structured as prioritized user stories — P one, P two, P three — with their own acceptance scenarios.

02:48 Kiro stores its specs under a dot-kiro folder, written in EARS notation, the Easy Approach to Requirements Syntax, which reads like: when this condition holds, the system shall do this. All three are trying to make requirements unambiguous enough for an agent to implement without guessing. They just disagree on the notation. Round two: agent integration.

03:37 OpenSpec is tool-agnostic, plugging into twenty-five-plus coding environments — Claude Code, Cursor, GitHub Copilot, Windsurf — through slash commands, or as a Model Context Protocol server. GitHub Spec Kit is also agent-agnostic, installed through its own specify command-line tool, and claims the widest reach at thirty-plus supported agents, from Copilot to Gemini CLI to Codex.

03:37 Kiro takes a narrower, deeper approach: a standalone desktop IDE or CLI, wired directly to Anthropic's Claude models through Amazon Bedrock, supporting the Model Context Protocol and the Agent Client Protocol for swapping in other editors. Breadth versus depth — Spec Kit and OpenSpec optimize for reach, Kiro optimizes for one well-integrated stack. Round three: drift handling — and this is the round I'd weight most heavily, because it's the one that decides whether your spec is still true six months in.

04:29 OpenSpec treats the spec files in git as the single source of truth. You draft a proposed change as a delta spec, then run a verify or check command that lints and validates the change before it's archived into the main spec directory — drift is something you inspect directly with a git diff. GitHub Spec Kit separates the spec, the product requirement, from the plan, the technical detail, and leans on a community-maintained extension called spec kit sync to scan for mismatches and propose fixes — it's not built into

04:29 the core toolkit, it's bolted on. Kiro takes the most automated approach: persistent steering files keep the agent obeying your architecture across sessions, and agent hooks trigger automatically on file save, running linters, updating docs, keeping the spec in step with the code without you asking. If drift handling is the criterion you care about most, notice that only one of these three ships it as a first-party, automatic feature.

05:31 Round four: lock-in — what it costs you to walk away. OpenSpec and GitHub Spec Kit land in the same place: zero lock-in. Both are MIT-licensed, both store specs as plain Markdown files committed to your repository, and both can be read by any tool or any developer with no special software required. Kiro is different. It's a proprietary IDE and CLI, and its agent capabilities are tied to Anthropic models running on Amazon Bedrock — so switching away means rebuilding your workflow, not just copying files.

05:31 That said, Kiro does lean on open standards, the Model Context Protocol and Agent Client Protocol, to keep individual tools swappable, and it lets you export full agent chat histories. Call it moderate lock-in, not total. Round five: cost and maturity. OpenSpec is one hundred percent free and open-source, with no paid tier, and has roughly sixty thousand six hundred stars on GitHub.

06:16 GitHub Spec Kit is also free as a toolkit — though you're still paying for whatever coding agent you plug into it — and it's the most-starred of the three, at roughly one hundred twenty thousand five hundred stars. Kiro runs on credit-based billing: fifty credits a month free, then paid tiers starting around twenty dollars a month for a thousand credits, scaling up from there — and it reached general availability in November of twenty twenty-five, with about four thousand stars on its public feedback repository.

06:16 None of this makes one tool the cheap one that wins — cost is one factor among five, and for Kiro specifically, you're paying for a fully integrated cloud IDE, not just a template generator. Here's the full scorecard, side by side. Backing organization, license, maturity, spec directory, requirements format, primary interface, agent support, drift handling, lock-in, and pricing — ten rows, three tools, one screen.

07:05 Pause it if you want the details. But the pattern that jumps out is this: OpenSpec and Spec Kit are nearly identical on paper — open-source, MIT-licensed, zero lock-in — and differ mainly in ecosystem reach and notation. Kiro is the outlier on almost every row, because it isn't really competing on the same axis. It's not a lighter-weight version of the other two; it's a different category of product.

07:48 So which should you actually pick? If you're a lean startup team, already living inside Cursor or Claude Code, and you want zero cost and zero lock-in — pick OpenSpec. If you're an enterprise team standardizing on GitHub Copilot and you need a structured, widely-supported planning process your whole org can follow — pick Spec Kit. And if you're building AWS-native, already inside the Bedrock ecosystem, and you want specs, hooks, and deployment in one integrated environment — pick Kiro.

07:48 These aren't mutually exclusive bets on the future of coding. They're three answers to three different starting points, and the honest move is picking based on where you already stand, not which one has the most stars. Three takeaways from this comparison. One: spec-driven development is converging on the same shape everywhere — a requirement file, checked into version control, that the agent reads before it writes code — even though the notation differs from RFC twenty-one nineteen to user stories to EARS.

08:30 Two: drift handling is the criterion that actually separates these tools day to day, more than license or star count — check whether your pick treats it as a first-party feature or a bolt-on extension before you commit. Three: lock-in and integration depth trade off against each other — the tool that plugs into the most agents is rarely the one with the deepest automation, and that's a real choice, not a flaw in either direction.

08:30 If this kind of technical comparison is useful to you, consider subscribing — I break down how these developer tools actually work, not just how they're marketed. Thanks for watching.