AWS Kiro: The Agentic IDE That Makes Specs the Unit of Work

The agentic IDE space has gotten crowded fast. Cursor, Claude Code, Copilot, Windsurf — they all share the same core model: you type a prompt, the AI writes some code, you iterate. It works well for prototyping. It breaks down when you're building production systems on a large codebase with a team of more than one.

AWS Kiro takes a different bet. Instead of chat-first, it's spec-first. The unit of work isn't a prompt — it's a structured specification that the agent uses to plan, implement, verify, and document your feature end to end. That's a meaningful philosophical difference, and in practice it changes what the tool is useful for.

Here's what Kiro actually is, how its core concepts fit together, and an honest take on when it makes sense over the alternatives.

What Kiro Is

Kiro launched from AWS in mid-2025 and is built on top of Amazon Bedrock, routing between Claude Sonnet for reasoning-heavy work and Amazon Nova for high-throughput code generation. It ships in three forms:

• Kiro IDE — a VS Code-compatible editor (built on Code OSS, so you can import your existing themes, keybindings, and Open VSX plugins)
• Kiro CLI — the same agent in your terminal, useful for SSH sessions or scripted workflows
• Kiro Autonomous Agent — a background agent that picks up tasks, implements them, and opens PRs without you sitting in the loop

You don't need an AWS account to get started — you can sign in with GitHub or Google. The IDE feels immediately familiar if you've used VS Code, which removes one of the usual adoption barriers for new tooling.

In January 2026, AWS also announced the end of Amazon Q Developer for new signups (effective May 15, 2026), explicitly directing users to Kiro as its successor for IDE-based AI assistance. That's a significant signal about where AWS is placing its bets.

The Three Concepts That Make Kiro Different

1. Specs

When you start a new feature in Kiro, you don't jump straight to code. You describe what you want to build, and Kiro generates three structured files:

• requirements.md — user stories and acceptance criteria
• design.md — system design, component breakdown, data flow
• tasks.md — a numbered implementation checklist the agent works through

These become the source of truth. Code is a build artifact of the spec. When you come back to the feature a month later, or hand it to a new team member, the reasoning behind every decision is documented — not in a Confluence page nobody reads, but in the repo next to the code it describes.

This is the thing chat-first tools can't replicate. Cursor or Claude Code can generate excellent code from a good prompt. What they can't do is maintain a structured paper trail of why the code looks the way it does.

2. Hooks

Hooks are event-driven automations that fire when things happen in your workspace — file save, new file created, commit opened. You define what Kiro should do in response, and it runs those actions in the background without you having to think about them.

Common hooks teams set up:

• Run the linter and auto-fix on every file save
• Regenerate unit tests when implementation files change
• Update the relevant section of design.md when a module is modified
• Run a security scan before any commit

The practical effect is that a junior developer's output passes the same automated quality bar as a senior's, because the standards are enforced by the environment rather than by code review heroics.

3. Steering Files

Steering files are Markdown files that give Kiro persistent context about your project — your conventions, the libraries you've standardized on, your architecture decisions, your security requirements. You create them once, and Kiro reads them on every interaction without you having to re-explain your stack in every prompt.

They live in two places:

• ~/.kiro/steering/ — global rules that apply across all your projects
• .kiro/steering/ — project-specific overrides checked into the repo

A typical global steering file might say things like "always use TypeScript strict mode," "prefer AWS CDK over raw CloudFormation," or "all Lambda functions must have structured logging with a correlation ID." Project steering files add things like "this service is a multi-tenant SaaS, tenant ID is always passed in the request context."

The result is that Kiro's context isn't reset between sessions and doesn't depend on whoever wrote the last prompt being thorough.

The Hooks + Specs Flywheel

The real power emerges when hooks and specs work together. Here's what that looks like in practice:

1. You describe a new feature. Kiro generates requirements.md, design.md, and tasks.md.
2. You review and refine the spec — add an edge case to requirements, adjust the component breakdown in design.
3. Kiro implements the tasks list, following your steering files for conventions.
4. On each file save, hooks run: linter, tests, security scan. Issues surface immediately.
5. When you're done, a hook generates the commit message from the spec diff.
6. The PR description writes itself from requirements.md.

