Amazon launched Kiro internationally on May 7, 2026 — not as a feature update, but as a ground-up replacement for Amazon Q Developer. The timing wasn’t accidental. Spec-driven development is Amazon’s declared answer to a specific and well-documented failure mode: agentic coding without formal structure produces code that works locally but drifts from your architecture, misses edge cases, and falls apart under production load. Kiro is Amazon’s attempt to make that failure mode structurally harder to reach. In this article we walk through how it actually works — the three-phase spec workflow, Agent Hooks, and Steering Files — and how it stacks up against Cursor for teams thinking about adoption.
What is AWS Kiro and what problem does it solve?
AWS Kiro is an agentic IDE built on Code OSS, the open-source base of VS Code. Your existing VS Code extensions, keybindings, and Open VSX-compatible plugins carry across without reinstallation. If your team lives in VS Code, day one will feel familiar.
What Kiro actually changes is the development contract. Where Q Developer and Cursor’s chat mode let you generate code from natural language prompts, Kiro requires structured specifications before any code generation can begin. The IDE makes it structurally difficult to skip that step. The whole workflow is built around the spec, not around the prompt.
Kiro is the direct replacement for Amazon Q Developer. New Q Developer account creation was blocked from May 15, 2026; IDE plugins reach end of support April 30, 2027. From May 29, 2026, the latest coding models — including Claude Opus 4.7 — are available exclusively on Kiro. Teams staying on Q Developer are locked to an older model stack.
Model routing is automatic. Kiro’s auto-router selects across Claude Sonnet, Qwen, DeepSeek, GLM, and MiniMax per task, running on Amazon Bedrock as the unified model plane. You can pin a specific model if consistent behaviour matters more than cost optimisation. Kiro is free during preview — 50 credits per month, no AWS account required for general use.
How does Kiro’s three-phase spec workflow operate?
Kiro requires three sequential documents before any agent writes a single line of code: requirements.md, design.md, and tasks.md. Together these form the spec stack, and they’re included by default in every session.
Phase one: requirements.md. You describe the feature in natural language. Kiro generates structured user stories using EARS Notation — Easy Approach to Requirements Syntax — a formal standard that structures acceptance criteria using consistent WHEN/IF/WHILE sentence patterns. Happy paths, edge cases, failure modes. Precise enough for an agent to implement without guessing your intent.
Phase two: design.md. Once you’ve approved the requirements, Kiro generates a technical design document — architecture decisions, component boundaries, data models, API contracts, sequence diagrams. This is the gate where you’re reviewing architecture coherence, not syntax. The agent cannot proceed until you explicitly approve this document.
Phase three: tasks.md. Kiro breaks the approved design into a numbered list of atomic implementation tasks. Each task maps to a discrete code change that can be independently reviewed and reverted. Agent execution is not fully autonomous — you decide when each individual task runs.
The spec stack goes into version control alongside the code. That gives you a human-readable audit trail of intent, not just implementation — which becomes genuinely useful when a change six months later needs to be understood in context.
One thing worth flagging: a Kiro technical review described the required level of specification detail as “over-specification”. The counterargument from practitioners is that this is exactly the right level of detail for an agent to produce reliable output. Your engineers will need to internalise that the spec authoring phase is the work — not overhead that precedes the work.
What are Agent Hooks and what do they automate?
Agent Hooks are Kiro’s event-driven automation system. Think GitHub Actions or AWS Lambda triggers, but scoped to IDE-level file events rather than CI/CD pipeline events. A Hook fires when a specified file event occurs — save, create, delete, rename — within a defined path pattern. The trigger is local to the developer’s working session, not to the repository pipeline.
In practice, the most common automation patterns look like this: run unit tests for any file touched by an agent run, regenerate API client stubs whenever a service spec changes, and cascade spec edits through dependent consumer specs — the pattern that Digital Applied describes as most reliably justifying the migration cost.
Hooks are defined in YAML configuration files stored in the project repository. They live in the repo, not in personal config, which means they’re versioned, reviewed, and shared across the team like any other infrastructure code.
The failure mode Hooks address is documentation drift and stale tests — the classic “I forgot to update the tests” problem that compounds over time. Redmonk notes that Agent Hooks let you offload routine maintenance tasks from the main coding session, keeping the context window focused on the work at hand.
Hooks and Steering Files are the two sides of Kiro’s persistent project infrastructure. Hooks handle automation. Steering Files handle governance. Both live in the repo, both are versioned, and both operate independently of any individual coding session.
How do Steering Files enforce compliance standards?
Steering Files are Markdown documents stored in the project repository that define standing constraints Kiro must follow during code generation: security standards, naming conventions, error handling patterns, regulatory requirements. They are automatically loaded into every agent interaction — unlike a one-time system prompt, they cannot be accidentally omitted.
That distinction — persistent context versus one-time prompt — is the architectural point worth understanding. Per-developer prompt discipline is fragile at team scale. One developer might remember to include security constraints in their prompts; another won’t. A single reviewed Steering File propagates those constraints across every team member’s code generation sessions without requiring individual discipline.
Typical Steering File contents include security controls (no hardcoded secrets, input validation requirements), coding standards (naming conventions, error handling patterns), and regulatory constraints (data handling rules for GDPR or HIPAA contexts). In an AWS mainframe modernisation case study, Steering Files were used to generate microservice specifications that conformed to organisational standards without per-prompt reminders.
Steering Files complement the spec stack rather than overlap with it. requirements.md defines what to build. design.md defines how to build it. Steering Files define the constraints governing every build — regardless of feature. For teams in regulated industries, Kiro GovCloud deployments can include Steering Files pre-configured with compliance constraints. Full governance treatment is in our regulated industry analysis.
Why did Amazon replace Q Developer with Kiro?
Amazon Q Developer was a conversational coding assistant — chat-first, prompt-driven, no spec mandate. You describe what you want, the assistant generates code, you review and iterate. Amazon’s rationale for replacing it is that developers need AI that understands the entire project — architecture, requirements, tests, and intent. Kiro is that environment. These are two different product classes — agentic IDE versus coding assistant — with fundamentally different design contracts: spec-first versus prompt-first.
The context behind that strategic shift matters. The Register reported on April 29, 2026 that Amazon had instructed all engineers to review AI-generated output following a service disruption traced to an agentic coding session. Amazon classified the events as user errors. The Q Developer EOL announcement followed one day later — and that combination of a company-wide review mandate and an immediate product retirement tells you the concern extended well beyond any single incident. The full incident analysis is in our Amazon internal probe article.
The strategic reasoning, independent of the incident, is fairly straightforward: if the root cause of agentic coding failures is insufficient specification rather than insufficient AI capability, then enforcing the spec at the tooling level is a more reliable fix than asking teams to self-enforce it. Kiro embeds that enforcement in the IDE — and in doing so, it represents one of the clearest vendor implementations of spec-driven development as an engineering discipline.
For teams currently on Q Developer: the migration is not a tool swap but a workflow adoption. VS Code users get a profile import on first startup. JetBrains users get a CLI-based integration via ACP — not a native plugin, a workaround. Visual Studio and Eclipse users have no native Kiro plugin at all. The editor constraint is a real migration consideration. Don’t treat it as a footnote.
How does Kiro compare to Cursor for engineering team adoption?
Cursor, built by Anysphere, is the most widely adopted AI IDE in 2026. Its Plan Mode creates a detailed implementation plan before any code is written. Project rules add persistent context. The two tools target overlapping problems with very different philosophies: Cursor treats code as the primary artefact and makes AI assistance feel like an enhanced keyboard shortcut. Kiro inverts that order, treating the spec as source of truth and code as a build artefact.
The practical differences come down to four dimensions.
Spec mandate. Kiro requires requirements.md, design.md, and tasks.md before code generation. Cursor’s Plan Mode generates a plan but doesn’t enforce review gates or produce versioned spec artefacts. Cursor’s spec support is not native to its architecture the way Kiro’s is — no built-in spec lifecycle, no drift detection, no living-spec synchronisation.
Editor portability. Kiro is Code OSS-only. JetBrains works via ACP/CLI — a workaround, not a native experience. Visual Studio and Eclipse have no path at all. Cursor supports JetBrains and other integrations via extensions. For teams with JetBrains-heavy stacks, this needs assessing before you pilot Kiro, not during.
Vendor integration depth. Kiro integrates natively with AWS CodeCatalyst for source control, pull requests, and CI pipelines. IAM integration is built in. Cursor is cloud-agnostic. Teams on non-AWS infrastructure should weigh that integration depth as a dependency, not a feature list item.
Team adoption ramp. Moving a Cursor or VSCode team to Kiro is “less about tooling and more about adopting spec-first review culture, which is where most migrations succeed or stall.” Cursor’s gradual on-ramp is lower-friction for teams mid-migration from unstructured AI coding. Kiro’s spec mandate is higher-friction upfront — but once it’s internalised it produces more consistent output across larger teams.
Many engineering teams end up running Cursor for day-to-day development and Kiro for long-running AWS-native services — complementary rather than mutually exclusive. AWS-native teams on greenfield projects benefit from Kiro’s integration depth and spec enforcement. Multi-cloud or JetBrains-heavy teams will find Cursor’s portability more practical. See how Kiro fits in the broader SDD tool landscape and GitHub SpecKit as the primary open-source alternative for additional comparison points.
What does Kiro GovCloud mean for regulated industry teams?
AWS GovCloud (US) is an isolated AWS infrastructure region built to meet US government data residency, ITAR, and FedRAMP compliance requirements. Kiro GovCloud is available in both GovCloud (US-West) and GovCloud (US-East).
For teams that can’t use standard commercial cloud AI tooling — US federal contractors, defence-adjacent software shops, HealthTech and FinTech organisations with strict data sovereignty requirements — GovCloud deployment means AI-generated code and the associated spec artefacts never leave a compliant data boundary. Steering Files can be pre-configured with agency-specific or regulatory compliance constraints.
A few meaningful constraints apply relative to commercial Kiro. Auto model selection is disabled — Claude Sonnet 4.5 is the default. The VS Code plugin is not available; users access Kiro through the standalone IDE or CLI. And GovCloud is a US-region construct — it does not directly address EU data sovereignty. Teams under GDPR or EU AI Act obligations need to treat that as an open question. The full governance analysis — EU AI Act compliance matrix, audit trail architecture, and regulated industry adoption patterns — is in our dedicated governance article.
How do you evaluate Kiro for your organisation?
Start with infrastructure context, not the feature list. Kiro’s value proposition is strongest for teams already on AWS. CodeCatalyst integration, IAM, and GovCloud availability are meaningful differentiators for AWS-native teams — and largely irrelevant for everyone else. If you’re not already on AWS, the evaluation calculus shifts substantially.
Next, audit your editor ecosystem before you pilot. If more than a fifth of your engineering team is on JetBrains or other non-VS Code environments, Kiro’s editor constraint creates adoption friction that needs solving before rollout.
If the infrastructure and editor checks pass, design the pilot carefully. Pick one bounded greenfield feature — not a brownfield migration. Run one or two engineers through the full three-phase spec workflow for two to four weeks. The harder shift is cultural: specs become the primary review surface, which reshapes how teams plan, split tasks, and sign off on changes. Teams with strong RFC or ADR practices will adapt faster. Teams with no formal spec habit will need process change management alongside tool adoption.
Know your exit ramps before you start. If the pilot team finds the spec gates valuable but the VS Code constraint prohibitive, GitHub SpecKit — IDE-agnostic and open-source with 93,000+ stars as of May 2026 — provides a compatible workflow without the editor lock-in. If the spec mandate feels heavy for your team’s current maturity, Cursor’s Plan Mode is the lowest-friction entry point to spec-first thinking. Both are legitimate paths rather than failures to adopt Kiro.
The relevant question is whether your team needs enforced spec gates or has the discipline to self-enforce. The answer to that shapes which tool fits — and which cultural investment is actually required.
Frequently Asked Questions
What is the difference between Kiro and Amazon Q Developer?
Q Developer was a conversational coding assistant — chat-first, prompt-driven, no spec mandate. Kiro is an agentic IDE that requires formal spec documents before generating code. Different product classes, not version iterations. New Q Developer signups were blocked from May 15, 2026; IDE plugins reach end of support April 30, 2027.
Does Kiro work with JetBrains IDEs?
Kiro works in JetBrains through JetBrains AI Assistant via the Agent Client Protocol (ACP) — a CLI-based integration, not a native plugin. Visual Studio and Eclipse have no path at all; users must switch to the standalone Kiro IDE or Kiro CLI. Assess that constraint before piloting.
What is EARS Notation and why does Kiro use it?
EARS — Easy Approach to Requirements Syntax — is a formal requirements-writing standard that structures user stories using consistent WHEN/IF/WHILE sentence patterns, ensuring acceptance criteria cover happy paths, edge cases, and failure modes. Kiro uses EARS to generate requirements.md content that is precise enough for agents to implement without ambiguity.
Can I use Kiro with models other than Claude?
Kiro’s default auto-router combines Claude Sonnet, Qwen, DeepSeek, GLM, and MiniMax, selecting the optimal model per task. You can pin a specific model for consistent behaviour. In AWS GovCloud (US), auto model selection is disabled; Claude Sonnet 4.5 is the default.
How do Agent Hooks differ from GitHub Actions?
GitHub Actions are CI/CD pipeline triggers that fire on repository events — push, pull request, merge. Agent Hooks are IDE-level triggers that fire on file-system events within the developer’s local working session — save, create, edit. They operate at different points in the development cycle and complement rather than replace each other.
How long does the three-phase spec workflow take compared to just starting to code?
No controlled time comparison exists. The overhead is front-loaded — requirements.md and design.md authoring adds time per feature. Proponents claim this is recovered in reduced review cycles and lower debugging overhead. Measure it in your own pilot rather than assuming the trade-off works in your context.
Is Kiro suitable for brownfield codebases?
Kiro is designed primarily around greenfield feature development. For brownfield migration, OpenSpec by Fission AI is explicitly brownfield-first, using delta markers (ADDED/MODIFIED/REMOVED) to track changes in existing code. Kiro can be applied to brownfield features but offers no native brownfield tooling.
What is a Steering File and how is it different from a requirements.md file?
A Steering File defines standing constraints that apply to every code generation session — security standards, naming conventions, regulatory requirements. requirements.md defines what a specific feature should do. They operate at different abstraction levels: Steering Files are persistent project-wide governance, requirements.md is per-feature specification.
Does Kiro integrate with AWS CodeCatalyst and existing AWS pipelines?
Kiro integrates natively with AWS CodeCatalyst for source control, pull requests, and CI pipelines. Hooks can trigger CodeCatalyst workflows without custom glue. IAM integration is built in. Meaningful advantage for AWS-native teams; meaningful lock-in for multi-cloud organisations.
How does Kiro handle security scanning — is it built in or via Agent Hooks?
Via Agent Hooks, not a built-in static analysis engine. A Hook triggers a security scan agent when new dependencies are added. It does not run automatically — teams configure it as part of project setup.
What happened to teams using Amazon Q Developer?
Q Developer IDE plugins reach end of support April 30, 2027; existing customers retain access through the transition window. Amazon’s guidance is to migrate to Kiro — a workflow adoption, not a tool swap. It is a substantive process change, not a substitution.
How does Kiro compare to GitHub Copilot?
GitHub Copilot is an AI coding assistant — autocomplete and chat — with no spec mandate. GitHub’s spec-first tooling is GitHub SpecKit, a separate open-source framework. The closer comparison is Kiro vs. SpecKit or Kiro vs. Cursor. Comparing Kiro to Copilot conflates two different product categories.
