Kiro is AWS's bet that AI coding should feel more like engineering and less like rolling dice. Instead of typing a prompt and hoping the agent edits the right files, Kiro forces a structured flow: requirements in EARS notation, a technical design, then discrete tasks the agent executes. The spec is the source of truth. Code is the build artifact.

Built on Code OSS and routed through Amazon Bedrock, Kiro pairs that spec workflow with two other primitives: Hooks (event-driven automations that run agent actions on save or commit) and Agents (including specialized sub-agents you can define yourself). The result is an AI IDE that plays well inside teams that already care about code review, audit trails, and cost discipline.

This guide covers Kiro's core primitives, pricing, how Specs and Hooks work in practice, how it compares to Cursor, Claude Code, Codex, and Antigravity, and when it's the right fit.

1What Kiro Is and Why AWS Built It

Kiro is an agentic IDE and CLI from AWS, built on Code OSS (the open-source base of VS Code) and powered by models served through Amazon Bedrock. Where Cursor and Copilot optimize for speed from prompt to code, Kiro optimizes for correctness: you can't ship a feature until there is a spec, a design, and a task list, all versioned in the repo.

Why AWS built this rather than yet another Copilot clone: enterprise customers need traceability. When an AI agent ships a bug, the review question isn't "what did the human prompt?" It's "was the requirement wrong, the design wrong, or the implementation wrong?" Kiro answers that by making each step a separate artifact you can version, review, and own.

2Specs: Requirements, Design, Tasks

A Kiro spec has three parts:

EARS (Easy Approach to Requirements Syntax) keeps requirements precise. A typical requirement looks like:

The spec lives in .kiro/specs/<feature>/ with separate markdown files for requirements, design, and tasks. Kiro generates the first pass, you review and edit, then the agent works through the tasks one by one. Every task change is tracked so you can pause, review, and resume.

3Hooks: Event-Driven Automation

Hooks turn Kiro agents into always-on teammates. A hook is a small JSON file that maps an event to an agent action. Events include file edits, file creation, file deletion, git events, and custom triggers. Actions can be "ask the agent" or "run a shell command."

{
  "name": "Lint on Save",
  "version": "1.0.0",
  "when": {
    "type": "fileEdited",
    "patterns": ["*.ts", "*.tsx"]
  },
  "then": {
    "type": "runCommand",
    "command": "npm run lint"
  }
}

Common hook patterns teams use:

• Lint and test on save: Run lint and unit tests on every TypeScript file change.
• Pre-commit review: Ask an agent to review staged changes and flag regressions before commit.
• Spec drift detection: On file changes in a specced module, check whether the spec still matches the implementation.
• Security checks: On new file creation, scan for hardcoded secrets, unsafe patterns, or credential leaks.
• Doc updates: On API changes, regenerate the API documentation.

4Agents and Sub-Agents

Kiro ships with a primary agent that can read, write, run shell commands, search, and fetch. On top of that, you can define sub-agents with their own system prompts and tool access. Three sub-agents are available out of the box:

• general-task-execution: All-purpose sub-agent used for well-scoped tasks with access to all tools.
• context-gatherer: Efficient explorer for mapping unfamiliar codebases without polluting the main context.
• custom-agent-creator: Designed for creating and configuring new custom sub-agents from scratch.

You can also define your own agents (security reviewer, SQL writer, test writer, accessibility auditor) with fenced system prompts and restricted tools. This is how enterprise teams enforce separation of concerns: the security reviewer agent has read-only access and can only call specific tools; the test writer agent can edit but only inside tests/.

5MCP Integration and Steering

Kiro integrates with the Model Context Protocol (MCP). Servers are configured in .kiro/settings/mcp.json at workspace or user level. Config merges with user precedence first, then workspace-by-workspace overrides.

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["mcp-server-postgres"],
      "env": { "DATABASE_URL": "env:DATABASE_URL" },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Steering is the other extensibility surface. Steering files live in .kiro/steering/*.md and can be included always, conditionally (based on file matches), or manually. They encode team conventions: coding standards, design tokens, naming rules, deployment pipelines. The agent reads steering before every task.

This is what separates Kiro from Cursor Rules or Claude Code memory. Steering is first-class, versioned, and scoped. Every team member gets the same conventions applied to every agent action.

6Pricing and Credits Explained

Credits are consumed by agent operations, not by chat typing. Simple questions cost nearly nothing. Spec generation, multi-file edits, and long autonomous runs cost more. Because Kiro routes through Bedrock, model access is predictable and not throttled the way free-preview agentic IDEs tend to be.

7Kiro vs Cursor vs Codex vs Antigravity vs Claude Code

For a deeper multi-tool breakdown, see our 2026 AI coding agents comparison.

8Where Kiro Shines and Where It Does Not

Strong fit

• Teams of 1-5 shipping new features that need traceability from requirement to code.
• Regulated or enterprise environments where audit trails and deterministic delivery matter.
• Organizations already invested in AWS and Bedrock-managed models.
• Projects where the cost of a bad ship is high (payments, health, scheduling, finance).

Weak fit

• Quick one-shot hacks where writing a spec slows you down more than the agent speeds you up.
• Frontend-heavy work that benefits from built-in browser verification (Antigravity is stronger).
• Very large legacy codebases where enterprise context engines can out-index Kiro's default indexer.

9Deploying Kiro in Production Teams

Seven things we do when we set Kiro up for a team:

• Commit .kiro/steering/ files for coding standards, testing conventions, security rules, and deployment procedures.
• Define an always included steering file for company-wide norms and manual steering for situational guides.
• Set up Hooks for lint, type-check, unit tests, and security scans on file save.
• Configure MCP servers for internal platform APIs so agents can reach real systems instead of scaffolding fakes.
• Define at least one custom sub-agent (for example, a security-reviewer agent) with restricted tools.
• Turn every non-trivial feature into a spec before writing code, review the spec in PR, then execute.
• Track credit usage per developer and per project so costs stay predictable as teams scale.

10How Lushbinary Uses Kiro

Lushbinary uses Kiro for client projects where the cost of incorrect delivery is high: payments flows, healthcare apps, scheduling systems, and data platforms. The spec-first workflow forces us to nail requirements before code, which cuts rework and gives the client a reviewable artifact at every step.

We pair Kiro with Cursor or Claude Code for rapid prototyping, Antigravity for frontend-heavy work with built-in browser verification, and custom MCP servers for AWS infrastructure automation. The result is a multi-tool workflow that matches the tool to the job.

❓ Frequently Asked Questions

📚 Sources

• Kiro official site
• Introducing Kiro blog post
• Kiro FAQ and pricing

Content was rephrased for compliance with licensing restrictions. Pricing and feature details sourced from official Kiro documentation as of May 2026. Pricing and features may change, always verify on the official site.