Kiro for spec driven software and platform work

Kiro is a development environment that combines a code editor with AI agents and a formal specification workflow. Its goal is to move beyond ad hoc prompting by asking teams to define what they want in a structured way and then letting the agent implement that plan. Kiro is based on Code OSS, so it feels similar to Visual Studio Code, and it suits platform teams that value repeatable processes and clear specifications.

What Kiro is

Kiro converts a request into structured requirements using EARS (Easy Approach to Requirements Syntax) notation, then builds a design and a task list before writing code. EARS expresses acceptance criteria in a testable form such as WHEN a condition THE SYSTEM SHALL a behaviour. The tool keeps natural language interaction at the front while still requiring the rigour of written specifications, and it can run independent tasks in parallel to speed up execution.

Setup

Kiro is distributed as an IDE. You download it from kiro.dev and install it like any other editor. Because it is based on Code OSS you can import your VS Code settings, themes and Open VSX compatible plugins. Kiro runs on Windows, macOS and Linux. You sign in with one of several options, including GitHub, Google, an AWS Builder ID or AWS IAM Identity Center. AWS integration is optional and you do not need an AWS account to use Kiro.

Core workflow

Kiro's workflow is explicitly spec driven. Every spec generates three files. You start with a requirements document (requirements.md, or bugfix.md for a bug fix) that describes the change as numbered user stories and EARS acceptance criteria. Next the agent produces a design document (design.md) that explains the architecture, data flow and key functions. Finally Kiro produces a tasks document (tasks.md) that breaks the design into concrete tasks. Code changes happen only after these documents exist. Tasks run sequentially or in parallel depending on their dependencies, and Kiro can run all independent tasks concurrently in waves.

For each task the agent proposes code changes and shows diffs, runs tests and updates the task status. Because the work is defined in tasks.md, you always know what the agent will do next. Bugfix specs follow the same three-phase structure, capturing current behaviour, expected behaviour and what must stay unchanged.

Steering and memory

Kiro gives the agent persistent context through steering files. These markdown files live in .kiro/steering/ for a specific workspace or ~/.kiro/steering/ for global settings. Three foundational files are included by default: product.md defines purpose, users and goals, tech.md records frameworks, libraries and technical constraints, and structure.md describes file organisation, naming conventions and architectural decisions. Steering files support inclusion modes: always (the default), fileMatch for conditional loading, manual for on-demand inclusion, and auto. You can add your own steering files for API standards, testing approaches or deployment workflows. Kiro also recognises AGENTS.md, which is always included and does not use inclusion modes.

Strengths

• Structured development. By making you articulate requirements, design and tasks before implementation, Kiro reduces ambiguity and encourages thoughtful design, and the specs act as living documentation.
• Persistent context. Steering files give the agent memory of your conventions, so it does not need reminding of preferred frameworks, folder structures or naming patterns.
• Parallel execution. Kiro runs independent tasks concurrently, which accelerates long-running changes across a large codebase.

Limits

Kiro assumes a formal specification exists for every change. For one-line fixes or exploratory coding this overhead can feel heavy. EARS notation and the three-document structure add a learning cost, and tasks need to be kept in step with the spec. Because Kiro emphasises a controlled workflow, it is less suited to rapid prototyping. Kiro is also proprietary: although it builds on open source components, it requires an account.

When to choose Kiro

Choose Kiro when you want the discipline of spec driven development. It is especially useful for platform teams building internal services or infrastructure that need traceability and strong conventions. The combination of formal requirements, design documentation and task orchestration helps align engineers and maintain quality across a large codebase. For small projects or quick experiments, a lighter tool may be more appropriate.