Amazon Kiro AWS Agentic IDE: 2026 Developer Guide

What Is Spec-Driven Development

Spec-driven development is the organizing paradigm behind every Kiro feature. The idea is straightforward, but the implications are not. Instead of writing code and asking the AI to help you along the way, you write a specification that describes what a component, service, or feature does, and the editor takes responsibility for generating and maintaining code that matches the spec.

In Kiro the spec is a living document stored alongside the code it governs. Edits to the spec propagate into code changes through agent runs, and edits to the code that drift from the spec either trigger a re-sync or a spec update. The model is inspired by infrastructure-as-code patterns and by the intent-driven programming ideas that floated around the early agentic tooling waves, but Kiro is the first mainstream IDE to make it the default workflow.

Why Invert the Artifact Order?

The practical argument is that specs are more stable than code. Requirements change less frequently than the implementation choices used to satisfy them, so anchoring the source-of-truth higher up reduces the amount of churn that needs human review. Engineering time shifts from typing code to describing behavior, reviewing generated output, and maintaining the spec as the product evolves.

The cultural argument is that specs are reviewable by people who are not the author. Product managers, designers, and tech leads can read and approve a spec in a way that they usually cannot for a raw diff. Kiro leans into that by making spec review a first-class part of its pull request flow.

Kiro Architecture: Specs + Hooks + Agents

Kiro's moving parts reduce to three primitives. Specs describe intent. Agents translate specs into code and keep them aligned. Hooks automate the surrounding workflow. Understanding how these three interact is the shortest path to evaluating whether Kiro fits a given team.

The Daily Loop

A typical Kiro workflow begins in the spec. An engineer opens or creates a spec file, describes the change they want, and asks the agent to synthesize. The agent reads related specs, fetches relevant code, and produces a set of proposed edits across the repository. The engineer reviews the diff, accepts or iterates, and opens a pull request. Hooks then take over, running tests, updating docs, and propagating the change to any downstream specs that reference the edited one.

This is the loop that engineers either love or bounce off. Teams that treat specs as genuine deliverables find that the daily loop is both faster and more reviewable than traditional code-first workflows. Teams that treat specs as overhead usually revert to using Kiro as a glorified code completion tool.

The Hooks System Explained

Hooks are the feature that keeps most Kiro teams on the platform once they've adopted it. They are the Kiro-specific answer to the automation layer that teams usually cobble together from GitHub Actions, custom scripts, and chat integrations. By moving that layer inside the editor, Hooks become trivially easy to author, review, and version alongside the code they govern.

Hook Triggers

• File events — save, create, delete, or rename of a specific file or glob pattern.
• Spec events — spec created, spec edited, spec approved, spec synthesized to code.
• Repo events — branch created, pull request opened, review requested, merge completed.
• External events — CodeCatalyst workflow state changes, S3 uploads, EventBridge messages, or scheduled cron triggers.

Common Hook Patterns

A few Hook patterns show up in nearly every mature Kiro deployment. Running unit tests for any file touched by an agent run is the most universal. Regenerating API client stubs whenever a service spec changes is a close second. Cascading spec edits through consumer specs — so that changing a payload schema in one service prompts consumers to update their own specs — is the pattern that most reliably pays for the migration cost.

# .kiro/hooks/regenerate-clients.yaml
name: regenerate-clients
on:
  spec_change:
    paths:
      - specs/services/**/*.spec.md
run:
  agent: sonnet
  task: |
    The service spec at ${event.path} changed.
    Regenerate client stubs in packages/clients/
    and open a PR if the diff is non-empty.
  approval: pr_review

Hooks can run with or without human approval. Approval-required hooks are the safer default for anything that touches production code or external systems; auto-approved hooks are appropriate for low-risk work like fixture regeneration, doc updates, and lint fixes.

Model Routing: Claude Sonnet vs Nova

Kiro's agents are not locked to a single model. Requests route between Claude Sonnet and Amazon Nova depending on the task type, with Bedrock as the shared model plane. Understanding how that routing works is important for both cost planning and quality tuning.

Overriding the Default Routing

Kiro exposes per-Hook and per-agent overrides, so teams can pin specific workflows to either model family. Common overrides include pinning all security-sensitive spec work to Sonnet, and pinning high-frequency formatting and fixture hooks to Nova to keep Bedrock spend predictable. For a deeper comparison of the Claude Sonnet family, see our Claude Sonnet 4.6 benchmarks and pricing guide.

AWS Stack Integration

Kiro is not a neutral IDE that happens to run on AWS. It is designed to sit inside the AWS tooling ecosystem and expects to talk to the rest of the stack out of the box. That is the primary reason an AWS-first team should consider it, and the primary reason it makes less sense for teams running elsewhere.

Third-Party Integrations

Beyond the core AWS stack, Kiro ships with integrations across source hosts, CI systems, chat platforms, and observability tools, covering a catalog of over ninety integrations at the time of writing. GitHub, GitLab, Slack, Linear, Jira, Datadog, and the usual set of modern engineering tools are all present. The integration surface looks similar to what Cursor or Claude Code offer, but with the addition of first-party AWS connectors that the others can only hit through generic HTTP calls.

