Amazon Q - Kiro-dev

Of all the IDEs, CLIs, and systems in general that allow process automation through agents that I’ve tested, Kirodev has definitely been a great surprise. I decided to create a very simple test application: I obtained a dashboard-style template and replicated the components and look and feel as closely as possible.

When installing the IDE, I found a new tab showing the enhanced tools: Specs, Hooks, Agent Steering, and MCP (I’ll explain this in more detail later). On the right side, the chat window, very similar to any other chat, like Kilocode, Continue, Windsurf, etc.

But what makes it innovative? In my opinion, the simplified implementation of SDD (Spec Driven Development) is very well executed. Unlike GitHub’s version (GitHub Spec Kit), which is more complex and requires more definitions, Kiro integrates a simplified version that allows maximum control over the project’s development. You could say it’s vibe coding with steroids and a police officer watching every step. To me, this is truly the next step in the evolution of programming, where the machine handles the routine work and developers focus on the logic and architecture of the project.

SDD (Spec Driven Development)

Programming through specs basically means you first define the specifications (specs)—a clear document describing what a functionality must do and how it should behave—and then you write code based on those specifications.

To program using SDD in Kiro, we need to define 3 base files:

requirements.md

Here, we define user stories and acceptance criteria, just as we do in Jira or any other ticketing tool, but using the EARS (Easy Approach to Requirements Syntax) notation. This notation looks like this:

WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]

This way of defining requirements allows greater clarity and traceability.

design.md

In this file, we define the entire architecture—everything we need for implementation, diagrams, etc.
Here, we define how our system will work in terms of components and their interactions.

tasks.md

This is our implementation plan. Here we define the list of tasks to follow, step by step. Each task must be well defined and must specify what will be received. We must also specify whether we have dependencies (external libraries or other resources).
One advantage is that this file runs task by task, allowing more granular control over the changes made.

PBT (Property Based Tests)

Another interesting feature of KIRO is PBTs, which in short are a more complete way of testing our development.

Usually unit tests focus on testing specific functionalities without considering the broader context; this is exactly what PBT aims to fix.
Properties are defined as the functionalities that must be fulfilled in our system. (For example, if we define a login, the user should be able to log in.)

Example of a PBT:

Traditional test: The user adds car #5 to favorites, car #5 appears in their favorites list.

Property-based test: For any user and any car, WHEN the user adds the car to favorites, THE system MUST display it in their favorites list.

KIRO extracts the properties automatically from our requirements.md file and generates the test cases, trying to cover as many scenarios as possible.

Agent Steering

If the specs define what needs to be created, agent steering defines how it must be created. This allows controlling the agents and telling them how to generate the implementation following specific rules.

For example, if I have a project using React + Vite + Tailwind + TypeScript, I could define an agent steering file like the following:

components:
  style: tailwind
  layout: responsive
  propsValidation: TypeScript interfaces
  interaction: hooks only

files:
  structure:
    - src/components
    - src/features
  namingConvention: PascalCase for components

pages:
  mustInclude:
    - Header
    - Sidebar
    - MainContentLayout

In short, specs are the map and steering is the driver.

Hooks

Another interesting addition is hooks, which are functions that trigger through events—events tied to creating, editing, or deleting a file, or even triggered manually.

Hooks receive a prompt as a parameter and, depending on their trigger, can be very useful for code review, documentation, security review, automated commit message generation, and much more.
An example of a manual hook would be:

Review the current file for:
1. Code quality issues
2. Potential bugs
3. Performance optimizations
4. Security vulnerabilities
5. Accessibility concerns

This hook would be executed manually on whichever file we choose.

While there is an ocean of tools like this right now (Cursor, TRAE, Windsurf, Antigravity, etc.), KIRO has something in its favor: integration with AWS and its simplified definition of Spec Driven Development.
Despite being a good tool, it is not exempt from errors—like all tools. Sometimes agent execution gets stuck, and lately, due to high demand, it takes a long time to execute some processes.

We’ll see in a few months whether it manages to position itself as a leading tool in the market.