AWS Kiro: Spec-Driven IDE for Agentic Development

There is a quiet argument happening inside every engineering team that uses AI coding tools: should the AI write code directly from a chat prompt, or should it first commit to a plan you can actually verify?

Cursor and Windsurf answer "write from the prompt." AWS Kiro answers "write the spec first."

That is not a small difference. It changes what you version, what you review in a pull request, and who on the team can understand what the agent actually built. This guide covers what Kiro does, how the spec workflow is structured, how agent hooks automate the repetitive parts, and where it fits relative to the other agentic IDEs competing for your workflow in 2026.

What Kiro Is

Kiro is a desktop IDE built on Code OSS — the open-source base that VS Code also runs on — developed by Amazon Web Services and released to the public in late 2025. It reached general availability in November 2025 after hitting capacity limits within days of its July preview launch.

The product is positioned as AWS's successor to Amazon Q Developer. AWS ended new Q Developer signups effective May 15, 2026, explicitly directing new users to Kiro. That matters for team context: if your organization is already on AWS and was evaluating Q Developer, Kiro is now the answer.

The core design principle: specs are the source of truth, and code is a build artifact derived from them. Rather than asking an agent to "add a rate limiter," you write a spec that describes what the rate limiter should do, under what conditions, and what the acceptance criteria are. The agent then generates code to satisfy the spec, not just a prompt.

The Spec Workflow

When you start a feature, Kiro creates three structured markdown files under .kiro/specs/{feature-name}/:

requirements.md captures user stories and acceptance criteria using EARS notation (Easy Approach to Requirements Syntax). EARS structures each requirement as a conditional assertion:

WHEN the user submits the registration form
THEN the system SHALL validate the email format before saving
AND the system SHALL return a 422 with field-level errors when validation fails

That format is not just documentation. It maps directly to testable assertions, which is why Kiro can generate test stubs from requirements with reasonable accuracy.

design.md documents the technical architecture for the feature — data models, sequence diagrams in text form, interface contracts, and any relevant infrastructure considerations. This file lives in the repo alongside the feature code, so anyone reviewing a pull request can see the design intent without reconstructing it from the implementation.

tasks.md contains a discrete task list that Kiro generates from the requirements and design. Tasks are tracked as in-progress or completed as the agent works through them. You can pause, redirect, or reassign tasks manually; Kiro treats them as a checkpoint-able queue, not a linear script.

The three-document structure is also the surface where human review happens. Before the agent touches code, you can edit requirements to narrow scope, add edge cases to the design, or reprioritize tasks. That is the mechanism Kiro offers for keeping the human in the loop on complex features without turning every step into a manual approval.

Strengths
<ul>
  <li>Specs survive code refactors — the "why" stays versioned in the repo</li>
  <li>EARS format produces testable acceptance criteria, not vague prose</li>
  <li>Spec review is a natural code review gate that any team member can participate in</li>
  <li>Free tier (50 requests/month) requires no AWS account or credit card</li>
  <li>Powers bundle MCP servers + hooks into reusable, context-aware packages</li>
</ul>


Limitations
<ul>
  <li>Spec-first workflow adds planning time — not suited for fast prototyping</li>
  <li>Credits deplete quickly on multi-file specs (community-reported)</li>
  <li>Deep AWS integrations require an AWS account and Bedrock access</li>
  <li>Smaller extension/plugin ecosystem compared to VS Code or Cursor</li>
</ul>

Agent Hooks: Automating the Repetitive Parts

One feature that distinguishes Kiro from competitors is its hook system. Hooks are event-driven automations configured in .kiro/hooks/ as JSON files. When a trigger event fires, the hook either runs a natural-language agent prompt or executes a shell command.

The available triggers as of Kiro's 0.10 changelog:

• file:save — fires whenever you save a file
• file:create — fires when a new file is created
• task:pre — fires before a spec task begins executing
• task:post — fires after a spec task completes

Common hook patterns from the official Kiro blog:

{
  "trigger": "file:save",
  "match": "src/components/**/*.tsx",
  "action": {
    "type": "agent",
    "prompt": "Update the test file for the component that was just saved. Keep existing test cases; add new ones only for changed behavior."
  }
}

That hook means you never manually sync your test file after touching a component. The agent does it on save, automatically, every time.

The task:post hook is useful for quality gates. You can configure it to run linting, type checking, or test execution after each agent task completes — so that a multi-step spec run doesn't silently accumulate broken intermediate states.

Hooks are committed to the repository, not stored locally in user preferences. That means the automation behavior is consistent across the whole team and survives machine changes.

Kiro Powers and MCP Integration

Kiro supports both local and remote MCP servers. Its differentiated feature here is "Powers" — a packaging concept introduced in changelog 0.10.

A Power bundles three things into a single installable unit:

1. An MCP server providing tools
2. A steering file that defines when and how to activate those tools
3. Optional hooks that automate related tasks

Powers activate on-demand based on conversation context rather than loading all MCP tools upfront. This keeps the token budget clean: if you are working on a CloudFormation stack, the CloudFormation Power becomes active; the pricing tools stay dormant until they are relevant.

AWS ships first-party Powers for several of its own platforms: CDK, CloudFormation, Pricing, and HealthOmics workflows. Third-party Powers follow the same packaging spec. If you are building your own MCP server and want it to integrate cleanly with Kiro, the Powers format gives you a structured way to bundle it.

This is worth comparing to how Cursor handles MCP: Cursor supports MCP servers directly but without the packaging abstraction. All configured servers load simultaneously, and there is no built-in concept of context-aware activation. For teams with many MCP tools, the Powers approach reduces noise at the cost of an additional configuration layer.

Pricing and Getting Started

