Kiro IDE Review 2026: Pricing, Specs, Tests, and What It Can't Prove

Kiro is the most structured agentic IDE available in 2026, the structure is real, and a completed spec is still not evidence that your app works. Requirements, design, and implementation tasks land in your repository as files anyone can read, and Kiro can now derive property-based tests from those requirements and run them. None of that describes the deployed system.

Kiro’s clearest advantage is that path from an idea to repository-based requirements, design, and implementation tasks. It also documents steering files, automated hooks, supervised changes, and property-based testing. Those controls make AI-assisted development easier to inspect. They do not establish that the resulting application is secure, reliable, or ready for production.

Kiro IDE review: the short verdict

Kiro is worth considering when a team wants requirements, architecture decisions, and implementation tasks stored beside the code instead of dispersed across prompts. The documented workflow is more inspectable than an unstructured chat session, and Kiro now includes real testing capabilities that earlier descriptions of the product miss.

Its strongest documented features still depend on human choices. A vague requirement can produce a weak spec. Property-based tests are optional. An agent hook only enforces the action it was configured to run. Supervised mode adds a review step for file changes, while trusted shell commands and readable workspace secrets remain separate risks. Kiro can support a production-readiness process, but the IDE cannot supply the whole process by itself.

Evidence note: This Kiro IDE review was verified against Kiro’s public product documentation on August 6, 2026, with the pricing page and FAQ rechecked on August 16, 2026. It is a documentation-based assessment, not a hands-on test. It makes no claims about response quality, speed, credit consumption, generated-code quality, or reliability in real projects. Where hands-on detail appears below, it is attributed to the reviewer who reported it, with a date.

What changed in Kiro since most reviews were written

The Kiro reviews most people read are dated July to December 2025. Every one of them describes a public preview build. Five things have changed since, and each of them moves a buying decision.

Kiro reached general availability on November 17, 2025, after a four-month public preview. AWS has since named it the official successor to Amazon Q Developer: new Q Developer signups closed May 15, 2026, and its IDE plugins and paid subscriptions stop getting support on April 30, 2027. If you are reading a review that predates November 2025, it is describing a different product with different prices and no correctness testing.

How Kiro compares with other agentic IDEs

Kiro sits at the structured end of a category that also holds Cursor, GitHub Copilot, Windsurf, Trae, and Claude Code. The difference is not raw capability, it is where the plan lives. Cursor and Copilot keep planning in the chat window and optimize for speed from prompt to diff. Kiro writes the plan into the repository first and makes you approve it, which is overhead on a one-line change and leverage on a feature that three people have to review.

Kiro’s model documentation, checked 17 August 2026, lists models from OpenAI, Anthropic, MiniMax, Zhipu AI, DeepSeek, and Qwen alongside Auto. The exact picker varies by plan and region.

What hands-on reviewers report

Because this review is documentation-based, third-party hands-on accounts are the closest available evidence about daily use. Read the dates before the verdicts.

These three 2025 accounts agree that structured planning is Kiro’s distinctive idea and that the preview product was still uneven. None is a measurement, and this review did not time anything. Weigh every entry as a preview-era account rather than evidence about the current release.

Kiro IDE pricing in 2026

Kiro’s pricing page listed these individual plans:

Prices checked August 16, 2026, and unchanged from the August 6, 2026 check.

A credit is Kiro’s unit of agent work, and some reviewers call them points. Kiro’s pricing page says included credits reset at the start of each billing month and do not roll over. When they run out, individual plans do not cut you off: Kiro’s FAQ says you buy add-on packs priced from $5 to $100 at $0.04 per credit, and purchased credits expire twelve months after the purchase date. Team plans can instead enable automatic overages, billed at month end at the same rate.

Those allocations are not a reliable feature count, because a task’s consumption can vary. Because this review did not run a representative project, it cannot say how many production features a plan buys or whether Kiro offers better value than another tool. A useful evaluation should record the credits consumed by the same fixed task, including revisions and tests, rather than comparing the advertised monthly allocation alone.

