What Is Kiro? AWS's Agentic IDE for Spec-Driven Development
Kiro is AWS's agentic IDE for spec-driven development: three structured files, automated hooks, and parallel agents that implement what you specify.
The tool that bakes the spec into the IDE does not guarantee a good spec. It guarantees a fast path to a mediocre one if you skip the thinking. The method comes first.
Kiro is AWS’s agentic IDE built around spec-driven development. Give it a prompt and it generates a structured specification: three markdown files covering requirements, architectural design, and sequenced implementation tasks. Then it hands those files to parallel agents that write the code. It runs as a downloadable IDE, a CLI, and a browser-based interface. It is built on Code OSS (the open-source base of VS Code) and supports Anthropic Claude models plus a range of open-weight alternatives. You do not need an AWS account to start.
I run spec-driven development every day with Claude Code and my own pi-sdd-kit. I have not run Kiro in production at the scale of the crypto fintech I built (13 apps, 70 days, solo), but I have studied its documentation in depth, tracked the community conversation, and read Birgitta Böckeler’s hands-on evaluation at Thoughtworks. What follows is an honest practitioner’s read: what Kiro is, how its workflow actually operates, where it delivers real value, and where the edges are.
What Kiro actually is
Kiro is an IDE that makes spec-driven development the default workflow rather than something you assemble yourself. Where I build context files, steering documents, and a .status gate with plain markdown and Claude Code, Kiro wraps the same ideas into a graphical panel, named files in a .kiro/ workspace folder, and a UI that walks you step by step through requirements, design, and tasks before any code is written.
The core SDD insight is the same one I use daily: the spec is the source of truth and the code is the output. The surface is different. Kiro is IDE-first, not agent-plus-toolkit. You install it, open a project, click the Specs panel, and the workflow starts. The structural work that takes me an hour to set up for a new project is already there.
The three-file spec flow
Every Kiro feature starts with a prompt. From that prompt, Kiro generates three markdown documents in sequence, with a human approval gate between each. The workflow has two variants: Requirements-First (behavior first, then design, then tasks) and Design-First (technical architecture first, then requirements, then tasks). Requirements-First is the default for most product-driven work. Design-First suits constrained systems where the architecture is the starting constraint.
Kiro's Requirements-First spec workflow
Input
A prompt describing the feature or behavior you want to build
- 01requirements.md
Kiro generates EARS-formatted requirements: WHEN conditions and THE SYSTEM SHALL behaviors. Before moving to design, you can ask Kiro to analyze requirements for contradictions, ambiguities, and gaps. Human gate before proceeding.
- 02design.md
Architecture, data flow, data models, error handling, and testing strategy. Every requirement from step one maps to a design decision. Human gate before task generation.
- 03tasks.md
A sequenced list of implementation tasks, each tracing back to specific requirement numbers. The IDE provides controls to run tasks one by one and review changes per task.
- 04Implementation
Parallel agents execute the tasks from tasks.md. Property-based tests (fuzz-style correctness assertions) catch issues that pass unit tests but break on edge-case inputs.
Output
Working code with a traceable chain from the original prompt through approved requirements, design, and tasks
The workspace structure that Kiro creates around this workflow:
Kiro workspace layout
- .kiro/
- steering/memory bank
- product.mdproduct purpose, target users, business objectives
- tech.mdframeworks, libraries, constraints, preferred stack
- structure.mdfile organization, naming conventions, architecture
- hooks/automation
- lint-on-save.jsonexample: run linter after every agent file save
- specs/feature work
- user-auth/
- requirements.mdEARS-formatted behaviors and acceptance criteria
- design.mdarchitecture, data models, API contracts
- tasks.mdsequenced tasks with requirement traceability
The steering folder is Kiro’s equivalent of what I call the steering/ layer in my Claude Code setup: stable product context that the agent loads on every session so you never re-explain the same decisions. The hooks folder holds automation triggers. The specs folder holds feature work in progress.
Requirements use EARS notation
Kiro writes requirements in EARS, the Easy Approach to Requirements Syntax. The pattern is simple:
WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fieldsThis leaves the agent no room to interpret. “Validation errors” becomes a specific, testable outcome rather than a vague instruction. Kiro can also run an analyze step before moving to design, checking the full requirements list for logical inconsistencies, ambiguities, and gaps. Catching a contradiction in requirements costs seconds. Catching it after the design has been generated costs a redesign.
The full explanation of EARS and why it matters is in the cornerstone piece on spec-driven development. The short version: it is a 30-year-old format from requirements engineering, built exactly for the ambiguity that kills AI-generated code. Kiro adopted it as the default format, which is the right call.
Hooks turn discipline into automation
Hooks are one of Kiro’s more practical differentiators. A hook is an event-driven trigger that runs an agent prompt or a shell command when something specific happens in the IDE. You define them as JSON files in .kiro/hooks/.
The full trigger list covers:
- PostFileSave, PostFileCreate, PostFileDelete (agent touched a file)
- UserPromptSubmit and Stop (conversation events)
- PreToolUse and PostToolUse (agent tool lifecycle)
- PreTaskExec and PostTaskExec (before or after a spec task runs)
Some triggers can block the agent (PreToolUse, UserPromptSubmit, PreTaskExec) by returning exit code 2. Others run after the fact and add context. A PostFileSave hook that lints every TypeScript file the agent saves is three lines of JSON. A PostTaskExec hook that updates documentation after each completed task is a short agent prompt. The things you would otherwise have to remember to do manually become structural.
In my Claude Code setup, I rely on habit and a reviewer sub-agent to catch what I might forget. Hooks in Kiro bake those catches into the project rather than into the developer’s memory. That is a meaningful difference for teams where not everyone has the same discipline.
Steering is the memory bank that outlives the session
Kiro calls its persistent context system “steering.” Steering files live in .kiro/steering/ and are loaded into every agent interaction by default. The three foundation files Kiro generates automatically are product.md, tech.md, and structure.md. You can add any number of custom files.
Steering files support four inclusion modes, which is more granular than anything I built manually:
- Always: loaded on every interaction, for core standards
- fileMatch: loaded only when working with files that match a specified pattern
- manual: loaded on demand by referencing the file in chat with a hash prefix
- auto: loaded when the request semantically matches the file’s description
The conditional modes mean a security-standards.md only loads when you are touching auth code, keeping context clean for unrelated sessions. Global steering files (in ~/.kiro/steering/) apply across all workspaces, which lets teams push shared conventions to developer machines automatically.
This is directly parallel to the approach I describe in spec-driven development with Claude Code, where the steering/ folder holds four files (product, tech stack, conventions, principles) that give the agent the product context it needs before you even start a session. Kiro formalizes the same pattern with a UI and more flexible loading behavior.
How Kiro compares to the alternatives
Three distinct approaches exist for spec-driven development in AI coding today: Kiro, GitHub Spec Kit, and agent-plus-toolkit setups like Claude Code with pi-sdd-kit. They are not substitutes for each other. They target different workflows and different control preferences.
Kiro vs GitHub Spec Kit vs Claude Code with pi-sdd-kit
| Dimension | Kiro | GitHub Spec Kit | Claude Code + pi-sdd-kit |
|---|---|---|---|
| Delivery format | IDE (VS Code-based), CLI, web interface | CLI and slash commands in Copilot | Terminal agent plus npm kit, any editor |
| Spec pipeline | requirements.md, design.md, tasks.md with UI approval gates | spec.md, plan.md, tasks.md via slash commands | PRD, SPEC, TASKS, EXEC, REVIEW via .status token gate |
| Memory system | Steering files in .kiro/steering/, four inclusion modes | constitution.md (high-level rules file) | steering/ with product, tech, conventions, principles files |
| Approval gate | Visual UI step in IDE panel between each phase | Checklists within spec files (AI-interpreted) | Explicit .status token: file presence is not approval |
| Automation | Hooks: event-driven triggers on file, tool, and task events | Not built in | Reviewer sub-agent, manual habit and workflow discipline |
| Correctness checks | Property-based tests (fuzz-style assertions) built in | Not built in | Reviewer sub-agent checks against spec criteria |
| Editor requirement | Kiro IDE replaces your current editor | Any editor that supports Copilot | Any editor, Claude Code runs in terminal |
| Pricing | Free tier (50 credits), paid plans from $20/month | Open-source, free | pi-sdd-kit is free, Claude Code subscription required |
The deeper comparison between GitHub Spec Kit and the pi-sdd-kit approach is in the Claude Code workflow article, including why I use a .status token gate over a visual UI step: the mechanical check removes the ambiguity that a human reading a completed file can still miss.
The honest critique: three things to watch
Birgitta Boeckeler, a Distinguished Engineer at Thoughtworks, published a hands-on evaluation of Kiro, GitHub Spec Kit, and Tessl in October 2025. Her observations are the most credible independent critique of early Kiro, and while the product has evolved since, the questions she raised are still worth keeping in mind.
One workflow for all problem sizes. Boeckeler tried Kiro on a small bug fix and received four user stories with sixteen acceptance criteria. The requirements document turned a straightforward change into something she described as “using a sledgehammer to crack a nut.” Kiro has since added a Quick Plan option that skips the approval gates for well-understood features, and a Design-First path for technically constrained work. But the question is still live: does a three-file workflow with human gates add more value than overhead for a two-hour change? The answer is not always yes.
Reviewing markdown instead of reviewing code. The spec-driven workflow produces documents to review before code exists. In theory, catching errors in requirements is cheaper than catching them in implementation. In practice, Boeckeler found the review experience tedious, and said she would rather review code than verbose markdown. This is a real friction cost. If you do not give the reviewing step real attention, you will rush it, and rushed reviews defeat the point of the gate. This is not a Kiro-specific failure, but Kiro does produce three separate documents to approve before you see a line of code.
False sense of control. Even with structured specs, Boeckeler observed agents frequently missing instructions or over-applying others. Larger context windows raise the risk that the agent finds a pattern it honors too literally, or ignores a constraint it never surfaced. A spec creates the conditions for a good outcome. It does not guarantee one. The spec is the memory. The agent still interprets it. This applies equally to Kiro, GitHub Spec Kit, and the setup I run with Claude Code.
When Kiro is the right pick
Kiro makes the most sense when you want spec-driven development without assembling it yourself. Install the IDE, open a project, enter a prompt in the Specs panel, and the workflow starts. There is no context system to configure, no gate convention to establish, no sub-agent prompts to write. The cost is switching editors and accepting the workflow as Kiro has designed it.
More specifically: Kiro is a strong fit for teams where not every developer has the patience to hand-craft steering files and manage gate conventions manually. The visual approval step in the IDE is harder to skip than a file you could simply not update. The hooks system removes whole categories of “I forgot to run the linter” errors. The property-based testing catches correctness issues that unit tests miss by asserting rules across many generated inputs, not just the cases you thought to write.
Kiro is a weaker fit if you need precise control over the gate logic, work across multiple models and want to swap them freely, have complex correctness requirements that need custom verification steps, or already have a Claude Code setup that is working. The IDE switch has real cost: muscle memory, extensions, editor configuration, the terminals and tools you have arranged around your current environment.
The comparison with vibe coding is also relevant here. Kiro sits between vibe coding and a fully custom SDD pipeline. It is more structured than prompting directly, and less configurable than building your own workflow. That is not a criticism. Most teams benefit from more structure and less configuration. It depends on what you are optimizing for.
FAQ
What is Kiro?
Kiro is an agentic IDE built and operated by AWS that makes spec-driven development the default coding workflow. Give it a prompt describing a feature, and it generates requirements.md, design.md, and tasks.md in sequence, with human approval gates between each. Parallel agents then implement the code from those files.
It is available as a downloadable IDE (built on Code OSS, the open-source base of VS Code), a headless CLI, and a web interface. You do not need an AWS account. Sign in with GitHub, Google, AWS Builder ID, or AWS IAM Identity Center.
Is Kiro free?
Yes, there is a perpetual free tier with 50 credits per month. The free tier includes access to Claude Sonnet 4.5 and open-weight models such as DeepSeek v3.2 and Qwen. Rate limits apply.
Paid plans start at $20 per month for 1,000 credits (Pro), then $40 (Pro+, 2,000 credits), $100 (Pro Max, 5,000 credits), and $200 (Power, 10,000 credits). Add-on credits cost $0.04 each on individual plans. Team plans add consolidated billing, SSO via AWS IAM Identity Center, usage analytics, and enterprise security controls.
Who makes Kiro?
Kiro is built and operated by AWS (Amazon Web Services). It runs on AWS infrastructure and inherits AWS's security, reliability, and privacy standards. It offers IAM and SSO authentication, enterprise governance features, and GovCloud (US) support for regulated environments.
The AI models are Anthropic Claude (Sonnet, Haiku, Opus variants) plus open-weight models. An Auto mode selects the best model per task based on complexity, latency, and cost.
Does Kiro use spec-driven development?
Yes. SDD is Kiro's core workflow, not an optional add-on. It generates requirements.md, design.md, and tasks.md from a prompt, with a human approval gate between each phase. Requirements use EARS notation (WHEN condition, THE SYSTEM SHALL behavior), which makes each requirement directly testable.
Kiro also adds a requirements analysis step before design (checking for contradictions and gaps) and property-based tests after implementation, which assert correctness rules across a range of generated inputs rather than a fixed set of examples.
Kiro vs Cursor: what is the difference?
Cursor is a VS Code fork focused on AI-assisted coding: inline suggestions, multi-file edits, and a conversational agent. It does not have a built-in spec-driven workflow. You can apply SDD practices with Cursor by adding GitHub Spec Kit or building your own structure, but Cursor itself is a general-purpose AI editor.
Kiro is built specifically around SDD as the primary workflow. The spec pipeline (requirements, design, tasks) is the front door to every feature, not an optional mode. If spec-driven development is central to how you want to work, that difference is significant.
Kiro vs Claude Code: which one?
They are different in kind, not direct competitors. Kiro is an IDE with SDD baked into the interface. Claude Code is a terminal agent you run inside your existing editor. Both can support spec-driven workflows, but Kiro's pipeline is built into the UI; Claude Code's requires you to build or import the structure yourself (via pi-sdd-kit, GitHub Spec Kit, or plain markdown).
If you want a ready-built SDD workflow with visual gates, hooks automation, and minimal setup, Kiro is the faster start. If you want maximum control over the pipeline, the approval gate logic, and the models you use, Claude Code with a structured kit gives you more flexibility at the cost of more configuration.
Where this fits in the larger picture
Kiro is an honest attempt to make spec-driven development the path of least resistance for developers who would not build the workflow themselves. The three-file pipeline is correct. The hooks system solves real friction. The steering files address the memory problem that undermines every agent-assisted project that runs longer than a single session.
The critiques are also real. One opinionated workflow does not fit every problem size. Reviewing markdown under deadline pressure produces the same quality of review as reviewing code under deadline pressure: not enough. A spec is a discipline aid, not a discipline replacement.
The tool is downstream of the method. Spec-driven development works because writing requirements, design, and tasks before code forces a clarity that prompting never achieves. Kiro makes that forcing function easier to reach. Whether you use Kiro, GitHub Spec Kit, or Claude Code with a kit and some discipline, the spec is the thing. The tool is just the surface.
If you are already running SDD with Claude Code and it is working, there is no compelling reason to switch. If you are starting fresh and want the workflow built in from the first session, Kiro is the most direct path there.