The spec doesn't go stale because hooks keep it in sync with the code. The code doesn't drift from the design because the design was written before the code. This is what "engineering rigor" means in the context of agentic development — not slower, but structured.

AWS-Native Advantages (and the Honest Tradeoff)

Kiro has deep integration with the AWS ecosystem: CodeCatalyst for repositories and CI/CD, Bedrock for model access, IAM Identity Center for enterprise auth, and "Kiro Powers" — pre-packaged MCP servers for AWS-specific domains like CDK, CloudFormation, pricing, and (recently) HealthOmics workflows.

If your team is already AWS-first, this is a genuine multiplier. Your Kiro agent can query your actual AWS account context, reference live Bedrock documentation, and generate CDK constructs that match your organization's guardrails.

The honest tradeoff: if your team isn't AWS-first, some of this integration feels like overhead rather than lift. Kiro works perfectly well as a general-purpose agentic IDE — the spec/hooks/steering system has value regardless of your cloud provider — but the ecosystem integrations are clearly designed for AWS shops. Most teams running mixed infrastructure (some AWS, some not) find it practical to use Kiro for the AWS-native services and keep their existing editor for everything else. The two coexist fine.

How It Compares to the Alternatives

Kiro and Claude Code aren't direct competitors in practice — Kiro is an IDE product and Claude Code is a terminal agent. Many teams run both, using Kiro for structured feature work and Claude Code for open-ended refactors or one-off tasks.

Getting Started

Download the IDE from kiro.dev — no AWS account required. Sign in with GitHub or Google, point it at an existing repo, and run through the onboarding to import your VS Code settings.

A good first experiment: take a feature you're planning to build anyway, describe it to Kiro, and look at the spec it generates before writing any code. The value of the approach becomes obvious when you see your vague "add user preferences" idea turn into a concrete requirements doc with six acceptance criteria and a data model.

From there:

• Create one global steering file in ~/.kiro/steering/ with your language and framework defaults
• Set up one hook that runs your linter on file save
• Build the feature using the task list Kiro generated

That's the feedback loop that makes the tool click. The full power of the hooks and autonomous agent comes later, but even the basic spec workflow is a meaningful improvement over prompt-and-iterate for anything that takes more than a day to build.

Worth Watching

A few things that make Kiro worth keeping an eye on even if you're not ready to switch:

The spec-as-artifact model is genuinely novel. When agents get better, spec-driven codebases will be better positioned to benefit — the structured requirements and design docs give future agents much richer context than a commit history and some comments.

Kiro Powers (the MCP server marketplace) is growing fast. The HealthOmics extension in February 2026 showed that domain-specific agent packs are a real product direction, not just a demo.

And with Amazon Q Developer sunsetting for new users, AWS is clearly consolidating its developer AI bet onto Kiro. Whatever the roadmap looks like from here, it's going to get resources.

Kiro isn't the right tool for every workflow. If you're prototyping solo or doing exploratory work, the spec-first overhead is friction you don't need. But for teams shipping production features that need to be documented, tested, and maintained — the bet that specs should be the unit of work is a compelling one.

Kiro vs. the Alternatives

How Spec-Driven Development Works

┌─────────────────────────────────────────────────────────┐
│              YOU: describe a feature                     │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│                KIRO GENERATES SPECS                      │
│                                                          │
│  .kiro/specs/my-feature/                                 │
│  ├── requirements.md  ← user stories + EARS notation     │
│  ├── design.md        ← architecture, data flow, APIs    │
│  └── tasks.md         ← ordered implementation plan      │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│              YOU: review + refine specs                  │
│  add edge cases, adjust design, approve task list        │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│            KIRO IMPLEMENTS task by task                  │
│  guided by steering files + spec context                 │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│              HOOKS FIRE AUTOMATICALLY                    │
│  on every file save:                                     │
│  → linter + autofix                                      │
│  → test generation / update                              │
│  → security scan                                         │
│  → design.md sync                                        │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│        PR OPENS — description from requirements.md       │
│        commit message generated from spec diff           │
└─────────────────────────────────────────────────────────┘

