The world of AI agents is evolving at a breathtaking pace. I think I have already written more articles about coding agents this year than blog posts in all of 2024. Having already shared my experiences with various other coding agents here on the blog, I now had the opportunity to test Kiro, Amazon's vibe coding agent, during a 14-day beta period. Kiro's approach is fundamentally different from the competition. Rather than acting as a reactive assistant in the IDE or an asynchronous "pull request generator", Kiro follows a structured, multistage process: first, you work with an agent to create a detailed specification and a design document before a second agent works through the actual implementation plan. In this blog post, I want to share my experiences with this working model.
A Planned Approach
My previous experiments with AI agents have shown that the quality of the result depends heavily on how clear the initial task description is. Kiro seems to want to tackle this problem at its root. The process I went through in my test is divided into several phases that closely follow a traditional software development process.
Instead of simply typing a prompt, Kiro's approach is to have you deliberately create your specifications and always keep them visible in a central place within the project.
Kiro itself is based on Visual Studio Code and has been extended with extensions to put more emphasis on the specification.
Phase 1: The Specification and Design Document
The first agent is responsible for creating the specification. Everything starts with a simple text prompt, much like other AI assistants. I described my requirement to implement a new, larger feature for my CLI tool n98-magerun2. The agent captured my requirement and turned it into a structured requirements.md and a design.md.
The design.md was the centerpiece of this phase. It described the architecture of the new feature, defined the classes and their interfaces to be created, and provided a clear overview of the expected data models and error handling. This is a major difference from other agents, which often start generating code immediately. Here, I felt that I was genuinely involved in designing the solution, rather than simply receiving a finished result that I would then have to laboriously debug.
And this is what a design document looks like (the file is much longer):
A design document like this contains example code for important interfaces and describes configurations as well as the architecture. Diagrams were also embedded in the Markdown document in Mermaid format.
Phase 2: The Implementation Plan
Once the design document was approved, the next phase began: creating a detailed implementation plan. A new agent took over and broke the design down into a list of 11 concrete, sequential tasks.
This plan was impressively detailed (there were 11 tasks in total) and gave me full control as a developer. I could review every single step and decide whether to approve it for implementation. Kiro managed to break a complex task down into manageable, logical units that could then be worked through one by one. What you are doing here is essentially the work of a software architect.
The generated Markdown files are stored in the project and can also be versioned.
Practical Use: From Task to Implementation
As soon as a task was selected from the plan, Kiro started the actual implementation work.
The Markdown file is displayed in the editor with corresponding links to start the tasks.
I could watch the agent analyze the codebase in the background and create blocks of code step by step.
The agent did not work blindly. In one of the first tasks, which involved creating the basic interfaces and classes for the feature, Kiro was even able to run a syntax check on the generated PHP files on its own. This proactive approach to identifying and fixing errors early is strongly reminiscent of how an experienced developer works and contributes to the idea of vibe coding – the seamless transition from an idea to finished code.
Kiro validates the classes it creates on-the-fly. Sometimes code is generated purely for testing purposes, executed, and then deleted again.
The result showed that all required dependencies were loaded correctly before the agent moved on to the next task. This approach demonstrates that Kiro sees not only code generation but also verification and testing as integral parts of the implementation process.
After a task was completed, Kiro produced a summary of the implementation.
The summary was detailed and provided a precise overview of what had been achieved in each step. This helped me keep track of the amount of code being generated.
The Downsides: Quotas, Code Volume, and Control
As impressive as the process was, my test reached its limits. At step 9 of 11, my request quota was exhausted. This not only interrupted the flow of work but also highlighted one of the biggest challenges of using agents like these: dependency on external services. As I later learned, the problem was caused by Amazon miscalculating the quota, but the effect was the same: the "vibe" was suddenly destroyed. The agent stopped even though the task plan was not yet complete.
Another noteworthy detail was the sheer amount of code Kiro generated in the first eight steps. Over 60 new PHP files, complete with interfaces, implementations, and test mocks. As a developer accustomed to writing and controlling code from A to Z myself, I initially found it difficult to keep track. The feature was substantial, but I was surprised by how many files were considered necessary for its implementation.
This raises the central question of the developer's role. The agent was able to produce code that did not work as a whole. That is not surprising, since the specification comes from a GitHub Issue (#1618), and it can never be so perfect that it covers every eventuality. Manual review and fine-tuning remain essential. The work shifts from being purely a "coder" to being a "conductor" who orchestrates the work, evaluates the results, and personally handles the final 20 percent of quality assurance. Here too, you are working more in the role of a software architect and a test manager.
This is exactly where the vibe killers lurk:
- A large portion of the generated code was unnecessary and had to be removed again by me.
- I had to adjust the generated tests so they would even do what I had originally intended.
- Because the agent had lost the
Context(the agent's work) after a certain amount of time and I had to restart the process, I was unable to see thePull-Requestcontaining all the changes.
My Conclusion and Outlook
Kiro is a fascinating tool, and its process-oriented approach deeply impressed me. Working together to develop a specification and an implementation plan is an intelligent approach with the potential to revolutionize collaboration between humans and machines. The idea of breaking complex tasks down into clear, understandable steps is pioneering.
Nevertheless, as with all new technologies, there is still room for improvement. Dependence on quotas, loss of context after a restart, and the challenge of keeping track of large amounts of automatically generated code are issues that need to be addressed in the future.
For me, Kiro proved to be a valuable tool for the initial, foundational implementation steps. It helps overcome the "vibe killer" of an empty code editor and quickly creates a solid foundation. You write a simple sentence, and Kiro first turns it into a nice draft of requirements.
The work that follows – fine-tuning, refactoring, and adapting to the specific project context – remains in the hands of the human developer.
It is clear that we are in a transitional phase. The question is no longer whether AI agents will change our work, but how we can best learn to work with them. The developer of the future will not just be a programmer, but also a good "agent handler" who can define tasks precisely and critically evaluate the results. Kiro is another exciting step along this path.