What Kiro’s spec workflow actually produces

Kiro’s current Specs documentation defines three repository artifacts for a feature:

• requirements.md captures user stories and acceptance criteria.
• design.md records architecture, sequence diagrams, data flow, error handling, and the testing strategy.
• tasks.md turns the design into discrete implementation work with progress states.

Bugfix specs use bugfix.md to describe current, expected, and unchanged behavior. Feature work can start requirements-first or design-first. Quick Spec can generate the three feature artifacts in one pass without the approval gates used by the guided workflow, which is the answer to the overhead complaint if the guided flow feels heavy for the size of the change.

That structure is useful because it leaves reviewable evidence in the repository. A teammate can inspect the acceptance criteria, compare the proposed data flow with the implementation, and see which tasks were marked complete. Kiro also documents dependency analysis for Run all Tasks: independent tasks are grouped into parallel waves, while dependent waves wait for earlier work to finish.

The task ledger should be interpreted narrowly. A completed item says Kiro’s task runner marked that unit complete. Whether the result meets the requirement depends on the checks attached to it. The documentation does not define a completed task as proof of security, deployment correctness, recovery, accessibility, or production behavior.

Steering files and hooks cover different jobs

Kiro’s first-project guide places generated steering files under .kiro/steering/. They can describe the product, technology stack, repository structure, coding standards, and team workflows. Steering therefore supplies durable project context that should influence later agent work.

Agent Hooks add event-driven automation. Kiro’s current hook trigger reference includes prompt submission, agent stop, pre-tool use, post-tool use, file creation, file save, file deletion, pre-task execution, post-task execution, and manual triggers. Depending on the trigger, a hook can ask the agent to act or run a deterministic shell command.

Examples of useful boundaries include:

• run the project’s test command after a spec task completes;
• format or lint files after a write;
• block selected tool calls before execution;
• create or update tests when matching source files change;
• run a security scanner from a manual trigger.

Kiro’s hook actions documentation distinguishes agent-prompt actions from local shell-command actions. A nonzero shell result is reported to the agent; for a pre-tool hook, it can block the tool invocation.

A hook is configuration, so its coverage needs review. A file pattern can omit part of the codebase. A test command can succeed without exercising the changed path. A scanner can cover one language and skip another. The useful artifact is the hook definition plus evidence that its command reaches the code and failure mode the team cares about. Steering and hooks also age: a rules file that no longer matches the codebase steers the agent wrong on every turn, which is part of why an AI-built app gets harder to change over time.

Kiro does generate tests

The claim that Kiro writes a spec but cannot write the tests that check it is no longer accurate, and it is the single thing every widely read review still gets wrong. Kiro documents three testing paths:

1. The design artifact includes a testing strategy.
2. File and task hooks can generate tests or run an existing suite.
3. Spec correctness can derive and execute property-based tests from eligible requirements.

Kiro’s spec-correctness documentation says it extracts properties from EARS-formatted requirements, identifies properties that can be tested, generates randomized cases, and runs those cases against the implementation when the user chooses to run them. A failure is reduced to a smaller counterexample and surfaced for review. The generated property remains traceable to its requirement and task.

This is meaningful verification, with two documented boundaries. Property-based tests are optional by default. They provide evidence and are not formal proof. A weak or incorrect property can pass while the intended behavior remains wrong. Requirements involving external services or nondeterministic behavior may need mocks or example-based tests instead.

Security controls in Kiro IDE

Kiro’s privacy and security documentation describes Autopilot and Supervised modes. Both can read and write files and run commands. Autopilot applies file changes immediately. Supervised mode tags file modifications for review, presents a diff after the turn, and can revert rejected changes. Protected paths require approval in either mode.

Shell commands follow their own approval policy. Commands require approval by default, and users can add trusted-command prefixes. Kiro warns that the matching is string-prefix based and does not analyze command structure, chaining, or special characters. A broad trusted prefix can therefore authorize more than its label appears to suggest.