Pricing and Quota Structure

Kiro's commercial model combines a per-seat IDE subscription with metered AWS usage for the underlying Bedrock model calls and related services. The exact numbers have shifted since launch, so the framing below focuses on structure rather than specific cents-per-token, which teams should always validate against current AWS pricing pages.

The practical implication is that Kiro's total cost of ownership is harder to eyeball than flat-rate tools like Cursor. Teams already running heavy AWS infrastructure usually see Bedrock spend blend into existing usage and treat the marginal cost as reasonable. Teams moving onto AWS primarily for Kiro will find the spin-up more painful, because they inherit the full AWS pricing model on top of the IDE seat.

Kiro vs Cursor: When AWS-First Wins

Kiro and Cursor solve overlapping problems with different philosophies. Cursor leans into code as the primary artifact and makes AI assistance feel like a souped-up keyboard shortcut. Kiro inverts that order and asks teams to adopt a spec-first workflow in exchange for deep AWS integration. Neither is objectively better; the right answer depends on the stack and culture.

Kiro wins when a team is already deep on AWS, values spec-first review, and has engineering leadership willing to sponsor the workflow change. Cursor wins when a team ships to heterogeneous infrastructure, values editor flexibility, and prefers to layer AI over a code-first workflow. Both can coexist inside a large organization, and many agencies end up using Cursor for day-to-day development and Kiro for long-running AWS-native services.

For a broader view of how Kiro, Cursor, Claude Code, and other agentic IDEs stack up head-to-head, see the Q2 2026 agentic coding tools matrix and the Claude Code vs Codex vs Jules matrix.

Kiro in Agency Workflows

Agencies running Kiro for client work face a different set of constraints than a single-product engineering team. Client IP must stay isolated, billing must attribute cleanly, and tooling must survive engineers rotating on and off projects. Kiro's AWS foundation helps with most of these, as long as the team leans into the primitives rather than fighting them.

Most of this tooling lines up with broader enterprise agentic coding patterns. See the enterprise coding agent deployment playbook for a deeper treatment of multi-tenant agentic tooling.

Migration Path: Cursor / VSCode Teams

Migrating from Cursor or a stock VSCode setup to Kiro is mostly a workflow change, not a tooling change. The editor surface looks familiar enough that most engineers adapt within days. The harder shift is cultural: specs become the primary review surface, which reshapes how teams plan work, split tasks, and sign off on changes.

Phased Rollout

1. Pilot on one service. Pick a bounded service or internal tool, rewrite its spec, and let one or two engineers work exclusively in Kiro for two to four weeks. Track cycle time, review quality, and incidents.
2. Codify Hook conventions. Extract the Hooks that proved useful in the pilot into a shared library, and document the triggers and approval rules the team will apply going forward.
3. Expand to adjacent services. Roll Kiro out to services that already share contracts with the pilot service, so spec cascades have somewhere to land.
4. Update review process. Shift pull request templates and review checklists to lead with spec changes. This is the single highest-leverage cultural change.
5. Onboard remaining teams. Once the spec-first workflow is load-bearing, bring in the rest of the organization with paired onboarding sessions led by pilot engineers.

Keeping Cursor or VSCode Around

Most teams keep Cursor or VSCode available during and after migration. Engineers doing quick edits, prototyping, or working on non-AWS services often prefer their existing editor and use Kiro for the services that benefit most from spec-first work. Treating the two tools as complementary rather than mutually-exclusive is usually the lowest-friction path.

For teams tracking broader agentic coding adoption trends during this transition, the 2026 AI coding tool adoption survey is a useful reference for benchmarking where your team sits relative to the wider market.

Common Migration Failure Modes

• Treating Kiro as an AI completion tool. Teams that never actually write specs end up paying for the IDE and AWS infrastructure without any of the workflow benefit.
• Mixing client tenants in one workspace. Skipping per-client AWS accounts or shared spec repos accumulates IP-leakage risk that's hard to unwind later.
• Ignoring Bedrock spend. Default routing is fine at small scale; at medium scale it needs a quarterly audit or it drifts expensive.
• Skipping the culture shift. Without leadership buy-in for spec-first review, engineers will quietly revert to code-first habits and Kiro's core value disappears.

Conclusion

Kiro is a serious, well-built agentic IDE with a clear opinion about how software should be built. For AWS-first teams willing to invest in a spec-driven workflow, it collapses a meaningful amount of glue work and opens up automation patterns that are expensive to replicate in Cursor or stock VSCode. For teams on other stacks, the math usually favors staying with a stack-agnostic editor and adding Kiro only if an AWS-centric project demands it.

The single biggest mistake teams make with Kiro is treating it as a Cursor replacement. It is not. It is a bet on a different unit of engineering work, and it pays off only when the culture shift lands alongside the tooling change. Pilot it honestly, measure the workflow impact rather than the editor experience, and make the call with eyes open.

Frequently Asked Questions