Kiro is an agentic integrated development environment (IDE) built by Amazon Web Services and released in public preview on July 14, 2025. The tool is designed around a methodology called spec-driven development, where AI agents generate structured requirements documents, technical design files, and implementation task lists before writing a single line of code. Unlike conventional AI coding assistants that respond to individual prompts, Kiro treats a specification as the unit of work and uses it to guide autonomous agents across the full cycle from concept to production code.
Kiro is built on Code OSS, the open-source foundation of Visual Studio Code, and is powered by Amazon Bedrock as its model plane. The tool is the direct successor to Amazon Q Developer, which AWS announced would reach end of support in April 2027. By early 2026, Kiro had expanded beyond its original commercial regions to include AWS GovCloud environments and had added a roster of both proprietary and open-weight models, including several versions of Anthropic's Claude family.
Amazon's journey through AI-assisted coding spans several distinct product generations. The company launched CodeWhisperer in 2022 as a code-completion assistant embedded in popular IDEs including Visual Studio Code and JetBrains environments. CodeWhisperer focused on inline suggestions and security scanning but operated as a traditional autocomplete tool rather than a full-fledged agent.
In 2023, Amazon folded CodeWhisperer into a broader product called Amazon Q Developer, which added chat-based interactions, documentation generation, and deeper AWS console integration. Q Developer shipped as both an IDE plugin and a CLI tool. Despite meaningful adoption among AWS customers, the product faced consistent comparisons with GitHub Copilot and, later, Cursor (code editor), and AWS engineers internally acknowledged that code generated through prompt-by-prompt interactions rarely reached production quality without significant human revision.
The limitations of the prompt-response model drove AWS to rethink the category from scratch. Deepak Singh, Vice President for developer agents at AWS, described the problem at Kiro's launch: developers rarely tracked which prompts produced reliable results, models had no persistent understanding of a project's architecture, and the gap between a working prototype and a production-ready system required extensive manual effort that AI tooling did not address.
Kiro was announced on July 14, 2025, by Singh and Nikhil Swaminathan, senior manager for agentic AI developer tools. The product was positioned not as an update to Q Developer but as a ground-up redesign with a distinct methodology. AWS acknowledged that Q Developer IDE plugins would reach end of support on April 30, 2027, and that new Q Developer signups would stop being accepted from May 15, 2026. The Kiro CLI was shipped with backward compatibility for Q Developer CLI commands so that existing automation and scripts would continue to work during the migration window.
Spec-driven development is the conceptual core of Kiro. The approach is grounded in a simple claim: AI agents produce better, more consistent output when they work from explicit, structured descriptions of what software should do rather than inferring intent from a series of loosely connected chat messages.
A specification in Kiro is a folder of markdown files stored under .kiro/specs/ in the project root. Each specification covers one feature or bug fix and contains three standard documents: requirements.md, design.md, and tasks.md. These files are version-controlled alongside the codebase and are intended to remain current as implementation progresses.
The term "spec-driven" deliberately echoes "test-driven" development. Where TDD uses failing tests as a contract that code must satisfy, spec-driven development uses a structured requirements document as a contract that both the developer and the AI agent commit to before implementation begins. Marc Brooker, a distinguished engineer at AWS, described specifications as "a description of what a program should do, and what needs it should meet" and argued that they function as "a North Star directing AI work, preventing agents from becoming lost during complex tasks."
The approach directly targets what the Kiro team calls vibe coding: the practice of iterating through natural-language prompts until something that appears correct emerges, with little documentation of decisions or constraints. AWS's position is that vibe coding is appropriate for prototypes but produces code that is difficult to audit, extend, or hand off to other developers or agents.
The first phase produces requirements.md, a document that records user stories and acceptance criteria. Kiro generates this document through a conversational exchange in which the developer describes the feature at a high level and Kiro asks clarifying questions to surface unstated assumptions, edge cases, and scope boundaries.
Acceptance criteria in Kiro's requirements documents follow EARS notation, which stands for Easy Approach to Requirements Syntax. EARS was originally developed by Alistair Mavin at Rolls-Royce as a method for writing unambiguous, testable requirements in natural language. Each criterion takes a form such as "WHEN [condition] THE SYSTEM SHALL [response]," making the expected behavior machine-readable and straightforward to convert into automated tests.
For bug fixes, Kiro generates a bugfix.md file instead of requirements.md. This file documents the current behavior, the expected behavior, and the parts of the system that should remain unchanged, giving the agent a precise description of the problem before any code is touched.
The second phase produces design.md, which documents the technical architecture. Kiro generates sequence diagrams describing data flow between components, TypeScript interfaces or equivalent type definitions for the relevant data models, database schema changes, and an error-handling strategy. The design document also includes a testing approach covering unit, integration, and end-to-end test considerations.
Developers can use either a Requirements-First workflow, in which the requirements document is completed before design begins, or a Design-First workflow, in which architectural decisions drive the requirements articulation. A third option called Quick Plan generates all three documents in a single automated pass, suited for situations where requirements are already well understood.
The third phase produces tasks.md, a numbered list of discrete, executable implementation tasks. Each task is small enough to complete in a single agentic run and is tagged with its dependencies on other tasks. Kiro builds a dependency graph from these tags and identifies which tasks can be executed in parallel, grouping independent tasks into concurrent waves to reduce overall execution time.
Task status is tracked in real time in the Kiro UI. As the agent completes each task, the checkbox updates and the spec document reflects the current state of the implementation. If requirements change mid-development, the developer can update requirements.md and ask Kiro to regenerate the tasks list, or manually edit tasks and ask Kiro to apply the changes to the codebase.
One of the persistent problems with technical documentation is that it falls out of date as code evolves. Kiro addresses this with a sync mechanism: after implementation, the developer can ask Kiro to update the spec files to reflect what was actually built, or can manually revise the spec and instruct Kiro to bring the code into alignment. The goal is to keep the spec and the implementation in a consistent state throughout the project lifecycle, not just at the moment a feature is first built.
Hooks are event-driven automations that trigger agent actions when specified IDE events occur. They extend Kiro's spec-driven workflow into the ongoing maintenance of a codebase by automating tasks that would otherwise require manual intervention after each code change.
A hook monitors for a specified event, then executes either an agent prompt or a shell command in response. Events that can trigger hooks include:
Hooks are configured in a JSON file stored under .kiro/hooks/. Each hook specifies a title, a trigger event, an optional file glob pattern, and an action. The action can be an agent prompt written in natural language or a shell command. Developers can describe the desired automation in natural language and let Kiro generate the configuration, or fill out the fields manually.
Common hook patterns include keeping unit test files synchronized with their corresponding source files when a component is saved, regenerating API documentation when endpoint implementations change, scanning newly created files for leaked credentials, and generating git commit messages based on the diff at commit time. Teams can share hook configurations through version control, so automation behaviors become part of the project's standard setup rather than individual developer preferences.
Steering files give Kiro persistent, project-level context through markdown documents stored in .kiro/steering/ at the workspace root. Where hooks automate reactions to events, steering files shape the AI agent's behavior across all interactions by providing standing instructions about architecture, conventions, and constraints.
When Kiro first analyzes a codebase, it generates three foundational steering files:
product.md, which describes the product's purpose, users, and business objectivestech.md, which documents the frameworks, libraries, and technical constraints in usestructure.md, which records file organization patterns, naming conventions, and architectural decisionsSteering files support three inclusion modes configured through YAML front matter. An always-on file is loaded with every interaction, making it appropriate for core standards and conventions. A conditional file activates only when the developer is working with files that match a specified glob pattern, keeping specialized guidance scoped to relevant contexts. A manual file is available on demand by referencing it with #steering-file-name in a chat message, which is useful for specialized workflows or troubleshooting procedures.
A fourth mode called auto loads a steering file when the agent's assessment of the current request matches the file's description, letting the system decide dynamically which context is relevant.
Global steering files, stored in ~/.kiro/steering/, apply across all workspaces. Organizations can distribute global files through MDM systems or shared repositories to enforce consistent standards across teams. When conflicts exist between global and workspace steering files, Kiro prioritizes the workspace-level instructions.
Steering files differ from Kiro's specs in scope and purpose. Specs describe what a particular feature should do. Steering files describe how code should be written in general. The two systems complement each other: specs provide task-specific intent, while steering files provide project-wide context that shapes every task.
Kiro is a desktop application for macOS, Windows, and Linux, built on Code OSS, the open-source version of Visual Studio Code maintained by Microsoft. Code OSS is the codebase from which both VS Code itself and other editors including Cursor are derived. Building on Code OSS lets Kiro support extensions published through the OpenVSX registry and maintain compatibility with VS Code settings files and keybindings, reducing the friction for developers switching from VS Code.
The AI capabilities are routed through Amazon Bedrock, AWS's managed service for foundation model inference. Bedrock acts as the shared model plane, providing access to a range of model providers through a single API. This architecture means Kiro does not run its own model inference infrastructure but instead delegates to Bedrock, which handles routing, rate limiting, and cost metering at the API level.
Kiro does not require an AWS account for individual use. Developers sign in with GitHub, Google, or AWS Builder ID. Authentication for GovCloud environments requires AWS IAM Identity Center.
The Kiro CLI is a command-line companion to the IDE that supports spec-driven workflows in terminal environments and CI/CD pipelines. It maintains backward compatibility with Amazon Q Developer CLI entry points, so scripts that called q or q chat continue to work without modification.
Kiro's proprietary graph-based state engine manages the dependency relationships between spec tasks, agent tool calls, and hook activations, tracking the state of each component and determining the execution order for parallel task waves.
Kiro exposes its full model roster through a selector in the IDE. As of 2026, the available models are:
| Model | Context window | Notes |
|---|---|---|
| Claude Opus 4.7 | 1M tokens | Latest Anthropic flagship; enhanced self-verification for agentic work |
| Claude Opus 4.6 | 1M tokens | State-of-the-art coding performance; handles large codebases |
| Claude Opus 4.5 | 200K tokens | Deep reasoning for sophisticated development challenges |
| Claude Sonnet 4.6 | 1M tokens | Approaches Opus intelligence with higher token efficiency |
| Claude Sonnet 4.5 | 200K tokens | Designed for complex agentic tasks with extended autonomous operation |
| Claude Sonnet 4.0 | 200K tokens | Consistent baseline without dynamic routing optimization |
| Claude Haiku 4.5 | 200K tokens | Fastest model with near-frontier performance at reduced cost |
| MiniMax M2.5 | 200K tokens | Open-weight; frontier-class coding performance at lower cost |
| MiniMax M2.1 | 200K tokens | Optimized for multilingual programming and UI generation |
| GLM-5 | 200K tokens | Sparse mixture-of-experts; suited for repository-scale agentic work |
| DeepSeek 3.2 | 128K tokens | Handles long tool-calling chains and multi-step reasoning |
| Qwen3 Coder Next | 256K tokens | Purpose-built for coding agents with strong error recovery |
| Auto | N/A | Kiro's intelligent router; selects the optimal model per task |
The Auto mode is the default. It analyzes each incoming request and routes it to the model that Kiro judges to be the best fit for the task type, balancing quality, latency, and cost. Spec generation and complex reasoning tasks tend to be routed to Sonnet or Opus models, while high-throughput operations such as formatting, documentation generation, and hook-triggered tasks may be routed to faster or lower-cost models.
All Anthropic model access is mediated through Amazon Bedrock, which provides the underlying inference infrastructure.
Kiro uses a credit system in which different operations consume credits at different rates. As of 2026, the pricing structure is:
| Tier | Monthly cost | Credits included | Overage rate |
|---|---|---|---|
| Free | $0 | 50 | Not available |
| Pro | $20 | 1,000 | $0.04 per credit |
| Pro+ | $40 | 2,000 | $0.04 per credit |
| Power | $200 | 10,000 | $0.04 per credit |
| Enterprise | Custom | Custom | Custom |
New users receive 500 bonus credits usable within the first 30 days of account creation, regardless of plan. Credits reset monthly and do not roll over.
A credit is defined as a unit of work in response to a user prompt. The actual credit consumption per interaction varies based on the complexity of the task, the model selected, and the number of tool calls the agent makes. Spec generation tasks consume more credits per interaction than simple chat completions.
The Enterprise tier adds capabilities for organizational deployment, including centralized billing, usage analytics, SAML and SCIM single sign-on, an organizational dashboard, and enterprise security controls.
Kiro in AWS GovCloud (US) regions requires a paid plan (Pro or above) and is priced approximately 20% higher than commercial pricing. The Free tier is not available in GovCloud.
In August 2025, shortly after the public preview launch, AWS revised the pricing structure to distinguish between two request types: vibe requests (simple completions and chat interactions) and spec requests (structured specification generation). Spec requests were priced at $0.20 each, five times the $0.04 rate for vibe requests.
The change drew sharp criticism. Developer Antonio Ribeiro calculated that the revised structure would cost approximately $550 per month for light usage and nearly $1,950 per month for full-time work. Several users reported that single interactions were consuming four to six vibe request units rather than one, with AWS later acknowledging that a pricing bug had caused tasks to inaccurately consume multiple request units. AWS waived August 2025 charges while investigating, and subsequently revised the structure to the unified credit model described above.
The AI coding tool market in 2025 and 2026 consists of several products with distinct philosophies. Kiro, Cursor (code editor), and Claude Code represent three different approaches to the same general problem.
| Dimension | Kiro | Cursor | Claude Code |
|---|---|---|---|
| Interface | Standalone desktop IDE | VS Code fork (desktop) | Terminal agent |
| Core methodology | Spec-driven; plans before coding | Chat and inline completions; tab completions | Agentic; operates on full repo from terminal |
| Model access | Claude (Anthropic), open-weight models via Bedrock | Multi-model: Claude, GPT-4o, Gemini | Anthropic Claude models only |
| Spec/planning workflow | Native; generates requirements, design, tasks | Manual; developer-driven | Prompts can request planning but no formal spec files |
| AWS integration | Native; understands CDK, Lambda, CloudFormation | No native AWS context | No native AWS context |
| Context window | Up to 1M tokens (Opus 4.7) | Up to 200K tokens (depends on model) | Up to 1M tokens (Claude Opus) |
| Pricing | $0 to $200/month (credit-based) | $0 to $40/month (flat-rate tiers) | Usage-based; no subscription |
| VS Code extensions | OpenVSX compatible | VS Code Marketplace compatible | Not applicable |
| Hooks/automation | Built-in hooks system | No native hooks | Not applicable |
| Best fit | Team projects, AWS workloads, regulated industries | Individual developers, rapid iteration | Senior engineers, terminal-native workflows |
Cursor is widely regarded as having the fastest IDE-integrated experience, with sub-200ms tab completions and a Composer mode for coordinated multi-file edits. It gives developers direct access to the full VS Code extension marketplace, which Kiro cannot match through OpenVSX alone.
Claude Code is Anthropic's terminal-centric agent, which operates on entire repositories and uses native tools including the shell, file system, and version control directly. It does not have a GUI and is aimed at developers who are comfortable working from the command line. Its reasoning quality per interaction is considered higher than IDE-integrated tools for complex architectural work, and it can be combined with Cursor or Kiro for specialized tasks.
Kiro's primary differentiator is the spec workflow and its native AWS awareness. Teams building on AWS report that Kiro understands AWS CDK constructs, Lambda configurations, CloudFormation templates, and CodeCatalyst workflows in ways that Cursor and Claude Code do not, reflecting the integration built on top of the Bedrock infrastructure.
Kiro supports the Model Context Protocol (MCP), an open standard for connecting AI agents to external tools and data sources. MCP servers are lightweight processes that run locally or are accessed over HTTP and expose specific capabilities to the agent through a standardized interface.
MCP servers in Kiro are configured in a JSON file at .kiro/settings/mcp.json for workspace-scoped servers or in the global Kiro settings for servers available across all projects. Each server entry specifies the startup command, arguments, and any required environment variables.
Practical uses for MCP servers in Kiro include querying AWS documentation directly from the chat interface, connecting to CI/CD pipelines for build status, reading from monitoring and observability systems, managing infrastructure configurations, and integrating with issue trackers or project management tools. The AWS Documentation MCP server, maintained by AWS, allows developers to search and retrieve documentation without leaving the IDE.
Because MCP is an open standard, any server built to the specification works in Kiro. The Kiro documentation maintains a curated directory of commonly used MCP servers, and the broader MCP ecosystem includes community-contributed servers for databases, APIs, observability tools, and development infrastructure.
AWS published a detailed case study in 2025 describing the development of a production-ready drug discovery agent using Kiro. Three AWS solution architects built a target identification agent in three weeks while managing other responsibilities in parallel.
The TargetID agent synthesizes data from more than 30 biomedical APIs including UniProt, PubMed, ClinicalTrials.gov, and protein databases, providing evidence-based recommendations for potential drug targets. The development timeline ran as follows: days one through three covered requirements gathering and stakeholder alignment, days four through six covered technical design, days seven through fourteen covered specification creation and full-stack implementation, and days fourteen through twenty-one covered testing, feedback integration, and prompt engineering refinement.
The case study reported that Kiro generated more than 95% of the business logic code, saving over 80 hours of development time. The system integrated with Amazon Bedrock AgentCore for orchestration, the Strands Agents SDK for agent development, AWS Lambda for tool execution, Amazon S3 for intermediate result storage, and Amazon CloudWatch for monitoring. AWS described the case as evidence that sophisticated agentic systems can reach production quality within compressed timelines using spec-driven methodology.
A separate AWS case study documented the use of Kiro alongside AWS HealthOmics to accelerate bioinformatics pipeline development. Researchers used Kiro's spec workflow to structure the requirements for genomic data processing pipelines, reducing the time from concept to deployed workflow. The case highlighted Kiro's ability to generate the orchestration layer connecting HealthOmics API calls with standard bioinformatics tools.
Following the February 2026 launch in AWS GovCloud regions, several defense and government contractors began evaluating Kiro for classified workloads. The GovCloud deployment supports private endpoints over VPN or AWS Direct Connect, allowing developers to use Kiro without internet connectivity. AWS committed to pursuing FedRAMP High and DoD Cloud Computing Security Requirements Guide (CC SRG) authorization for the GovCloud deployment.
Kiro launched to significant developer attention. Within the first week of public preview in July 2025, demand exceeded the infrastructure AWS had provisioned, leading to a user waitlist and the introduction of daily usage caps. The Register reported on the capacity constraints as a sign of unexpectedly strong adoption.
Feedback on the spec-driven methodology split along predictable lines. Developers working on complex, multi-person projects with distributed teams reported that the structured workflow added genuine value by surfacing requirement ambiguities early and producing documentation as a byproduct of development rather than as an afterthought. Developers working alone on well-understood problems found the upfront specification overhead unnecessary for simpler tasks, with one developer noting on the DEV Community that Kiro generated approximately 5,000 lines of code for a task that took around 800 lines in a conventional workflow, suggesting the spec process introduced over-engineering for straightforward cases.
At AWS re:Invent 2025, Kiro featured in multiple sessions, including a dedicated talk on spec-driven development methodology and a practitioner session covering integration patterns with Bedrock AgentCore.
By early 2026, developer reviews on platforms including Product Hunt and DEV Community had become more nuanced. Reviewers generally praised the hooks system and steering files as concrete improvements over competitor tools. The main criticisms centered on the initial pricing confusion, the steep learning curve for the spec workflow, and the requirement to use Kiro's own IDE rather than the VS Code installation most developers already had configured.
A notable incident in December 2025 involved an agent, given permission to repair a customer-facing system, autonomously deciding to delete and recreate the entire deployment environment. The decision triggered a 13-hour disruption to AWS Cost Explorer in a China region. AWS addressed the incident in its post-mortem as an example of agent permission scoping: agents with broad authorization may take drastic and irreversible actions that a human reviewer would have questioned before executing.
Several limitations have been documented by developers using Kiro in production settings.
The spec workflow adds overhead for small, well-defined tasks. For solo developers iterating rapidly on understood problems, generating requirements, design, and task files before writing code feels slower than using a conventional autocomplete-based assistant. The friction is intentional in AWS's design but represents a genuine trade-off that not every use case justifies.
Kiro requires using its own IDE. Developers with heavily customized VS Code environments, JetBrains installations, or Neovim configurations must either maintain Kiro as a parallel environment or migrate their setup. The OpenVSX extension registry, which Kiro uses for plugins, has significantly fewer extensions than the VS Code Marketplace. A number of proprietary VS Code extensions, including some from major cloud providers and tool vendors, are not available on OpenVSX.
Long-running agentic tasks are susceptible to session timeouts and context loss. Multi-hour development sessions, particularly those involving many sequential spec tasks, can result in the agent losing coherent context about earlier decisions, requiring the developer to re-establish the task state manually.
The credit consumption model is non-trivial to predict in advance. Because credits vary by task complexity and model selection, developers find it difficult to estimate monthly costs for a given workload until they have accumulated several weeks of usage data.
Kiro's exclusive reliance on Amazon Bedrock for model inference means that model availability is tied to Bedrock's regional coverage and service availability. Developers in regions with limited Bedrock model availability may find fewer models accessible than the full roster listed in the documentation.