Two months with Kiro
I first heard about Kiro in August when Scott Tolinski mentioned it on an episode of Syntax (see Scott & CJ’s Fave Productivity Apps & Web Apps). Kiro has been in public preview for several months now, and after getting off the waiting list a month or so ago, I've had the good fortune to churn through some free credits to try it out.
What is Kiro?
The AI IDE for prototype to production. Kiro helps you do your best work by bringing structure to AI coding with spec-driven development.
Kiro is yet another Agentic IDE to enter the ring of contenders—built on top of Visual Studio Code's open source foundation—it introduces a style of agentic coding called spec-driven development that is tightly integrated into the IDE's experience of working with LLM agents.
What is spec-driven development?
This has been written about ad nauseum elsewhere (e.g., see kiro docs or gh blog post for more), but the gist is that when starting to work on a larger task or project, instead of just jumping right in to vibe code with an agent, you go through a structured interaction with your chosen AI model to:
- Specify your requirements (🔄 iterate until happy) --produces-->
requirements.md - Specify the technical design and implementation -> (🔄 iterate until happy) --produces-->
design.md - Outline the tasks needed to meet requirements and fulfill design (🔄 iterate until happy) --produces-->
tasks.md - Start tasks one by one for agent to implement with requirements and design as context.
This structured process forces you to slow down and really question what exactly it is you're trying to do and why it's the right thing to do (requirements); technically how you think you should do it (design), and then marry the requirements and design to produce a concrete set of discrete tasks that can be actioned on by an AI agent.
This process forces you to think through the why and the what on any particular thing before you just start cowboy coding something. It's unsurprising that Kiro is a product of a team from AWS, where this type of rigor is just a part and parcel of software engineering, where, if you're asked for something and you start coding right away, you've already failed.
Is Spec-Driven development a novel idea?
If you've spent any time coding with AI, you'll know that it is fraught with circular interactions, dead ends, frustration, and plenty of wonder. The more you do this, the more you start to find ways to avoid pain and correctly leverage the language model to do the right thing for you. When you have a lot of people in the world of software engineering all doing this, you're bound to come to circle around good patterns as they spread around. So this idea of, plan first, break the problem down, then do the work—this is really just a microcosm of good software engineering practices brought to the individual interacting with AI.
Spec-Driven Development is just a sexy label applied to a very structured way of doing that process. Kiro's under-the-hood structured way of prompting AI to produce a spec creates a robust and repeatable way to do this in an AI-driven IDE.
So takeaways about Kiro?
The seeming sales pitch for Kiro (at least as far as I've interpreted it) is spec-driven development. So, to speak to Kiro is really to evaluate the value of that feature. Outside of that feature, it is more or less average compared to the other tools I've used (mostly Copilot and Augment).
Spec-driven development scratched a particular itch I was having back in August. Still new to using GitHub Copilot, I found myself going down frustrating paths with AI, wondering how the slop it produced would ever actually save me time. When I created my first spec and started using it to build a dynamic MDX blog with searching, filtering, etc... I loved how structured everything was. The lengthy requirements doc. The smart-sounding design doc with mermaid diagrams. The incremental task list that can be kicked off one by one just by clicking a little button above each task in the markdown file that Kiro annotates it with. So satisfying.
However. I quickly realized that just because you suddenly have a robust specification for a project that AI can complete for you does not mean it is correct.
Spec-driven development isn't "easy"
Building a "correct" product requirements doc is hard. Knowing that you have made the right technical design decisions is hard. Actually building cohesive software incrementally to meet requirements and fulfill designs is hard.
As I said earlier, spec-driven development is just a compression of the software development lifecycle (SDLC). There is a reason the economy has handsomely rewarded the people who are good at it: it's hard to do well.
The point of building with a spec-driven approach is twofold:
- It helps you build better software
- It helps the AI know what to do, how to do it, and the order to work in
If, after interacting with AI throughout the creation of your spec, you do not actually read and verify the story being told by its documents, you will undoubtedly find you will not end up with the thing you wanted. Something will be off. It might build the wrong thing (the requirements weren't right), or worse, it might build the "right" thing in a way that does not perform well... maybe in a way that forces you to spend money on a Vercel Pro plan or risk having your site turned off. Yes, that did happen to me, which is why I just spent much more time creating a new spec to handle a refactor to better align the MDX blog implementation with Next.js performance best practices.
Beyond Kiro
All in all, while I've had varied outcomes building with specs, I really appreciate the structured way to plan, then code, with an agent. The out-of-the-box UX of plan-then-code in Kiro is way better than any other tool I've used. That said, it is clunky for small efforts, and can really be overkill even for mid-size or larger efforts. If you are already operating in a well-oiled team following solid SDLC practices—with a Product Owner working with stakeholders to refine requirements, more senior engineers or architects working on technical designs, and an Agile team with good ticket writing and refining, by the time you, the developer, get to a ticket, no matter how meaty it is, your "spec" is pretty well defined. The value of translating a ticket into a spec is to structure how you tell AI to implement it for you. However, sometimes, just jumping in—that is, vibing—is the best place to start.
Final words
Given the challenges presented by vibe coding, the massive context, work and rework of an unstructured approach to agentic coding can slow you down to a crawl. Whether you're doing spec-driven development, vibe coding, or something in between—producing written assets during planning and development as a means to carry context across conversations or agents is hugely powerful and a pattern worth using,
In spite of the power of spec-driven development and the cute ghost logo, I anticipate that Kiro is going to struggle to get a foothold in an ever-crowded space. The concept of spec-driven development has already spread as an open source tool, SpecKit from GitHub, and I imagine flavors of this approach is going to become a somewhat standard feature in all AI coding tools. Lastly, fact that it is a fork of VSCode like Cursor rather than a more plugin/CLI model like Augment/Auggie is going to limit adoption.
I'm hugely grateful to have had almost 2 months to experiment with this approach, to burn hours of time with Claude to rebuild this blog. That said, I'm not convinced it will be my end-all-be-all tool. It still has a ways to mature, and as a VS Code clone, the marketplace simply isn't 100% available, making it less desirable.