Kiro: an agentic IDE built around specs, steering and parallel agents
Kiro is an agentic IDE that works alongside you from prototype to production.
At a glance
- What is it?
- Kiro is an agentic AI development platform from Amazon that runs across IDE, CLI, Web, Mobile and Crew surfaces. This review covers what it actually does, how to install it, and where it stops being the right tool.
- Who is it for?
- Adopt Kiro if you want requirements, design and tasks captured as reviewable specs before an agent writes code, and you are willing to accept a hosted product whose source is not in the repository. Skip it if you need a fully open source toolchain or on-premise deployment, because the repository at kirodotdev/Kiro holds only the issue tracker and triage automation.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem Kiro solves, and who it is actually for
Most coding assistants start from a prompt and produce code. The failure mode is familiar: the agent implements something plausible that does not match the requirement, and nobody notices until review. Kiro's answer is to make the requirement explicit first. The README describes turning prompts into executable specs, then running Requirements Analysis to find contradictions, ambiguities and gaps before coding begins. That ordering is the product's whole thesis.
The intended user is a developer or a team working in a large codebase where a single agent pass is not enough. The README lists parallel agents and cloud sessions in managed sandboxes as the mechanism for that scale, and mentions carrying the same project context across IDE, CLI, Web, Mobile and Crew. A solo developer editing one file gets little from the spec layer. A team coordinating multi-repository work gets the most, which is also why the enterprise onboarding, governance and usage monitoring pages exist.
One thing to be clear about before anything else: this repository is not the product. The README states plainly that it is the public issue and feedback tracker, that the Kiro product source code is not hosted here, and that the repository also contains the automation used to triage and manage its GitHub issues. The top-level entries match that description: .github/, .kiro/, assets/, docs/, scripts/ and the usual community files. If you arrived expecting to read the agent harness, you will not find it.
One agent harness across IDE, CLI, Web, Mobile and Crew
The architectural claim is that one unified agent harness powers every Kiro surface, so specs, steering, permissions, hooks, MCP servers and custom agents follow a project across workflows. That is a configuration-portability argument rather than a runtime one: the artifacts you author are the unit that travels, not the process.
The README assigns each surface a job. The IDE is for local development with editor integration, chat, specs and hooks. The CLI is for terminal-native work, headless automation and CI/CD. Web is for delegating multi-repository tasks in isolated cloud sandboxes. Mobile is for monitoring tasks, reviewing pull requests and working with agents while away. Crew is described as a persistent open-source development workspace with memory, scheduling and multi-channel access, and it lives in a separate repository, kirodotdev/KiroCrew.
The control mechanisms are where the design gets specific. Permissions set access boundaries. A .kiroignore file keeps sensitive paths out of context, which is the same idea as a gitignore but applied to what the agent can read. Checkpoints and rewind let you inspect or undo changes. Hooks react to agent events, Powers add on-demand tools and knowledge, and MCP connects external systems. Steering supplies project conventions, and Agent Skills package reusable expertise.
Specs are the part worth understanding properly. They structure requirements, design decisions and implementation tasks, and correctness is handled with property-based testing: requirements become executable properties that are exercised across generated inputs. That is a meaningfully different bet from example-based tests, and it is the feature most likely to divide opinion, because writing properties is harder than writing examples.
Installing Kiro and running a first spec-driven task
There is no package to install from this repository. The README points to the download page for the IDE and to a separate CLI setup page for terminal use, so the first step is choosing a surface. The IDE download lives at kiro.dev/downloads/, and the CLI instructions are at kiro.dev/docs/cli/setup/. Follow the platform-specific instructions on those pages rather than any command reproduced here, because the README does not inline the installer.
After installing, the documented path is authenticate, then build your first project. The README links both steps under Get started, and also points to a learn-by-playing guide for people who prefer to explore before committing a real codebase. Authentication happens against a Kiro account; account settings, including billing, live at app.kiro.dev/settings/account.
Project-level configuration is file-based, which is the part you can inspect and commit. The .kiro/ directory at the repository root is the convention, and the README documents .kiroignore for excluding sensitive paths from agent context. The README does not print the contents of a .kiroignore file, so check the .kiroignore documentation page for the pattern syntax before relying on a glob behaving exactly like gitignore.
For CI, the CLI is the surface to use, since the README names headless automation and CI/CD as its purpose. The documentation pages for the CLI setup are where the invocation details live; the README does not publish a command line here, and inventing one would be worse than sending you to the setup page.
If you want to try the spec workflow without touching a real repository, the learn-by-playing guide is the lowest-risk entry point. It exists precisely for that.
Where Kiro is the wrong tool
The clearest limitation is structural. The product source code is not in this repository, so you cannot audit the agent harness, fork it, or self-host it from what is published here. The repository is an issue tracker plus triage automation. For anyone whose adoption criteria include reading the code that will run against their source tree, that is a stopping point, not a detail.
Cloud sessions are marked as currently in Preview. Preview status means the feature can change or break, and teams with strict change-control requirements should treat cloud delegation as untested ground until that label disappears. The README does not document a rollback path for cloud sessions, and it does not state what happens to a sandbox when a session is abandoned.
Spec-driven development has its own cost. Writing requirements, design and tasks before coding is overhead, and Requirements Analysis only pays for itself when the requirements are non-trivial. For a one-line fix or an exploratory spike, the spec layer is friction. The same applies to property-based testing: it catches classes of bug that examples miss, but only if someone can express the requirement as a property, and not every requirement can be.
Finally, this is a hosted platform with pricing, subscriptions and enterprise governance. That is normal for the category, but it means the tool is not a drop-in replacement for a local-only assistant, and the README does not describe an offline mode. Check the pricing page before you build a workflow around it.
How Kiro differs from Cursor and GitHub Copilot
Cursor and GitHub Copilot are the obvious comparisons, and the difference is where the artifact lives. Both are primarily editor-centric assistants: you work in the editor, the assistant responds to what is in front of you, and the durable output is code plus whatever chat history you keep. Kiro's durable output is intended to be the spec, with the code following from it. That is why Requirements Analysis and property-based correctness sit in the feature list rather than chat quality.
The second difference is surface count. Kiro documents five surfaces sharing one harness, including a mobile client for reviewing pull requests and a cloud sandbox for multi-repository delegation. Copilot and Cursor are editor-first products with adjacent CLI offerings; neither, as described in their own documentation, is positioned around a persistent workspace with memory and scheduling.
The third is governance. Kiro documents an enterprise onboarding path, organization-wide governance controls and usage monitoring. That is aimed at buyers who need to answer who used what and with which permissions, a question a single-developer editor assistant does not try to answer.
The honest counterpoint: Kiro asks you to learn a methodology. Specs, steering, skills, powers, hooks and MCP are six concepts before you write a line of code. If your team will not adopt the spec discipline, the extra surface area buys you nothing over an editor assistant, and you have paid the learning cost for free.
Licence, maintenance and upgrade cost
The repository does not state a licence in what is published, and the README's only legal line is the copyright notice for Amazon.com, Inc. or its affiliates. The CODE_OF_CONDUCT.md follows the Amazon Open Source Code of Conduct, which governs community behaviour rather than the code grant. Because the product source is not hosted here, there is no source licence to reason about in this repository at all: what you are adopting is a hosted service under its own terms, and those terms live on the Kiro site, not in this repo. Treat the absence of a licence file as a question to resolve with the vendor, not as permission.
Maintenance of the repository itself is current: the last push was on 2026-09-15. No releases were retrieved, which fits an issue tracker that ships no artifacts. The upgrade cost that matters is not in this repo. It is the cadence of the hosted product, tracked on the changelog page, plus the Preview status of cloud sessions. Teams that pin tool versions will find less to pin here than they are used to.
Support routing is documented and worth noting because it is unusual. Product questions go to the documentation or FAQs, community help goes to the Kiro Discord server, billing goes to Kiro account settings, and a suspended account is handled through AWS support contacts. Security issues go to the AWS/Amazon vulnerability reporting page, with an explicit instruction not to open a public GitHub issue.
Editorial conclusion
Adopt Kiro if you want requirements, design and tasks captured as reviewable specs before an agent writes code, and you are willing to accept a hosted product whose source is not in the repository. Skip it if you need a fully open source toolchain or on-premise deployment, because the repository at kirodotdev/Kiro holds only the issue tracker and triage automation. Before committing a team, verify four things: the installation and authentication path for your platform, whether cloud sessions being in Preview is acceptable for your workflow, the current pricing and enterprise governance terms, and how .kiroignore and the permissions model map onto your sensitive paths.
Frequently asked questions
Is Kiro from AWS?
The README carries a copyright notice for Amazon.com, Inc. or its affiliates, and security reports are routed to the AWS/Amazon vulnerability reporting page. Support for suspended accounts goes through AWS support contacts.
What company is Kiro?
The repository is kirodotdev/Kiro and the README's copyright line names Amazon.com, Inc. or its affiliates. The product site is kiro.dev.
How do I use kiro?
The README's Get started path is install Kiro, authenticate, then build your first project, with a learn-by-playing guide as an alternative entry point. Installation instructions are on the download page for the IDE and the CLI setup page for terminal use.
Why is Amazon Kiro called Kiro?
The README does not explain the origin of the name. It only uses Kiro as the product name across the IDE, CLI, Web, Mobile and Crew surfaces.
Community notes