Kiro (AI IDE Platform Market Research)

1. Introduction

Kiro is an agentic IDE released by AWS in July 2025, built on Code OSS and connected to models via Amazon Bedrock. Its launch slogan is “from vibe coding to viable code” — in response to the industry’s widespread dissatisfaction with the pattern of “casually chatting in natural language and generating code,” Kiro bets on a structural claim: write the spec first, then write the code. After a developer describes a feature, Kiro generates three editable, version-controllable spec documents (requirements.md, design.md, tasks.md); only after a human approves each one in turn does the agent carry out the work according to the task list. The spec is no longer a conversation buried in a chat log, but an explicit artifact inside the repository.

In the genealogy of AI IDE’s three schools — the completion flow (Copilot / Tongyi Lingma), the agent flow (Cursor / Cline / Roo Code), and the spec flow — Kiro is the sole representative of the spec flow backed by a hyperscale cloud vendor. This group of documents treats it as the differentiating thread: spec-driven development moves Harness’s L1 context engineering from “implicitly assembling prompts at runtime” forward to “explicit artifacts up front,” and externalizes L3 orchestration from “implicit planning within the model” into a “task list + gates.” On the six-layer model this is a genuine architectural shift forward, not merely an added feature.

1.1. Developer and Product History

Note on sources (v1.1 addition): There is a conflicting account of the relationship between Kiro and Amazon Q Developer — harnesses.sh (2026 account) says Kiro was released internationally on 2026-05-07 as the “successor to Amazon Q Developer,” while multiple third-party reviews from 2026-06/07 still list Q Developer as an independent, active product (Pro $19/seat/month). Whether the two form an official successor relationship is [To be verified], subject to the official AWS announcement; if the successor relationship is confirmed, Q Developer no longer merits its own standalone article, and this article’s history prevails.

1.2. Positioning and Latest Version

Kiro’s positioning is a spec-driven agentic IDE aimed at “prototype to production.” Unlike Cursor, which emphasizes the editor experience, and Claude Code, which emphasizes terminal autonomy, Kiro productizes the “intermediate artifacts of the development process”: requirements documents, design documents, and task lists — things that traditionally lived in Confluence and meeting minutes — are pulled into the repository, becoming both the agent’s implementation basis and the team’s review targets.

The current version number has not been disclosed first-hand on the official release page; recorded as [To be filled]. On the model side, the official account is that Bedrock provides frontier models such as Claude Sonnet 4 and Auto (hybrid routing); third-party accounts indicate that after GA, optional models include Claude Sonnet 4.5, Haiku 4.5, Opus 4.5, Opus 4.6, and the Amazon Nova family, with the exact list changing over time.

1.3. Pricing System

The following is the Credits billing system in effect since 2025-09-15 (official account relayed by third parties; the live kiro.dev/pricing page takes precedence):

Key points:

• New registered accounts receive 500 bonus Credits regardless of tier (valid for 30 days, third-party account).
• Credits are deducted by task-complexity score, and different models have different multipliers (e.g., Claude Opus 4.5 is 2.2x).
• Auto routing: by default the agent routes between multiple frontier and specialized models by intent; AWS official says this saves about 23% in cost versus direct Sonnet 4 (official account relayed by third parties).
• After GA, team plans are managed via AWS IAM Identity Center, with centralized billing and cost control (official account).
• Third parties also report a Pro Max tier ($100 / month, 5,000 Credits) that is inconsistent with the official four-tier account.

2. Glossary

3. Feature Overview

3.1. Spec-Driven Development

The spec workflow is Kiro’s main entry point, with a three-stage gate structure (each document must be approved by a human before the next one is generated):

Spec artifacts are stored in .kiro/specs/ and versioned with the codebase; in conversation, spec files are referenced directly via #spec-style references. AWS’s value proposition for this workflow is: explicitly recording decisions and rationale lets the agent implement more complex tasks in fewer turns, and “code–spec drift” can be detected and flagged (third-party account).

3.2. Steering and Hooks

Steering (the persistent context contract): the three base files form the project baseline and are injected by default with every interaction —