Kiro runs on a credit system. One agentic request equals one credit. Plans as of May 2026:

Plan	Monthly Credits	Price	AWS Account Required
Free	50	$0	No
Pro	Unlimited*	$20/mo	No
Pro+	Unlimited*	$40/mo	No
Power	Unlimited*	$200/mo	Optional

*Overage credits beyond the plan's included usage cost $0.04 each, billed at month-end.

To install: download from kiro.dev/downloads. The installer is available for macOS, Windows, and Linux. Sign in with GitHub, Google, AWS Builder ID, or IAM Identity Center. No credit card for the free tier.

Your first project follows this path:

1. Open a folder in Kiro
2. Open the Kiro panel and type a feature description in natural language
3. Kiro generates .kiro/specs/your-feature/requirements.md — review and edit it
4. Approve the requirements → Kiro generates design.md and tasks.md
5. Approve the design → Kiro begins working through tasks.md sequentially
6. Hooks run automatically on file saves during implementation

The full quickstart is at kiro.dev/docs/getting-started/first-project/.

How Kiro Compares to Cursor and Windsurf

The agentic IDE space has three dominant positions heading into mid-2026:

Cursor (1M+ daily active users, $20/mo Pro) is the market leader. Its strength is codebase indexing: semantic embeddings of the entire repo, @-file references, and a polished multi-file editing experience. Agent mode handles large refactors well. The weakness is that "prompt → code" means the agent's intent is implicit in the output, not in a verifiable artifact.

Windsurf ($15/mo) targets enterprise teams. Its Cascade feature auto-discovers context without manual file tagging, which works well on large codebases. First-pass success on complex tasks is reported as higher than Cursor's agent mode.

Kiro is the most opinionated of the three. It trades speed for verifiability. The spec workflow adds 15–30 minutes of upfront planning to any non-trivial feature. In return, you get requirements that you can reference in code review, design decisions that survive refactors, and hooks that keep tests and documentation in sync automatically.

A useful heuristic: if your team already writes design documents before implementing, Kiro formalizes that workflow and connects it to the code generation loop. If your team goes from Jira ticket straight to code, Kiro will feel like it is adding ceremony without clear return.

For further context on the broader agentic IDE landscape, see the cursor vs windsurf vs zed comparison and the best AI coding agents roundup for 2026.

Who Should Actually Use Kiro

Good fit:

• Teams already on AWS who want AI coding integrated with their existing Bedrock and IAM setup
• Projects where requirements traceability matters: regulated industries, complex APIs, multi-team codebases
• Engineers who write design documents by habit and want to close the gap between the doc and the code
• Anyone evaluating Amazon Q Developer alternatives (Kiro is now the official successor)

Less useful:

• Solo developers doing rapid prototyping where the cost of planning exceeds the cost of mistakes
• Projects where the team does not review design artifacts — specs without readers add overhead with no return
• Teams wanting the largest VS Code extension ecosystem (Kiro's is smaller, though growing)

The Real Question: Is Spec-Driven Development a Better Default?

The honest answer is that spec-driven development is better for some teams and worse for others — and Kiro does not resolve that ambiguity for you.

What Kiro does resolve is the artifact gap that exists in every other agentic IDE: the mismatch between what you asked for and what the code actually does, documented nowhere. The spec files live in the repository. When something breaks three months later, you can read what the system was supposed to do instead of reverse-engineering it from the output.

Whether that is worth the additional workflow overhead depends on how much of your team's time currently goes into maintaining context versus generating new code. For teams where "why does this work this way" is a common question in standups, the spec overhead pays back quickly. For solo builders iterating fast, the overhead stays overhead.

Kiro's MCP Powers concept is worth watching independently of the spec workflow. Bundling MCP servers with activation context and hooks is a packaging idea that other IDEs will likely adopt — it solves a real problem with how multiple MCP tools currently have to be configured and managed.

FAQ

Q: Does Kiro work without an AWS account?

Yes. The free tier (50 agentic requests/month) and the paid Pro plans ($20/mo) work with GitHub or Google sign-in. An AWS account only becomes relevant if you want to use Bedrock directly or connect to AWS-specific Powers like CloudFormation or CDK.

Q: Are Kiro specs committed to the repository?

Yes. The .kiro/specs/ and .kiro/hooks/ directories are intended to be committed. Specs and hooks are team artifacts, not personal IDE settings. This is deliberate: Kiro's design assumes the spec files are part of the code review surface.

Q: How are Kiro credits consumed?

Each agentic request consumes one credit. Generating a spec from a prompt, executing a task from tasks.md, or running an agent hook each count as one request. Autocomplete and inline suggestions do not consume credits. On the free tier (50 credits/month), a medium-complexity feature with 8–10 spec tasks plus several hooks will use most of the monthly allowance.

Q: What is the difference between Kiro Powers and regular MCP servers?

A Power is an MCP server plus a steering file plus optional hooks, packaged together. The steering file tells Kiro when to activate the Power's tools based on conversation context. Regular MCP servers load all their tools upfront; Powers load on-demand. The practical difference is a shorter tool list in the agent's context window, which reduces token usage and improves relevance on complex tasks.

Q: Is Kiro open source?

The Kiro codebase repository is at github.com/kirodotdev/Kiro. The IDE is built on Code OSS (VS Code open-source base). The agent runtime and Bedrock integrations are proprietary AWS services.

Bottom Line

Kiro is the first agentic IDE that makes the design document part of the build process rather than a separate artifact that decays. The spec workflow adds overhead that pays back on team codebases where requirements traceability matters. For solo prototyping or teams that run Cursor smoothly, there is no compelling reason to switch today — but the Powers and hooks concepts are worth watching as patterns the rest of the IDE market will absorb.