Supervised mode is a review boundary for file modifications. It does not restrict which files the agent can read, which commands it can propose, or what network access it has. Before opening a sensitive repository, Kiro recommends workspace isolation, narrowly scoped credentials, a minimal trusted-command list, and protected paths for sensitive files.

Those distinctions matter for production repositories. A reviewed diff does not reveal every effect of an already-approved command. A protected path prevents an unapproved write, while the agent may still read other accessible workspace content. Repository access, environment variables, cloud credentials, extensions, MCP servers, and trusted commands need an explicit least-privilege pass.

Data handling needs an account-level decision

Kiro’s data-protection page states that it stores questions, responses, code context, and request metadata to provide the service. Content for Free and individual subscribers is stored in US East (N. Virginia), with documented cross-region processing rules. Data is encrypted in transit with TLS 1.2 or higher and at rest with AWS-owned KMS keys. Enterprise administrators can configure a customer-managed KMS key.

For Free and individual subscriptions, Kiro says content may be used for service improvement and the relevant telemetry and content-sharing settings are enabled by default. Users can opt out in the IDE settings. Enterprise content is excluded from service improvement, with some reporting controls managed by the enterprise administrator.

This does not decide whether Kiro fits a particular organization’s policy. The decision depends on repository sensitivity, contractual requirements, permitted storage and processing regions, identity controls, credential exposure, and whether the selected account settings match the policy.

Is a Kiro-built app production ready?

The distance between “specced” and “verified” is measurable, and we measured it. Across the 26 real apps in the AxonBuild audit corpus, most of them vibe coding projects taken all the way to a launch, every finding adversarially verified: 22 shipped with at least one confirmed-critical issue, none finished in the green band, and the average score landed at 52 of a possible 100. A good share of those findings share one shape a spec workflow can reproduce on its own. The requirement was written down and the box got checked, and nobody ran the one command that would have shown the requirement was not actually met.

I saw that shape directly in one of the more mature codebases in the corpus, a voice-AI SDK with real ephemeral tokens and a proper reconnect lifecycle, the kind of repo that reads like someone who knew what they were doing. Its test command reported three packages back green: three configured runners, zero actual test cases inside any of them. The suite passed because there was nothing in it capable of failing. That app still landed red overall, on an unauthenticated endpoint that let a stranger mint sessions on the owner’s bill, a different hole entirely, but the empty test suite is the exact shape of a spec that says done without a command that proves it: readable, checked in, and confirming nothing. It is the same absence that turns into a real, expensive data-loss bug once a control exists on paper and nothing ever wires it. Kiro’s optional property-based tests raise the ceiling here, but only when someone chooses to run them and reads what they cover.

So Kiro can produce useful planning and verification artifacts, and production readiness still describes the deployed system. A release needs checks that cross the boundaries a repository spec may not exercise:

1. 01 Test authorization with a second account and a direct request that attempts to read or change the first account’s data
2. 02 Tamper with prices, roles, object ids, and callback payloads outside the user interface and confirm the server rejects or re-derives them
3. 03 Run database migrations and a restore drill against a non-production environment with representative data
4. 04 Exercise payment, email, storage, AI, and other external integrations using their failure and retry paths
5. 05 Run the configured tests from a clean checkout and confirm the suite contains meaningful assertions for the changed path
6. 06 Force a production-like failure and confirm monitoring reaches a human with enough context to respond

Whichever tool wrote the spec, those checks do not change; only the code being checked does. They are one slice of what decides whether an AI-built app is ready to launch.

Spec-driven development is worth understanding as its own discipline, separate from one IDE’s implementation, and the full ledger behind this corpus’s numbers carries every denominator and every held-out check. Kiro’s documented workflow can make intent, design, task progress, and some correctness checks more visible. That is a useful foundation. The production verdict still comes from evidence collected against the running application.

Common questions about Kiro IDE

