Amazon Kiro Review: AWS's Spec-Driven Agentic IDE in 2026

Most agentic IDEs optimize for the same loop: you type a prompt, the agent edits files, you review the diff. Kiro — AWS’s entry into the category, launched in public preview in July 2025 and out of preview since late 2025 — bets on a different loop entirely. Before it writes application code, it writes documents: a requirements file, a design file, and a task list. You review and edit those, and only then does the agent start implementing.

That sounds like process overhead, and sometimes it is. But after running Kiro through a few real features on a mid-sized TypeScript codebase, we think the spec-first workflow solves a problem every Cursor and Copilot user has hit: the agent that confidently builds the wrong thing, fast.

How spec-driven development actually works

Kiro is a fork of Code OSS, the open-source base of VS Code, so the editor itself feels familiar. Your keybindings carry over, and extensions install from Open VSX rather than Microsoft’s marketplace — which means some proprietary extensions are missing, a real annoyance if your workflow depends on one. Sign-in works with an AWS Builder ID, Google, or GitHub; you don’t need an AWS account, and the IDE doesn’t assume you’re deploying to AWS.

The core feature is the spec. When you start one, Kiro generates three Markdown files under .kiro/specs/<feature-name>/:

• requirements.md — user stories with acceptance criteria written in EARS notation (“WHEN a user submits an invalid email, THEN the system SHALL display a validation error”). EARS comes from the systems-engineering world, and it forces edge cases into the open before any code exists.
• design.md — the technical plan: architecture notes, data flow, TypeScript interfaces, sometimes sequence diagrams. Kiro reads your existing codebase to ground this, and in our testing it correctly picked up our existing repository patterns rather than inventing parallel ones.
• tasks.md — a dependency-ordered checklist of implementation steps, each linked back to specific requirements.

Each file is a checkpoint. You edit the requirements in plain Markdown, tell Kiro to refine, and the design and tasks regenerate to match. Then you execute tasks one at a time or let the agent run down the list. The agent runs on Anthropic’s Claude models — Kiro launched on Claude Sonnet 4 and has tracked newer Sonnet versions since, with an automatic model-selection option.

The payoff showed up for us on a feature with genuinely fiddly requirements (a permissions change touching four modules). Writing three documents first felt slow. But the implementation pass needed far fewer corrections than our typical prompt-and-pray sessions in other tools, because the misunderstandings surfaced in requirements.md, where fixing them costs one sentence edit instead of a multi-file revert.

For a one-line bug fix, the ceremony is wrong, and Kiro knows it — there’s a standard “vibe” chat mode that behaves like any other agentic IDE, with autopilot (agent applies changes itself) and supervised (you approve each step) variants.

Hooks, steering, and the automation layer

Two supporting features round out the workflow, and both are quietly useful.

Agent hooks are event-driven automations: when a file is saved or created, a background agent runs a natural-language instruction you’ve defined. The examples AWS pushes are the right ones — update the test file when a React component changes, scan for accidentally committed credentials on save, refresh a README when an API signature changes. Hooks are defined per-project and live in version control, so the whole team inherits them. This is the feature we expect other IDEs to copy first.

Steering files live in .kiro/steering/ and play the same role as a CLAUDE.md or Cursor rules file: persistent project context. Kiro can bootstrap three of them by analyzing your repo — product context, tech stack, and project structure — and you can add your own with conditional inclusion rules (for example, a testing-conventions file that only loads when the agent touches *.test.ts). MCP support is built in, so external tools and docs plug into the same context system.

Pricing: the credit system, post-preview

Kiro’s pricing has been a moving target. The free preview ran for months, an initial tier announcement drew enough backlash that AWS revised it, and the structure that stuck is credit-based. As of this writing: a Free tier with 50 credits per month, Pro at $20/month with 225 credits, Pro+ at $40/month with 450, and a Power tier at $200/month with 2,250. Paid tiers can enable pay-as-you-go overage, billed per credit.

A simple chat interaction costs roughly one credit; complex spec executions cost more, scaling with the work the agent does. That’s the honest version of AI pricing — heavy agentic work costs real money everywhere — but it makes Kiro harder to budget for than Cursor’s request-based tiers, and the Free tier’s 50 credits evaporate in a day or two of real use. Check Kiro’s pricing page before you commit; given the history, the numbers above may shift again.

Where Kiro fits in 2026

Kiro is not the fastest way to get code out of an LLM, and it isn’t trying to be. It’s built for the part of software work that prompt-driven tools skip: agreeing on what to build before building it. Teams that already write design docs will find the spec workflow maps onto their process almost exactly — except now the docs stay synchronized with the code instead of rotting in a wiki.

If your work is mostly rapid prototyping, small fixes, or solo experiments, the spec ceremony will slow you down and a conversational tool remains the better default. The extension-marketplace gap and the pricing churn are real costs too.

Our take: try Kiro on one feature that has genuinely ambiguous requirements — the kind that usually triggers a rewrite. If the requirements-design-tasks loop catches a misunderstanding before implementation, you’ll understand the pitch immediately. If it doesn’t, you’ve spent an afternoon and a handful of free credits to find out.