Most AI coding tools share the same basic philosophy: you type a prompt, they generate code, you fix what breaks. Amazon’s new IDE disagrees with that premise at a fundamental level.
Kiro — launched in May 2026 as a ground-up replacement for Amazon Q Developer — forces you to stop and write a specification before any code gets generated. Requirements document. System design. Task list. All AI-assisted, all reviewable, and none of them optional. Only after you’ve agreed on what you’re building does Kiro start writing code.
That’s either exactly what your team needs, or an infuriating amount of ceremony for a simple feature. Probably both, depending on the day.
I’ve been running Kiro for about a month across a handful of real projects: a Lambda-based API, a React dashboard backed by DynamoDB, and a couple of internal tooling scripts. Here’s what I actually think.
How the Spec Workflow Works
The core Kiro concept is the spec — a set of three structured documents generated before any implementation begins:
- Requirements document — user stories, acceptance criteria, explicit out-of-scope declarations
- System design — architecture decisions, data models, API contracts
- Task list — granular implementation steps derived from the design
You start by describing a feature in plain English. Kiro drafts all three. You review, edit, push back, regenerate sections. When you’re satisfied, you approve. Then it codes.
The mechanism sounds like added bureaucracy until you experience what it’s actually catching. I spotted three cases in a single project where Kiro’s interpretation of my prompt diverged from what I meant — all of them at the requirements phase, before a single line of code was written. “User can filter by date” turned into a pretty heated conversation between me and the AI about whether that meant created-at, updated-at, or an event date field on a separate table. We resolved it in the spec. In Cursor, I would have resolved it two hours into implementation.
The trade-off is speed. A feature that Cursor would ship in 45 seconds takes 5-10 minutes in Kiro if you actually engage with the spec. Whether that’s worth it depends entirely on what you’re building and how often you’ve been burned by building the wrong thing.
Steering Documents: The Persistent Memory Cursor Doesn’t Have
Beyond specs, Kiro has two other features that I think are genuinely underappreciated in the early coverage.
Steering documents are project-level context files — a persistent system prompt for your codebase. Your architectural constraints, team conventions, the things every agent session should always know. Every code generation automatically includes your steering docs as context. No more typing “we use dependency injection, don’t use singletons, all async functions return Result types” into every new chat window.
This matters a lot for teams. The institutional knowledge problem with AI coding tools is real: every session starts from zero, and the AI will happily generate code that violates patterns your team spent months settling on. Steering docs solve that at the IDE level rather than requiring discipline from every developer on every session.
Hooks are Kiro’s automation layer. They fire on IDE events and trigger predefined agent actions: save a file → run an agent that checks for spec drift, complete a task → surface test failures inline. The goal is to catch problems during development rather than after a commit. I have a hook that alerts me when my implementation starts diverging from the system design document. It’s caught me taking shortcuts twice. I can’t prove it saved me rework, but I think it did.
Neither of these features exist in Cursor or Claude Code in this form. They’re Kiro-only, and they’re worth considering seriously if you’re evaluating whether to switch.
Kiro vs Cursor: Speed vs Structure
Cursor is fast. That’s what you feel the moment you switch back from Kiro. Sub-30-second completions, up to 8 parallel agents, instant inline suggestions. Multi-model support — OpenAI, Anthropic, Google, xAI — with the ability to switch models mid-session. A 1M+ subscriber community that has built years of rules templates, extensions, and shared context.
Kiro wins on a different axis: depth. For a feature that touches five files, involves a schema change, and has non-obvious edge cases, the spec-driven process surfaces problems earlier. Cursor’s approach — generate aggressively, fix iteratively — works fine on simple tasks and starts leaking time on complex ones when the generated code has to be unwound and rewritten because the initial direction was wrong.
Here’s a concrete comparison from my own usage. A three-file API endpoint: 20 minutes in Cursor, 35 minutes in Kiro. A nine-file feature with three database tables: I estimate Cursor would have taken 4.5+ hours; Kiro took 3.5 hours, largely because I caught a schema problem in the requirements phase that would have required a data migration halfway through implementation.
The pattern I’ve settled on: Kiro saves time on features that are complex enough to go wrong. Cursor saves time on everything else. The ratio shifts depending on what you’re building.
One thing to flag honestly: Kiro’s inline code completion inside files is noticeably slower than Cursor’s. The keystroke-level assistance that Cursor does well, Kiro doesn’t match. If you rely heavily on real-time inline suggestions while you type, you’ll feel this gap. Kiro is stronger in the chat-based generation workflow, not the autocomplete workflow.
Kiro vs Claude Code: CLI vs IDE
Claude Code is a terminal-first tool. You run it from the command line, it reads your codebase, you describe tasks, it edits files autonomously. No IDE required.
Comparing it to Kiro is a bit apples-to-oranges. Claude Code is better at fully autonomous execution — the kind of long, multi-step task where you describe a goal at a high level and come back to the result. It’s also better for developers with a heavily customized editor setup who don’t want to move to a new IDE.
Kiro is better for structured, collaborative work. The spec review process assumes you want to be in the loop before code is written, which is the right assumption for most production feature work and the wrong assumption when you want to delegate a complete task and walk away.
The underlying model is the same either way: Kiro runs Claude through Amazon Bedrock. You’re not getting meaningfully different code quality between them — the difference is process and interface.
I’ve settled into a rough split: Claude Code for exploratory work, complex refactors, and tasks I want to delegate autonomously. Kiro for new features on production codebases where I want structure.
The AWS Integrations Are Real
Kiro is clearly built for the AWS developer. The platform integrations reflect it:
- Native CloudWatch log exploration without leaving the IDE
- IAM policy generation derived from what your system design actually requires
- Dedicated MCP servers for Lambda, DynamoDB, S3, and core services
- GovCloud compliance (significant for government contractors and regulated industries)
The IAM generation is the piece I’d call out specifically. Least-privilege IAM policies are tedious to write and easy to get wrong. Kiro can look at your system design spec — which defines what your Lambda function needs to access — and generate policies that match. Not perfectly, but close enough that the review pass is fast instead of starting from scratch.
Outside of AWS projects, these integrations are idle. Kiro works fine on non-AWS stacks, but you’re paying for features you’re not using. That should factor into your evaluation if you’re on GCP, Azure, or multi-cloud.
Pricing
The free tier covers limited interactions per month — usable for evaluation, not sustainable for real work. Pro is $19/month.
You sign in with an AWS Builder ID, which is free and requires no credit card or active AWS account. The signup friction is low. Compare that to setting up full AWS credentials for other tooling, and it’s a relief.
Cursor is $20/month. The price difference is not the deciding factor here. If you’re already paying for Cursor and want to evaluate Kiro, the free tier is a reasonable starting point before committing to paying for both — or switching.
Who Should Switch (And Who Shouldn’t)
The honest breakdown:
Kiro is worth trying if you’re building primarily on AWS and want native tooling, your team works on features complex enough that building the wrong thing is a real risk, you’ve been burned by implementation drift between what was discussed and what was built, or your org has compliance requirements that GovCloud support addresses.
Stay on Cursor if you need maximum speed for everyday coding, you work across multiple cloud providers, you want model flexibility (Cursor’s multi-model approach is genuinely useful when different tasks call for different models), or your work skews toward quick scripts and prototypes rather than multi-file production features.
Keep Claude Code if you prefer CLI-native tools, you want fully autonomous “describe it and come back” execution, or you’re already in a terminal-first workflow that you’d rather not change.
There’s a legitimate case for running Kiro alongside Cursor rather than instead of it: Kiro for new feature development, Cursor for everything else. $39/month total isn’t trivial, but it’s reasonable for a professional dev toolchain if both tools are earning their keep.
What Surprised Me
I expected the spec workflow to annoy me. I use these tools for speed, and a mandatory planning phase seemed like friction added in the wrong place.
What I found is that the spec step is most annoying for simple features and most valuable for complex ones — which is exactly the right calibration. Kiro generates lightweight specs for small changes and detailed ones for larger features. That proportionality isn’t perfect, but it’s good enough to make the workflow feel appropriate rather than bureaucratic most of the time.
The spec step also surfaces something subtler: it forces you to articulate what you’re building before you’re influenced by what the AI generates. That sounds obvious, but in practice I’ve caught myself starting to rationalize AI-generated directions because it was easier than pushing back. The spec review happens before any code exists, which means you’re evaluating the plan on its own merits.
Kiro launched in May 2026, and it shows. The ecosystem around Cursor is years deeper — community rules, extensions, shared patterns. Kiro’s MCP support and hook ecosystem are newer and thinner. That gap will close, but it’s real today.
Amazon Kiro is a serious product with a distinct point of view: the problem with AI coding isn’t code quality, it’s the absence of structure before you get there. For teams that have watched good sprints derail because the AI generated something confidently wrong, that point of view will resonate. For solo developers doing quick iterations on simple problems, it adds ceremony without enough payoff.
The free tier is easy to sign up for. If you’re AWS-native and doing production feature work, spend a week with it. It’s a genuinely different way of working — and worth understanding even if you decide to stay where you are.