Custom Steering files support four injection modes: always (inject every time), fileMatch (inject when a file pattern matches), manual (#filename manual reference), and auto (automatic matching by description, in the same vein as the skills mechanism). It supports #[[file:...]] references to active workspace files to keep content fresh; it is compatible with the AGENTS.md standard (though AGENTS.md does not support injection modes, is always loaded, and AGENTS.md files in workspace subdirectories are also discovered); when the global scope ~/.kiro/steering/ conflicts with the workspace, the workspace takes precedence.

Agent Hooks (event-driven automation): configured as JSON under .kiro/hooks/, with ten trigger types in total (official documentation): SessionStart / Stop / PreToolUse / PostToolUse / PostFileCreate / PostFileSave / PostFileDelete / PreTaskExec / PostTaskExec / UserPromptSubmit. Actions fall into two categories: shell commands (executed at the project root, receiving the session-context JSON via STDIN) and agent prompts (injecting instructions into the current conversation). Key points:

• File-based triggers only respond to the agent’s own changes (agent-created / agent-saved); manual saves by a human do not trigger them — this is a key fix in the mid-2026 IDE 1.0.116: the code the agent writes is exactly the primary target the automation is meant to cover.
• Blockability is explicitly modeled: the three triggers PreToolUse, PreTaskExec, and UserPromptSubmit can block execution via exit code 2 (stderr relayed back to the agent), upgrading red lines such as “don’t touch the primary data files” from a prompt convention to a hard gate.
• The remaining triggers are non-blocking; their output is presented as a warning and execution continues.
• Command actions time out after 60 seconds by default (configurable; 0 disables); agent actions ignore the timeout.

3.3. Multi-Form Factor and Team Capabilities

4. Platform Architecture

图 4-1｜Kiro 平台架构：.kiro/ 声明式 Harness 与规格层的一等地位

数据来源：基于本文分析绘制的示意图。

The key architectural judgment: Kiro is one of the few products that makes the spec layer a first-class citizen inside an IDE. The .kiro/ directory (specs / steering / hooks / agents) effectively constitutes a Harness declaration system inside the repository: what context is resident (steering), what processes must be followed (specs), what events are handled automatically (hooks), and what tools each role uses (agents) — all four things are persisted to disk, version-controllable, and reviewable.

5. Harness Design

5.1. L1 Context Engineering Layer

Kiro’s L1 is the most forward-positioned on the timeline among the platforms in this group: most platforms’ L1 is “assembly at request time” — rule files, retrieval results, and history are stitched together on each request; Kiro moves half of that assembly work ahead to “before coding”:

1. The spec is the context. The three artifacts requirements / design / tasks become the implementation basis after human approval. In contrast to Cursor’s Auto Attached rules (which inject conventions when files are matched), the spec injects not “conventions” but “the goals and boundaries of this task” — the context upgrades from describing what the code currently is to describing what the code is to become. This expands L1 from “retrieving existing information” to “constructing information that does not yet exist.”
2. Steering’s four injection modes map almost one-to-one to Cursor’s four rule types (Always / Auto Attached / Agent Requested / Manual, see 01-cursor.md) as always / fileMatch / auto / manual, but add one more semantic layer: the three base files product / tech / structure are divided by “why to build it, what to build it with, and where to put it,” rather than being a single catch-all rules file. The official best practices also give a red line: Steering files must not contain secrets or sensitive data.
3. AGENTS.md compatibility and file references. Open-standard compatibility (workspace-wide AGENTS.md discovery) + #[[file:]] live file references mitigate drift between rule files and code.
4. Known weakness: spec quality depends on human review discipline — the gate blocks “unapproved, vague requirements,” but it cannot block “approved, wrong designs.” The spec flow moves part of the defect cost from the coding stage to the review stage; if a team lacks review capability, the benefit is accordingly lost.

5.2. L2 Tools and Execution Layer

• Built-in toolchain (official CLI material): read / write, glob (respects .gitignore), grep, shell, AWS CLI calls (use_aws), web_search / web_fetch, code (symbol-level LSP code intelligence), and more.
• The blockable PreToolUse hook is the connection point between L2 and L6: tools pass through the hook gate before execution, and exit 2 intercepts them — the command whitelist goes from “a prompt convention” to “programmatic enforcement.”
• MCP support (stdio, etc.); tools can be bundled into Powers for distribution; on the CLI side there is tool_search for on-demand loading of MCP tools, mitigating tool definitions crowding the context.
• No public OS-level sandbox disclosure (in contrast to Codex CLI’s Seatbelt / Landlock, see 05-codex-cli.md), [To be filled]; cloud Web sessions are naturally isolated from the local environment.

5.3. L3 Orchestration and Control Layer

1. The spec is the plan. tasks.md is an explicit, human-approved plan — while most platforms’ Plan Mode produces a one-off plan text, Kiro’s plan is a persistent artifact that is valid across sessions, can be advanced by checking items off, and can be reviewed. Upgrading “the plan” from conversation state to a versioned file is the meeting point of L3 and L4.
2. Task-level hooks: PreTaskExec / PostTaskExec wire the start and end of spec tasks into automation (spinning up the environment before a task starts, running verification after it ends), with orchestration granularity down to task-list entries.
3. Gated autonomy: in autopilot-style modes the agent can autonomously execute large tasks, but the three blocking points PreToolUse / PreTaskExec / UserPromptSubmit retain hard gates; independent tasks execute in parallel.
4. Multi-form-factor isomorphism: IDE / CLI / Web share the same spec and Steering system, and the Web autonomous mode takes on the clarification stage by “asking first, implementing second.”
5. Known weakness: the expressive power of the orchestration syntax (retries, timeouts, failure branches) has no public documentation, [To be filled]; cross-repository collaboration remains at the preview stage (third-party account).

5.4. L4 Memory and State Layer

Kiro’s memory philosophy is the opposite of Claude Code’s auto memory: it does not automatically persist session memory, but instead explicitly writes what should be remembered into specs and Steering. This is an advantage for “memory trustworthiness” (all memory is reviewable and version-controllable) and a disadvantage for “memory completeness” (it depends on humans writing it down). PR-comment learning is an attempt that sits between the two — feedback is distilled automatically, but scoped to the task creator to keep multiple people’s feedback from polluting each other.

5.5. Evaluation and Observability Layer

Two mechanisms in Kiro’s L5 are worth listing separately:

1. Property-based testing (GA): extracts properties from the EARS statements in requirements.md and generates hundreds or thousands of random cases to verify the implementation — this is a programmatic consistency check between the spec and the code, equivalent to turning “acceptance criteria” into executable assertions. It is the mechanism closest to a “spec-level regression suite” across all platforms in this group: after a change, rerunning the property tests lets you mechanically decide whether the implementation still conforms to the spec.
2. Unit-test / lint-style hooks + /context observation: PostFileSave attaches lint, Stop attaches tests, forming a continuous quality net; /context shows token usage and context files, and /compact manually compresses history.

Limitations: there is no public trace tracking or online quality metrics, [To be filled]; property-based testing depends on the spec itself being correct — if the spec is wrong, the tests “correctly” verify the wrong requirements.

5.6. Governance and Security Layer

Position within the group: Kiro’s L6 strength is moderately strong — it has programmatic gates and identity integration, but not the content-exclusion and IP-indemnity loop of GitHub Copilot, nor Cursor’s MDM-level hook distribution. Its special advantage is the spec audit chain: the complete chain of requirements → design → tasks → commit naturally constitutes the traceability material for “why the AI wrote this code,” which for AI-output attribution in regulated industries is something other platforms must add on externally.

5.7. Structural Significance of the Spec Flow for AI Harness

Placing Kiro back into this group’s README six-layer framework, its insight is: the differences between AI IDE schools are essentially a redivision of each layer’s responsibilities, not differences in the feature list.

In one sentence: the agent flow hands uncertainty to runtime guardrails, while the spec flow hands uncertainty to up-front human review. The two are not mutually exclusive — Kiro itself retains a vibe-style fast path, and Roo Code can also build its own spec directory in Markdown; the core deciding variables are “whether the requirements can be written clearly before work begins” and “whether review bandwidth is sufficient.”

5.8. Summary of Six-Layer Capabilities

6. Practical Cases

Note: this section honestly describes data availability. No externally published quantitative customer case studies from AWS with controlled measurements were found, and no unverified figures were used.

Citable information falls into three categories:

1. Internal adoption signals: third-party accounts say that within a few months after the release, about 1,500 AWS engineers actively used Kiro, and AWS announced it would standardize its internal developers on Kiro (). Internal scaled adoption is a stronger signal than external testimonials, but it is still not a customer case.
2. Product-side facts: the GA (2025-11-17) and the re:Invent 2025 capability-expansion cadence, along with the Amazon Q Developer migration guidance, indicate that AWS positions Kiro as the next-generation carrier of its coding-tools line (the third-party end-of-support date is [To be verified]).
3. Reproducible Harness workflow patterns (based on descriptions in the official documentation, not quantitative cases):

• Requirements traceability in regulated industries: finance / healthcare teams use the EARS statements in requirements.md as the acceptance baseline, and property-based testing + task-level hooks form a “spec → assertion → gate” chain, with audit material retained in the repository.
• Greenfield project documentation: new project teams write the requirements and designs that would otherwise go into Confluence into .kiro/specs/, so the documents ARE the implementation basis, avoiding a “documents vs. code” split.
• Team capability-pack distribution: package MCP configuration + Steering + rules as Kiro Powers, letting new members activate the team-consistent development context with one click.
• Task-level automation: PreTaskExec spins up the environment, PostTaskExec runs verification, and every checked-off item on the task list is accompanied by mechanical validation.

7. Conclusion

7.1. Strengths

1. Structural front-loading of the spec flow: moving L1 (context), L3 (plan), and L5 (acceptance) from runtime to up front is a redivision of Harness’s six-layer responsibilities, not feature stacking.
2. EARS + property-based testing: writing acceptance criteria as testable statements and then verifying them programmatically is the most complete “spec-level regression” mechanism across the group.
3. Blockable hooks + task-level triggers: red lines are upgraded from prompt conventions to hard exit-2 gates, with automation granularity down to spec tasks.
4. The .kiro/ directory is a declarative Harness: specs / steering / hooks / agents are all persisted to disk, version-controllable, reviewable, and distributable via Powers.
5. Multi-form factor and identity integration: IDE / CLI / Web / Mobile are isomorphic, with IAM Identity Center carrying enterprise identity and billing.

7.2. Limitations

1. Review bandwidth becomes a new bottleneck: the three-stage gate moves defect cost forward, and also moves the human bottleneck forward; spec quality determines the ceiling on the benefit.
2. Poor fit for emergent requirements: exploratory, fast-iteration work is slowed down by the gate process — Kiro itself has to fall back on the vibe path.
3. Local sandbox and orchestration semantics not disclosed: L2 isolation primitives and L3 failure-handling details lack public documentation, [To be filled].
4. Ecosystem lock-in: models go through Bedrock and governance connects to IAM, so teams outside the AWS ecosystem need to evaluate the depth of the tie.
5. Conflicting pricing and tier accounts: third-party Pro Max reports are inconsistent with the official four tiers, with the per-tier details.

7.3. Applicability Boundaries and Selection Recommendations

Selection recommendation: on this group’s main line of “completion flow → agent flow → spec flow → terminal flow,” the spec flow answers the question the other three flows do not — where requirements come from, who approves them, and what governs. The evaluation criterion: if a team already has an explicit requirements-review culture (or wants to build one through the tool), Kiro is the most complete carrier; if requirements only emerge during coding, the spec flow is a burden, and one should return to the agent flow (Cursor / Roo Code, see articles 01 / 10). A hybrid strategy also holds: complex features go through the spec gate, small changes take the fast path — this is exactly Kiro’s own product shape.

Information Gaps Statement

1. Exact public-preview date: the official blog and third-party reports disagree between 07-14 / 07-15.
2. Current version number: not disclosed first-hand on the official release page, [To be filled].
3. Pricing details: the Credits system comes from an official account relayed by third parties; the Pro Max tier and bonus-Credits rules have conflicting sources.
4. Auto routing’s cost savings (about 23%): official account relayed by third parties.
5. Available model list: changes over time and is inconsistent across sources.
6. Local sandbox mechanism: no public disclosure found, [To be filled].
7. Implementation of spec–code drift detection: an officially claimed capability, but no documentation of the implementation details was found.
8. Compliance certification list (SOC 2 / ISO, etc.): no public material found, [To be filled].
9. Customer quantitative cases: no first-hand controlled data from AWS found; the 1,500 internal-engineers account is a third-party relay.
10. Exact date of Kiro Web GA: the official FAQ confirms availability and the billing account but does not state a date; the media-sourced date is 2026-09-01, [To be verified].

8. References

1. Kiro official website — AWS, 2026. https://kiro.dev/
2. Kiro official documentation · Steering — AWS, 2026. https://kiro.dev/docs/steering/
3. Kiro official documentation · Hooks — AWS, 2026. https://kiro.dev/docs/hooks/
4. Kiro official documentation · Hooks (cross-form-factor version) — AWS, 2026. https://docs.kiro.dev/hooks
5. Introducing Kiro — AWS official blog, 2025-07. https://kiro.dev/blog/introducing-kiro/
6. Kiro is generally available — AWS official blog, 2025-11-17. https://kiro.dev/blog/general-availability/
7. Spec-driven development entry — AI Wiki (third party), 2026. https://aiwiki.ai/wiki/spec_driven_development
8. Beyond Vibe Coding: Amazon Introduces Kiro — InfoQ (third party), 2025-08. https://www.infoq.com/news/2025/08/aws-kiro-spec-driven-agent/
9. AWS launches Kiro — SiliconANGLE (third party), 2025-07-14. https://siliconangle.com/2025/07/14/aws-launches-kiro-spec-coding-developer-environment-integrated-ai-agents/
10. Introducing the Model Context Protocol — Anthropic, 2024-11-25. https://www.anthropic.com/news/model-context-protocol
11. Terminal-Bench official site (model + Harness system evaluation account) — Stanford / Laude Institute, 2025—2026. https://www.tbench.ai/
12. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/

Incremental update (2026-09-12): In early 2026-09, AWS launched the Kiro Web edition (a browser-based entry point; GA status [To be verified]), expanding Kiro from a desktop IDE into a spec-driven development platform available on the Web; this complements the desktop form factor in section 1.1 of this article and does not change its “spec-first” Harness design mainline.