Is Kiro worth it?

Yes, if you want requirements, design documents, task tracking, steering rules, and event-driven checks living in the repository instead of in a chat history. The overhead is real on small changes, which is what Quick Spec exists to shorten, and it pays back on features that more than one person has to review. This documentation review cannot judge output quality, speed, or value per credit, so test those on a representative task before adopting it across a team.

Is Kiro good for coding?

Kiro is good at the planning and review side of coding and unproven on speed. Requirements, design, and tasks land in the repository as files a teammate can read, hooks run checks on file and task events, and property-based tests can be derived from eligible EARS requirements and run against the implementation. Hands-on accounts dated July 2025 to March 2026 praise the planning depth and report the same rough edges: the IDE slowing down as context grows, heavy token use on long tasks, and agent cancellation that does not always work. This review did not test output quality or speed, so treat those accounts as reported experience rather than measurement.

Is Kiro IDE free?

There is a free tier with 50 credits a month, which is enough to try the spec workflow on a small feature and not enough for daily work. Paid individual plans run $20, $40, $100, and $200 a month for 1,000 to 10,000 credits. Included credits reset each billing month and do not roll over, and when they run out you buy add-on packs from $5 to $100 at $0.04 per credit rather than being cut off.

Is Kiro IDE made by Amazon?

Yes. Kiro is an AWS product. AWS’s own Kiro documentation hub describes Kiro as an agentic coding service built on Amazon Bedrock, and AWS named it the successor to Amazon Q Developer when it closed new Q Developer signups on May 15, 2026. That does not make it an AWS-only tool: it runs as a desktop IDE on your machine, and sign-in works with Google or GitHub as well as AWS identities.

Does Kiro require an AWS account?

No. Kiro’s FAQ says you can use it without an AWS account, signing in with Google, GitHub, an AWS Builder ID, or your organization’s identity provider through AWS IAM Identity Center. The Amazon Q Developer succession does not change that: Kiro is an AWS product, but it is not gated behind an AWS console account.

Which models does Kiro use?

Kiro defaults to Auto and also offers a picker with models from OpenAI, Anthropic, MiniMax, Zhipu AI, DeepSeek, and Qwen. The current model table, checked 17 August 2026, shows that availability varies by plan and region. The exact list in your picker can therefore be narrower than the full documented lineup.

How does Kiro compare to Cursor?

Kiro trades speed for structure. Cursor optimizes the distance from prompt to diff and keeps the plan in chat, while Kiro writes requirements, design, and tasks into the repository and asks you to approve them before implementation. Pick Kiro when the plan needs to be reviewable by someone who was not in the session, and pick Cursor when you already know exactly what you want changed.

Why do people say Kiro is slow?

Hands-on reviewers report the IDE slowing down as context grows during spec refinement, along with heavy token use on long tasks and agent cancellation that does not always work. Those accounts are dated from July 2025 through March 2026 and describe a product that shipped general availability partway through that window. This review did not time anything, so treat speed as reported experience rather than a measured result.

Does Kiro IDE generate tests?

Yes. Kiro documents test generation through hooks and optional property-based tests derived from eligible EARS requirements. It can also run tests after file saves or completed spec tasks. The team still needs to inspect the generated properties, confirm the hooks cover the right files, and run integration checks for behavior outside the property-test boundary.

Do Kiro specs make an app production ready?

No. Specs record requirements, design, and tasks, while optional correctness tests can check selected properties. Production readiness also depends on deployed configuration, authorization, real integrations, data recovery, observability, capacity, and failure handling.

Is Kiro safe for private code?

Kiro documents encryption, protected paths, command approvals, supervised file-change review, data-sharing controls, and enterprise options. Suitability depends on the account type, data settings, repository sensitivity, storage and processing requirements, extensions, MCP servers, and the credentials available in the workspace. Free and individual content is used for service improvement by default, so an opt-out pass in settings is the first thing to do on a sensitive repository.