Kiro: AWS's Agentic AI IDE Built Around Spec-Driven Development

AWS launched Kiro on July 14, 2025. It’s an agentic IDE built on Code OSS (the open-source foundation of VS Code) and it makes a specific bet: the biggest problem with AI coding tools isn’t that they can’t generate code, it’s that they generate code without a plan. Cursor, GitHub Copilot, and similar tools meet you where you are and help you type faster. Kiro wants to change the conversation before you start typing.

The approach is called spec-driven development. Before the agent writes anything, it generates structured specifications — requirements with acceptance criteria, a technical design, and a numbered task list. You review and edit them. Then the agent implements from the spec. This adds a planning phase that most AI tools skip, and it’s the design decision that makes Kiro different from everything else in the space.

The Spec System in Practice

Start a new feature in Kiro by describing it in plain language. “Add a review system for products” is enough. Kiro reads your codebase, understands the existing architecture, and generates three files in a .kiro/specs/<feature-name>/ directory:

requirements.md uses EARS notation (Easy Approach to Requirements Syntax) to express user stories as testable acceptance criteria. Each requirement reads like: “WHEN a user views a product page, the system SHALL display all approved reviews sorted by most recent.” These are explicit enough to verify against — not vague descriptions of intent.

design.md covers the technical approach. Data models, API contracts, component structure, database changes. Kiro bases this on your actual codebase, not a blank-slate architecture. If you’re using DynamoDB with single-table design, the design doc will reflect that. If your API follows a specific pattern, the new endpoints will match.

tasks.md is a numbered implementation checklist that breaks the design into concrete steps, ordered by dependency. Task 1 might be “Create the Review data model and DynamoDB schema.” Task 5 might be “Add the GET /products/{id}/reviews endpoint with pagination.” The agent can execute these sequentially.

The critical thing about this workflow: the spec review happens before any code is written. This is where you catch misunderstandings about scope, wrong architectural assumptions, or missing requirements. Fixing a spec takes 5 minutes. Fixing three days of code built on a wrong assumption takes considerably longer.

Kiro’s founder framing for this is “from vibe coding to production-ready code.” Vibe coding — just prompting an agent and seeing what comes out — works fine for prototypes and throwaway scripts. Specs are for things you have to maintain.

Steering Files

Steering files give Kiro persistent context that carries across every session, every spec, every chat message. They live in .kiro/steering/ as markdown files and contain whatever you want the agent to always know about your project.

A practical steering file:

# Stack
- Python 3.12, FastAPI, Pydantic v2
- DynamoDB single-table design (table: AppTable, region: us-east-1)
- Lambda + API Gateway, deployed via AWS SAM
- Structured logging via structlog, JSON output

# Conventions
- All functions have type annotations
- Error responses: {"error": "SNAKE_CASE_CODE", "message": "human-readable text"}
- Tests use pytest with pytest-anyio for async; fixtures in conftest.py
- No print() statements — use logger.info() with structured fields

# AWS Context
- Dev account: 123456789012
- Prod account: 987654321098
- Assume least-privilege IAM; no wildcard resources in Lambda execution roles

Every suggestion Kiro makes, every line it generates, every spec it writes will be grounded in what’s in your steering files. You write the conventions once instead of repeating them in every prompt.

Steering files can be scoped to specific file patterns. A steering file with filePattern: "**/*.tf" only applies when Kiro is working with Terraform files — useful for keeping Terraform-specific context separate from application code conventions.

The difference between a team with good steering files and one without shows up quickly. Without steering files, you’re correcting the agent on the same conventions repeatedly. With them, the agent already knows your preferences before you open your mouth.

Hooks: Automation Triggered by File Events

Hooks connect file system events to agent actions. You define them once; Kiro runs them whenever the trigger fires.

The setup is intentionally simple. Save a React component: Kiro updates the corresponding test file automatically. Modify an API endpoint definition: Kiro refreshes the README section that documents that endpoint. Stage a commit: Kiro scans for leaked credentials or hardcoded secrets before the commit completes.

Each hook has a trigger (file save, file create, etc.) and an action (a shell command or an agent prompt). The agent-prompt style is where it gets interesting — you can write natural language instructions that reference the triggering file:

name: Update tests on component save
trigger:
  event: file-edit
  pattern: "src/components/**/*.tsx"
action:
  agent: "Review the changes to  and update the corresponding test file to cover new props or behavior changes. Do not remove existing tests."

When you save src/components/ProductCard.tsx, Kiro reads the diff, finds the test file, and updates it. You review the proposed change before it’s applied.

The hooks system rewards investment. Set them up once for your project patterns, and the enforcement happens automatically. A hook that keeps tests in sync with implementation, a hook that validates component architecture, a hook that updates documentation — these accumulate into a system that actively maintains code quality rather than relying on engineers to remember.

Agentic Chat and Autopilot

Kiro’s chat panel handles multi-file changes. Describe what you want, the agent reads the relevant code and proposes coordinated edits across multiple files. You see a diff before anything is applied.

