Kiro: The AWS Agentic IDE That Puts Specs Before Code

Vibe coding made prototyping faster than ever. It also created a new failure mode: AI-generated code that works in the demo, drifts in staging, and collapses under production load. The gap between "AI wrote it quickly" and "a team can maintain it" has become one of the defining engineering problems of 2026.

Amazon's answer is Kiro — an agentic IDE that inverts the traditional workflow. Instead of writing code and describing context in chat, Kiro makes the spec the source of truth and treats code as a build artifact. Launched internationally on May 7, 2026 as the ground-up replacement for Amazon Q Developer, it represents a genuine architectural bet on what structured AI development should look like.

What Kiro Is (and What It Is Not)

Kiro is an IDE built on Code OSS — the same open-source base as VS Code — so your existing keybindings, themes, and Open VSX plugins carry over. It runs on Mac, Windows, and Linux, and is currently free during its preview phase.

Underneath the familiar surface, Kiro routes between two model tiers via Amazon Bedrock: Claude Sonnet 4.5 handles reasoning-heavy tasks like spec authoring, design critique, and complex multi-file refactors. Amazon Nova handles high-throughput mechanical work — inline completions, fixture generation, lint fixes. Teams can override routing per-hook or per-agent, and Claude Opus 4.8 is available for the most demanding tasks.

The core philosophy is direct: the spec is source-of-truth, and code is a build artifact. This inverts how Cursor, GitHub Copilot, and Claude Code work, where code is primary and context arrives ad hoc through chat. Kiro's argument is that code written without an upstream spec drifts — from architecture, from requirements, from each other.

The Three-Phase Spec Workflow

Every feature in Kiro starts as a spec. Creating one takes under a minute: click Spec in chat or the + in the Specs panel, describe your feature in plain language, and Kiro expands it into three structured phases.

Phase 1 — Requirements. Kiro converts your description into EARS notation (Easy Approach to Requirements Syntax), a structured format that captures user stories with explicit acceptance criteria. Instead of a vague backlog ticket, you get: "Given a logged-in user, when they submit the login form with an unrecognized email, then the system returns an error message within 2 seconds." No ambiguity, no interpretation gap.

Phase 2 — Design. From the requirements, Kiro generates a technical design document: data flow diagrams, TypeScript interfaces, database schemas, and API endpoint definitions. This document stays synchronized with your codebase as it evolves — bidirectional updates mean the spec and code can never silently diverge.

Phase 3 — Tasks. The design breaks into sequenced implementation tasks, each linked to its requirement. Tasks cover not just code changes but unit tests, integration tests, accessibility considerations, and responsive design checks. Everything that ships is accounted for before the first line is written.

Agent Hooks: Automation Without Prompting

Hooks are the part of Kiro that most surprises developers coming from chat-first tools. They are event-driven background agents that fire automatically — no manual prompting required.

Configure a hook by describing what you want in natural language, then selecting the trigger event. Kiro generates the YAML configuration:

# .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

Hook triggers span four categories:

• File events — save, create, delete, rename
• Spec events — created, approved, synthesized, edited
• Repo events — branch, PR open, review submitted, merge
• External events — cron schedules, S3 events, EventBridge, CodeCatalyst workflows

A practical example: a hook that fires on every file save to update test files when the component changes, and another that regenerates API documentation when an endpoint definition is modified. These are the tasks that slip through the cracks during fast-moving sprints. Hooks make them non-optional.

Steering Files: Project Memory That Persists

Chat-first coding tools require you to re-explain your architecture every session. Kiro solves this with steering files — markdown documents in .kiro/steering/ that capture persistent project knowledge:

• Product purpose and domain context
• Technical stack and framework choices
• Project structure and naming conventions
• Team standards, code style rules, and anti-patterns to avoid

Generate the initial set automatically via "Generate Steering Docs" in the Kiro panel. Every agent interaction reads these files without prompting. A new team member, a new session, a new hook — all inherit the same context automatically.

Custom steering files can cover specific domains: a payments.md that explains your Stripe integration patterns, a database.md that enforces your migration conventions. The more specific the steering, the less correction is needed during execution.

How Kiro Compares to Cursor and Claude Code

The honest summary: Kiro is not a Cursor replacement. It is a bet on a different unit of engineering work — the spec rather than the commit. Teams that have suffered from AI-generated technical debt will find the structure welcome. Teams optimizing for raw iteration speed may find it constraining.

Getting Started

1. Download Kiro at kiro.dev — available for Mac, Windows, and Linux
2. Open your project with kiro . from the terminal, or via File → Open Folder
3. Generate steering docs — click the Ghost icon → Kiro Panel → "Generate Steering Docs"
4. Create your first spec — click Spec → describe a feature → review and iterate on the three-phase output
5. Set up a hook — Agent Hooks → + → describe the automation → set event type and file pattern

The preview is free. After general availability, costs combine a per-seat IDE subscription with metered Bedrock token usage, plus any CodeCatalyst compute minutes and supporting AWS service costs. Total cost of ownership is harder to model than flat-rate tools — budget accordingly.

MENA and Enterprise Considerations

For organizations in the MENA region, Kiro's AWS integration carries specific advantages.

If your team already runs workloads on AWS — common in Saudi Arabia, UAE, and Egypt — the deep Bedrock and IAM integration removes friction. No separate API key management, no additional vendor relationships.

Bedrock's regional deployments include Middle East South (Bahrain), which means specs and code context can remain within regional boundaries. For regulated industries — fintech, government, healthcare — this matters significantly.

The adoption caveat is real: Kiro requires a genuine workflow change. Engineers comfortable with chat-first coding will need two to three weeks to internalize spec-first thinking. Without leadership buy-in for spec-first review, the pattern quietly collapses. The tool cannot substitute for the cultural shift.

Who Should Evaluate Kiro Now

Strong fit — AWS-native teams with compliance requirements; engineering organizations recovering from AI-generated technical debt; projects where spec-to-code alignment determines reliability (API-driven services, multi-team coordination, regulated domains).

Weaker fit — Solo developers or small teams on GCP or Azure; rapid-prototyping contexts where specs slow the iteration loop; teams not already embedded in the AWS ecosystem.

The free preview lowers the evaluation cost to near zero. For any team that has shipped vibe-coded features and spent the next sprint cleaning up the drift, Kiro's approach deserves a serious look.

The broader argument Kiro is making is not subtle: AI tools that generate code without generating shared understanding are building on sand. Specs are not bureaucracy — they are the shared model that lets multiple agents, and multiple engineers, work on the same system without stepping on each other. Whether that argument wins depends on whether teams are willing to front-load the structure that today gets back-loaded as debugging.

For production engineering in 2026, that trade looks increasingly favorable.