Steering File Layout

~/.kiro/steering/              ← global, applies to every project
├── typescript.md              "always use strict mode, no any"
├── aws.md                     "prefer CDK over raw CloudFormation"
├── security.md                "IAM roles must follow least privilege"
├── git.md                     "use conventional commits"
└── testing.md                 "80% coverage minimum, jest + RTL"

your-repo/
└── .kiro/
    └── steering/              ← project-specific overrides (checked in)
        ├── architecture.md    "multi-tenant SaaS, one DB schema per tenant"
        ├── api.md             "all endpoints versioned under /v1"
        └── data-model.md      "tenant ID always in request context, never inferred"

Hook Definition Example

# .kiro/hooks/test-sync.yaml
name: Sync Tests on Component Save
trigger:
  event: onSave
  pattern: "src/**/*.tsx"
instructions: |
  When a React component file is saved:
  1. Check if a corresponding test file exists in __tests__/
  2. If not, create one with basic render and snapshot tests
  3. If it exists, update it to cover any new props or exported functions
  4. Run the test file and report failures inline

# .kiro/hooks/security-scan.yaml
name: Pre-commit Security Scan
trigger:
  event: onCommit
instructions: |
  Before every commit:
  1. Scan staged files for hardcoded secrets, API keys, and credentials
  2. Check for any 0.0.0.0/0 ingress rules in IaC files
  3. Flag any new IAM policies that use wildcard actions (*)
  4. Block the commit and explain any findings — do not auto-fix

How Powers Solve Context Rot

Without Powers, connecting multiple MCP servers front-loads your entire context window before you write a single line:

Without Powers
──────────────────────────────────────────────────
Context window (200K tokens)

[Figma MCP tools]     ~12K tokens  ████
[Postman MCP tools]   ~18K tokens  ██████
[Stripe MCP tools]    ~10K tokens  ███
[Supabase MCP tools]  ~15K tokens  █████
[Datadog MCP tools]   ~9K tokens   ███
                      ──────────────────
Total overhead        ~64K tokens  (32% gone before first prompt)

With Powers (dynamic loading)
──────────────────────────────────────────────────
You mention "payment" → Stripe power activates
You mention "database" → Supabase activates, Stripe deactivates
Baseline overhead: ~0K tokens until context is needed

Workspace Architecture for AWS Teams

AWS Organization
└── Management Account
    ├── Client A Account
    │   ├── Kiro workspace  (.kiro/ scoped here)
    │   ├── CodeCatalyst repo
    │   ├── Bedrock access (us-east-1)
    │   └── Secrets Manager (client A secrets only)
    │
    ├── Client B Account
    │   ├── Kiro workspace  (.kiro/ scoped here)
    │   ├── CodeCatalyst repo
    │   ├── Bedrock access (us-east-1)
    │   └── Secrets Manager (client B secrets only)
    │
    └── Shared Services Account
        ├── IAM Identity Center (SSO for all Kiro logins)
        └── Billing consolidated

This pattern keeps client IP, secrets, and Bedrock spend isolated by account boundary — IAM does the enforcement, not convention.

Resources

• kiro.dev — download is free, no AWS account required
• Introducing Kiro — the original launch post, good context on the design philosophy behind specs and hooks
• Introducing Powers — explains why dynamic MCP loading matters and how Powers solve context rot
• Teaching Kiro new tricks with steering and MCP — practical deep dive on using steering + MCP to handle custom libraries and DSLs
• Specs documentation — full reference including the Design-First and Bugfix spec workflows
• Kiro Powers marketplace — browse Figma, Stripe, Supabase, Datadog, Terraform and more
• IDE Changelog — how fast the product is moving
• Amazon Q Developer end-of-support announcement — official AWS post confirming Kiro as Q Developer's successor
• github.com/kirodotdev/Kiro — issue tracker and feedback repo