AWS Kiro - what the agentic IDE is and where it fits in your SDLC
If you are weighing where AI genuinely helps across the software lifecycle before committing to a tool, start with our article on AI in the SDLC. Kiro is one answer to the “AI in the IDE” part of that picture. Here we focus on the tool itself.
Want to try Kiro in your organisation? We can help you fund the proof of concept.
As an AWS Partner, Devopsity can secure proof-of-concept funding for teams that want to evaluate Kiro on a real workload rather than a toy demo. We help you scope a focused PoC, set it up with the right steering and guardrails, and measure whether spec-driven development actually pays off for your team. Talk to us about funding your Kiro PoC.
What is AWS Kiro?
Kiro is an agentic IDE from AWS, built on the open-source VS Code base (Code OSS) and powered by Anthropic’s Claude models alongside a selection of open-weight models. It reached general availability in 2026 and is positioned by AWS as the official successor to Amazon Q Developer for IDE and agentic coding. Where most AI coding assistants start from a chat prompt, Kiro starts from a specification: you describe what you want, Kiro turns it into structured requirements and a design, and only then writes the code.
One thing to be clear about before going further: Kiro is a separate product with its own subscription, not a rebrand of Amazon Q Developer. That distinction matters for teams already on Q Developer, and we come back to it in its own section below. First, what Kiro actually does.
Sources we reference: the Kiro site and documentation and the AWS introduction to Kiro.
The problem Kiro solves
Prompt-first AI assistants are fast at producing code and slow at producing the right code. You get a working snippet, but the requirements live only in a chat history, the design decisions are implicit, and nobody can review the intent separately from the implementation. On a one-file script that is fine. On a team codebase it is how AI quietly adds risk, which is the exact failure mode we described in AI in the SDLC.
Kiro’s answer is to make the specification a first-class, reviewable artefact. The requirements and the design are written down, in the repository, before the code exists. That turns “the AI wrote something” into “the AI wrote something against an agreed spec we can review” - which is the difference between a demo and a change you can ship.
How Kiro is built: the core building blocks
Kiro is organised around a small set of primitives that have no direct equivalent in a prompt-first assistant. These are the parts worth understanding before you judge it.
| Building block | What it does |
|---|---|
| Specs | The spec-driven core. A feature becomes structured requirements, then a design document, then an implementation task list - each reviewable before the next step runs. |
| Hooks | Event-driven automations that trigger an agent in the background on actions like file save, create, or delete, or on a manual trigger - catching missed work or completing boilerplate as you go. |
| Steering | Persistent project context (conventions, stack, standards) that the agent reads on every interaction, so guidance does not have to be re-pasted into each prompt. |
| Subagents | Specialised agents you can delegate scoped tasks to, each with its own instructions and tool access. |
| Powers / MCP | Packaged capabilities and Model Context Protocol integrations that connect Kiro to external tools and AWS services. |
The through-line is that Kiro externalises things prompt-first tools keep implicit: the requirements (specs), the project rules (steering), and the automation (hooks). That is what AWS means by “spec-driven” - the intent lives in the repository, not in a chat scrollback.
Deciding whether Kiro fits your team's SDLC?
Book a free 30-min call
Kiro and Amazon Q Developer: successor, not rebrand
This is the section most relevant to teams already inside the AWS ecosystem, and the part a lot of coverage gets slightly wrong.
AWS has named Kiro the official successor to Amazon Q Developer for IDE and agentic coding. Concretely:
- Amazon Q Developer IDE plugins reach end of support on 30 April 2027, with new sign-ups already blocked. Teams on the Q Developer IDE experience have a defined runway, not an open-ended one.
- Kiro is a ground-up product, not a renamed Q Developer. Its spec/hook/steering/subagent/powers model has no direct equivalent in Q Developer, and it requires its own separate subscription.
- The switch is smoothest if you are already on VS Code, since Kiro is built on the same Code OSS base. Teams relying on Q Developer plugins for JetBrains, Eclipse, or Visual Studio should plan the move deliberately rather than assume a drop-in replacement.
None of this is a reason to rush. But it does mean “we already have Q Developer” is not a reason to ignore Kiro - the two are on a migration path, not a long coexistence. We will cover that migration in a dedicated article on building an AI-driven SDLC on AWS with Kiro and Q Developer.
Pricing: the credit model
Kiro uses a credit-based model with a perpetual free tier and several paid tiers, from an individual Pro plan up to higher-capacity Power and team plans. The free tier includes a monthly credit allowance with access to Claude Sonnet and a set of open-weight models under rate limits; paid tiers raise the credit allowance and unlock premium models.
The practical point for a team is not the entry price but the unit of consumption: Kiro bills by credits tied to agent interactions (spec and vibe requests), so cost scales with how heavily you lean on the agent, not with a flat per-seat number alone. That makes a small pilot cheap and a heavy, agent-driven workflow something you should model before rollout.
Kiro vs Cursor vs GitHub Copilot
All three put an AI agent in the editor; they differ in philosophy.
| Kiro | Cursor | GitHub Copilot | |
|---|---|---|---|
| Core model | Spec-driven: requirements and design before code | Prompt- and edit-driven, fast in-editor agent | Completion- and chat-driven, deep GitHub integration |
| Base | VS Code (Code OSS) | VS Code fork | VS Code, JetBrains, and others |
| Best fit | Teams wanting reviewable intent and AWS-native workflows | Individuals and teams wanting raw in-editor speed | Teams standardised on GitHub |
| Ecosystem pull | Native AWS integration (IAM, Lambda, Bedrock, and more) | Model-flexible, vendor-neutral | GitHub-native |
The honest summary: if your advantage is raw editing speed for an individual developer, Cursor is hard to beat; if you live inside GitHub, Copilot has the shortest path. Kiro’s differentiator is the spec-driven workflow and native AWS integration - it is the strongest fit when you want the intent of a change to be reviewable and when your infrastructure already lives on AWS.
When Kiro is worth adopting, and when it is not
| Kiro fits when... | Kiro is not the obvious pick when... |
|---|---|
| Your infrastructure is on AWS and you want native IAM/Lambda/Bedrock integration | You are multi-cloud or cloud-neutral and want to avoid AWS-leaning tooling |
| You are already on Amazon Q Developer and need a migration path before April 2027 | You depend on Q Developer plugins for JetBrains, Eclipse, or Visual Studio |
| You want AI-written changes to be reviewable as specs, not just diffs | Your workflow is single-file scripting where a spec step is overhead |
| Your team is on VS Code already (shortest switch) | Raw per-developer editing speed is the only thing you are optimising for |
A simple rule: Kiro is strongest when the process around AI-written code matters - review, governance, repeatability - and when AWS is your home. For a solo developer chasing the fastest possible edit loop, a lighter prompt-first tool may still win.
Where Kiro fits in the AI SDLC
Adopting an agentic IDE changes how code enters your pipeline, which means it also changes what your pipeline has to check. A spec-driven tool helps on the way in - intent is reviewable - but it does not remove the need for guardrails on the way out. AI-written code still needs the same discipline we describe in shipping AI-generated code safely and the review practices in AI code review in CI/CD.
There is also a scale question. One developer with an agentic IDE is a productivity story. A whole organisation running agents, subagents, and background hooks is a governance story - the same agent sprawl pattern we see on the infrastructure side, now inside the development workflow. Deciding on a shared way to adopt Kiro, with steering and standards agreed once rather than per-developer, is what keeps it a productivity story.
When it is worth bringing in an external partner
- Standardising Kiro across a team. Shared steering files, conventions, and hook policies are worth designing once, not reinventing per developer.
- Migrating off Amazon Q Developer. The April 2027 end-of-support date gives a runway; using it well (especially off VS Code) benefits from a planned path.
- Fitting Kiro into an existing pipeline. Spec-driven on the way in still needs guardrails on the way out - CI/CD, review, and security gates.
- Governing agentic development at scale. Many developers, many agents, no shared policy is the development-side version of agent sprawl.
Summary
Kiro is AWS’s bet that the future of AI coding is spec-driven, not prompt-first, and it is the designated successor to Amazon Q Developer for IDE work.
Three things to remember:
- Kiro is spec-driven, not prompt-first. Its core primitives - specs, hooks, steering, subagents, powers - externalise the requirements and the project rules into the repository, so AI-written changes are reviewable as intent, not just as diffs.
- It is Amazon Q Developer’s successor, not its rebrand. Q Developer IDE plugins reach end of support on 30 April 2027; Kiro is a separate product with its own subscription, smoothest to adopt from VS Code.
- Adopting it is a productivity story for one developer and a governance story for an organisation. Spec-driven helps on the way in; you still need CI/CD guardrails on the way out, and a shared standard to avoid agent sprawl inside the workflow.
Deciding whether Kiro fits your team's SDLC?
Book a free 30-minute call. We help teams adopt Kiro deliberately - shared steering and standards, a migration path off Amazon Q Developer, and the CI/CD guardrails that keep AI-written code safe to ship.