By default, the agent asks for approval at each significant action. Autopilot mode removes those checkpoints — the agent runs through the task list from the spec without pausing. Useful when you’ve reviewed the spec carefully and trust the implementation plan.

A practical Autopilot workflow:

1. Describe the feature
2. Review and edit the generated spec (requirements, design, tasks)
3. Enable Autopilot
4. Let the agent work through the task list
5. Review the final diff before accepting

The spec review before Autopilot is what makes autonomous execution reasonable. You’re not trusting the agent to make all the decisions — you’re trusting it to implement a plan you already approved.

MCP Integration

Kiro has native MCP (Model Context Protocol) support. Connect external tools by adding them to .kiro/settings/mcp.json:

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${env:DATABASE_URL}"
      }
    }
  }
}

With the AWS docs server connected, Kiro pulls live AWS documentation when answering configuration questions — useful for services that change frequently. With a database MCP server, you can ask Kiro to query your schema directly when generating migrations or reviewing data models.

The MCP ecosystem is the same one supported by Claude Code and other AI tools, so servers you configure for one tool can often be reused in Kiro with the same JSON configuration.

Models and Pricing

Kiro uses two model options:

Claude Sonnet 4.5 — reliable, strong reasoning, AWS’s recommended choice for complex spec generation and multi-file agent tasks.

Auto — Kiro’s mixed-model mode that detects prompt intent and routes to the most cost-effective model for each task. Simple completions go to a faster model; complex reasoning goes to Sonnet. Good for keeping interaction costs down.

Pricing (as of launch):

The free tier is a real trial — 50 agentic interactions is enough to evaluate the spec system on one or two real features. The credit counter appears per-prompt so you can see what each operation costs before you build habits.

At $19/month, Pro covers most individual developer usage. Teams with heavy agent use — running specs daily across multiple features — may need Pro+.

Language and Stack Support

Kiro supports: Python, Java, JavaScript, TypeScript, C#, Go, Rust, PHP, Ruby, Kotlin, C, C++, shell scripting, SQL, Scala, JSON, YAML, and HCL.

Because it’s built on Code OSS, Kiro accepts VS Code settings and Open VSX-compatible plugins. If you have a .vscode/settings.json with language-specific configurations, those carry over. Your existing extension setup for linting, formatting, and language servers works.

Kiro vs Other AI IDEs

The honest comparison:

Kiro vs Cursor: Cursor is faster for quick edits and has more mature inline completion. Kiro’s spec system is the differentiator for features that span multiple files or require design decisions — Cursor doesn’t have an equivalent planning phase. If you’re doing a lot of “make this function work differently,” Cursor wins on speed. If you’re implementing a new subsystem, Kiro’s structure helps.

Kiro vs GitHub Copilot: Copilot is inline completion and chat, well integrated into VS Code. It doesn’t have specs, steering, or hooks. Kiro is more opinionated about workflow.

Kiro vs Claude Code: Claude Code is terminal-native and excels at repository-wide tasks, infrastructure code (Terraform, CloudFormation), and DevOps work. Kiro is IDE-native and excels at application feature development with a visual diff workflow. They solve overlapping but distinct problems. Many AWS developers use both — Claude Code for infra, Kiro for application features.

Known Limitations (Preview)

Kiro launched in public preview. Current limitations worth knowing:

Session timeouts on large tasks — very long agent runs can time out, requiring you to resume from a checkpoint. The tasks.md structure helps here because you can restart from the last completed task.

Steep learning curve on the workflow — the spec system is unfamiliar if you’re used to immediately prompting for code. The first few features feel slower until the workflow clicks.

Preview performance — some users report occasional sluggishness. Expected to improve as the service scales.

Interaction limits — on the free tier, 50 interactions per month goes faster than you’d expect when you’re running specs. A single feature might use 5-10 interactions (spec generation, revision, agent tasks, questions).

The spec system, steering, and hooks all work well in the current preview. The rougher edges are around performance and the learning investment required to use the workflow effectively.

Getting Started

Download Kiro from kiro.dev. Available for macOS, Windows, and Linux.

Sign in with an AWS Builder ID (free, no AWS account required) for the free tier. For organizational deployments, IAM Identity Center provides centralized authentication for Pro seat management.

Initialize Kiro in an existing project:

# Create the Kiro project structure
mkdir -p .kiro/steering .kiro/specs .kiro/hooks .kiro/settings

# Create your base steering file
cat > .kiro/steering/project.md << 'EOF'
# Project
[Describe your application, tech stack, and deployment environment]

# Coding Standards
[List conventions: naming, error handling, logging, test patterns]

# Infrastructure
[AWS services used, account IDs, region, IaC tool]
EOF

Then open Kiro, start a new spec for a real feature rather than a toy example, and follow the spec review process. The workflow makes most sense applied to something with real constraints.

The investment in steering files pays back quickly. Write them well on day one, and every spec Kiro generates from that point reflects your actual project context rather than generic best practices.