The new AI IDE, Kiro, has just been launched in preview, and over the past few weeks, I have been able to try its features. Below, I share some of my initial experiences and the unique advantages Kiro has brought to my software development flow.
Kiro has two different ‘modes’: spec mode and vibe mode. The vibe mode is how most developers would understand it - direct implementation based on a prompt focusing on conversational style and without a formal structure. However, what makes Kiro unique is the spec mode. During a spec session, a formal workflow is followed using a structured approach. This makes it easier to plan and coordinate tasks, resulting in a paper trail for future reference and team collaboration. The whole flow of spec-driven development is something new and different, and I have really enjoyed the organised and logical way of programming, which is very different from the at times chaotic vibe coding where you are unsure of what is happening and how to fix things that have gone wrong.
I have been testing Kiro with a couple of existing projects, where the expectation for Kiro is to start by scanning the project and trying to understand the requirements and the structure of it. Kiro creates spec files that are like documentation for your own little project manager.
To illustrate, I'll use a simple serverless project that utilizes AWS services. Kiro is versatile and compatible with any cloud provider, but AWS was simply what I used for this particular project. The project had a functioning Lambda function code that interacts with Amazon Bedrock and some database tables, but there was no infrastructure as code apart from an empty CloudFormation folder. Generally, the project was unorganised and uncompleted and my first prompt requested Kiro to improve the repository structure and also add the infrastructure-as-code capability for the project. Based on this prompt, Kiro started to create documentation in the specs folder based on it’s standard design - requirements - tasks -flow. I will describe below the flow in more details in the context of this specific example.
Design
The purpose of the design.md document is to describe what Kiro is aiming to achieve with the steps that it is planning to take. In my specific example, the document contained the following details:
Current state of the architecture (for example, agent.py located at the repository root)
Target state of the architecture represented as a directory tree
Infrastructure as code - listing how the files will be structured and where this like development environment parameters will be stored. The design document also listed all the AWS resourced that the IaC is meant to create
Documentation updates that would be done on the README.md after the steps have been completed
Data models that would be used in the DynamoDB tables
It also describes thing like error handling, testing strategy and implementation considerations
Once Kiro has completed the design document it will ask you to verify whether you are happy with it before moving on to the next step. At this point, you are able to ask it to make modifications if want to make a change or if you want to exclude something (for example, testing) and tackle it as a separately later on.
Requirements
Once you have confirmed that you are happy with the design file, Kiro will move on to create the requirements.md file. In this document, it will summarise the requirements to user stories, which for my specific project were, for example, the following:
Each of these requirements will have an acceptance criteria listed in the form of when - then - shall -statements:
Tasks
After you have confirmed that you are happy with the requirements file, the fun part begins. Kiro is going to create a tasks.md file. This file will list all the different tasks that need to be taken in order to reach the previously described design that follow the requirements. In my example, the first task was to create new directory structure and move source files. This task included not only creating and moving the files, but also updating any relative import paths if needed. The task file also clearly describes which requirements this specific task is going to fulfil.
The nice things is that you are able to manually start the tasks directly from the file, and you will always have an easy overview of which tasks have already been completed and which are still waiting for completion. After the task have been completed, you can easily review the changes that have been made:
This allows you to easily follow execution step-by-step and request changes as you go if anything doesn’t look the way you wanted it to.
Further specs
After completing the tasks from my original prompt, I asked Kiro to complete a few additional features. The first request was to add an AWS API gateway in front of the Lambda function, and the second was to create a simple frontend application to provide a user-friendly interface. For both of these requests, Kiro created new spec directories with their own design.md, requirements.md and tasks.md files. This separation of concerns makes it easy to keep track of what is happening and to have clear documentation for the future:
Hooks
Hooks is a feature that I have until now tested only with very basic examples, but there are plenty of use cases where it would be very valuable. Hooks are essentially event listeners that, when triggered by specific IDE events or user actions, automatically launch a full agent execution session. Kiro creates a hook folder, which contains a file for each hook.
The hook I used in this project was to update hook the documentation. It listened to the Python source files, CloudFormation templates and requirements.txt changes to automatically update the README.md document. The prompt used for the agent execution session when triggered, is the following:
‘The source code or infrastructure has been modified. Please review the changes and update the README.md file to reflect any new functionality, API changes, infrastructure changes, dependencies, or usage instructions. Pay special attention to CloudFormation template changes and deployment instructions. Ensure the documentation stays current with the codebase.‘
The nice thing about this hook is that it doesn’t only update the documentation when it has completed tasks, but the hook will make updates also if you, as a developer, have manually made changes to any of the files. Having said that, the above doesn’t take into consideration the fact that the hook will consume agentic interactions and there will be price considerations in terms of how often you want your hooks to run, so this would need to be balanced.
Conclusions
My experience of Kiro has mainly focused on the main ‘design-requirements-tasks’ -flow, and I haven’t yet had a chance to test other features such as integration with MCP servers or steering files, and I have only done some initial exploration with the hooks. With such a new product there are, of course, sometimes been small issues and bugs, but generally, I have absolutely enjoyed working with the design-requirements-tasks flow. I wonder if it also depends on the personal working and documentation style whether someone would find this way of working compelling, but I find the organisation and structure really helpful even with a personal project and in a teamwork setting, it would bring added benefits for coordination. It makes it so much easier when you can clearly follow what AI is doing and make small adjustments as needed. And having a clear documentation for future reference is the second main advantage - imagine coming back to the project after a while and having clear feature spec directories that contain tasks lists to give you an easy overview of the status.
