From EARS requirements and technical design to task planning, Amazon Kiro provides a specification-driven workflow for AI-Driven Development.

What is Amazon Kiro?

Amazon Kiro is an IDE based on Visual Studio Code. Kiro is offered by Amazon Web Services (AWS) and aims to support developers in the transition to AI‑Driven Development. Unlike other IDEs that typically require additional plugins to connect AI agents, Kiro comes with AI integration out of the box.

What makes Kiro special is its predefined, specification-driven development approach. With AI support, developers first write requirements in the so-called EARS notation. I’ll go into that in more detail below. Kiro then generates a technical design and a detailed implementation plan including the tasks to be completed. AI agents then automate the execution of those tasks. Kiro also offers features like “Agent Hooks” for event-driven automations. I won’t cover those further in this post.

Kiro uses the latest Anthropic models that Amazon provides via AWS Bedrock. You can either select the specific Anthropic model manually or let Kiro choose depending on the task at hand.

Kiro can be downloaded and tried out free of charge at first (https://kiro.dev). It’s based on a credit system, meaning you have a certain number of requests per month for free until the credits run out. After that, you need a subscription. Details can be found on the Kiro website linked above.

The Kiro workflow at a glance

Kiro has two main modes you can switch between when starting a new session with the AI: “Vibe Session” for fast prototyping and “Spec Session” for structured, specification-driven development. The latter is the recommended option for serious projects and forms the core of Kiro. In the following, I’ll only talk about Spec Sessions. Vibe Sessions largely correspond to the familiar AI‑Driven Development approach with plugins like GitHub Copilot or OpenAI Codex (see also my earlier post OpenAI Codex vs. GitHub Copilot). If you are interested in a more agent-centric IDE approach, Google Antigravity is an interesting alternative.

Structure of a Spec Session

Kiro splits the development process of a Spec Session into three phases and assigns a file in the workspace to each: requirements elicitation (Requirements.md), technical design (Design.md), and implementation (Tasks.md). Each phase builds on the previous one; switching is done explicitly by the user. The respective file is automatically generated or updated. Actual coding only starts once the implementation plan is available in the Tasks.md file. In my view, this structured approach reflects best practices for running an AI‑Driven Development process.

For each Spec Session, Kiro automatically creates a directory under /.kiro/specs/ in the workspace. For simple projects like my sample application, a single Spec Session is sufficient. For more complex projects, it can make sense to create a separate Spec Session per Jira epic or even per user story to keep things manageable.

Requirements.md with EARS notation

The Kiro workflow starts with eliciting and documenting requirements in the Requirements.md file. What’s particularly interesting here is the use of EARS notation. EARS stands for “Easy Approach to Requirements Syntax”. The notation was developed in 2009 by Alistair Mavin at Rolls‑Royce to reduce the ambiguity of natural language by using a structured syntax with a small number of keywords. In principle, an EARS requirement always follows the pattern below (there are various extensions and variants; see the original documentation at https://alistairmavin.com/ears):

WHILE "precondition" WHEN "trigger" THE "system name" SHALL "system response"

Example:

WHEN an administrator creates a survey
  with title and creator (optional description, start and end date),
THEN THE Survey_System
SHALL create a new survey with a generated unique identifier
  and store all provided metadata

WHILE and WHEN define the conditions under which the requirement applies, while SHALL describes the expected system response. In most cases, either WHILE or WHEN is used to specify the requirement.

Kiro supports the entire specification process in EARS notation. For example, you can use existing requirements documents as a starting point. Alternatively, you can work with business stakeholders (and Kiro) to develop the specification in a question-and-answer format.

A complete example of a Requirements.md file shows the EARS notation in action.

Design.md: Technical design

To switch to the design phase, open Requirements.md in Kiro, click the “2 - Design” button, and then click “Generate design based on requirements”. Kiro analyzes the requirements and automatically creates a technical design in the Design.md file. This clearly shows the difference compared to other IDEs with AI integration: Kiro actively helps structure the development process.

However, this automation also has its downsides: Kiro initially generates the design exclusively based on the requirements. The result was quite okay in my tests, but my sample application (a survey app) is also fairly trivial. Like all AI models, the Anthropic models operate on probabilities, so the result is a more or less generic architecture for a microservice with a REST API and database integration. In real projects, there are always additional constraints and requirements that are not explicitly mentioned in the requirements document but still influence the design (e.g., existing architectural guidelines, specific non-functional requirements like performance or scalability, preferred technologies or frameworks, etc.).

I therefore recommend thinking about the architecture before generating the design and documenting it in a separate Markdown file. In addition, you should always create a semantic data model to clearly define data structures and their relationships (see also my blog post). You can then provide that groundwork to Kiro and ask it to revise the design accordingly.

Regardless, I liked the structure of the generated design document. It includes, among other things:

• Architecture overview with predefined layers (REST controllers, services, repositories, entities)
• Tech stack (Spring Boot 3.x, Java 21, PostgreSQL, JPA/Hibernate)
• Design decisions (UUIDs, validation-first, cascading deletes, stateless REST).
• API specifications for all endpoints
• Data model for the entities
• Test setup: Kiro suggests a “Property-Based Testing” (PBT) approach in addition to classic unit tests. PBT is a technique where, instead of individual test cases, you define general properties that the code must satisfy. The test framework then automatically generates a large number of inputs to verify those properties. This can help cover edge cases and unexpected inputs that conventional unit tests may miss. PBT comes from functional programming and is commonly used in languages like Haskell or Scala. In the Java ecosystem, PBT is less common, but there are libraries such as jqwik that support it. In my view, this test strategy suggested by Kiro is a typical example of the benefits an AI‑Driven Development process can provide: with the help of AI agents, developers can learn new techniques and best practices and integrate them into their workflow.

The full example of the generated Design.md file shows the technical design produced by Kiro.

Tasks.md: Implementation

Once the design phase is complete, you switch to the implementation phase in Kiro via the “3 - Task list” button. Kiro then automatically generates a Tasks.md file containing an implementation plan. A nice touch is the automatic selection of the “right” context: Kiro now knows the requirements and the design, and it also automatically analyzes the existing code in the workspace.

The plan structures the actual implementation into tasks and subtasks. Each task is linked to the corresponding requirements, so you can always trace why a particular task is being implemented. Kiro also automatically prioritizes the plan based on dependencies so the tasks can be completed in the “right” order.

The actual implementation then happens by clicking “Start Task” directly in the file. This can be done for individual subtasks, tasks, or even for the entire plan (in that case, however, only explicitly when requested in the prompt). In the Kiro documentation, Amazon recommends working through tasks step by step, as overall quality is supposedly higher that way. It also keeps you in control of the process and lets you perform the necessary reviews and tests in smaller chunks.

Integration into the development workflow is again very well done: Kiro automatically updates the Tasks.md file as soon as a task is completed. This makes it much easier to keep track of progress than with traditional IDEs with AI plugins.

Kiro can also automatically adjust the tasks in the implementation plan to the current state of the source code (e.g., because team members have made changes). All you need to do is click the “Update Tasks” button. Kiro then analyzes the workspace and updates the plan accordingly. This also includes automatically checking off completed tasks that Kiro recognizes as done when comparing the code with the plan.

The actual implementation is similar to conventional AI plugins like GitHub Copilot or OpenAI Codex. Kiro generates code snippets based on the current context (requirements, design, tasks, existing code) and inserts them directly into the relevant files. Developers can then review the generated code, adjust it, and commit it to their version control system.

Conclusion

Kiro is an exciting new approach to AI‑Driven Development. It goes beyond the classic AI plugin and provides a predefined, structured development workflow. I particularly liked the seamless integration of the workflow into the IDE, the structure and completeness of the automatically generated documents, and the clear separation of the different phases.

The biggest downside of Kiro, in my view, is its reliance on EARS notation for requirements documentation. I generally find EARS helpful for phrasing requirements clearly and in a testable way. However, I think readability for humans is rather poor. In addition, while the desire to capture requirements in such a structured way is understandable and also desirable, it’s not always easy to implement in practice. You have to be careful not to end up with two sets of requirements: the “normal” ones in natural language and the EARS version. That would undo many of the potential benefits of EARS.

Whether the limitation to Anthropic models is a drawback is something everyone has to decide for themselves. Personally, I think the Anthropic models are very good, but there are certainly use cases where other models are better suited.

Overall, I think Kiro is perfectly suited for a quick entry into AI‑Driven Development: the predefined workflow makes the transition much easier. At the same time, that very structure can become a brake if it doesn’t match your own requirements and ways of working. In such cases, it’s often better to consciously invest time in your own AI‑Driven Development process that is better tailored to your individual needs. You can implement such a process with other AI plugins and models in your IDE as well.