One of the coolest things about being part of AWS's Community Builders program is that we occasionally get early access to new products. As such with today's public preview that is available over at kiro.dev, I am excited that you guys will be able to have an opportunity to try out this new development experience. Like other agentic IDEs that I've worked with, Kiro still feels early, but in my extensive testing there is no question to my mind that it has already multiplied my productivity by leaps and bounds. I'd like to introduce you to this new development tool, helping you understand how it is different from other VS Code forks and agentic IDEs, describing my experiences developing on Kiro, and share some tips regarding how to get the most out of the IDE.
I'll be upfront about my experience: Kiro has genuinely changed how I approach development work, but we haven't yet arrived at the AGI magic bullet rendering software engineers obsolete. What I found interesting is how it forced me to think differently about the development process itself. Instead of jumping straight into code, I found myself spending more time articulating what I actually wanted to build and high level software architectural choices.
During my testing, I built a complete TanStack Start portfolio website from scratch in a few hours without writing a single line of code. I contributed substantial pull requests to open source projects like Alchemy.run, with Kiro generating roughly 80% of the implementation. I used it to help onboard to complex Spring Boot + Angular projects and develop internal command-line tools. But each of these experiences also taught me about Kiro's limitations—when it gets stuck in loops, when it needs more guidance, and when traditional development approaches are still faster.
The reality is that Kiro requires a different kind of project management. You're not just writing code anymore; you're steering an AI that can get overwhelmed by complexity, sometimes prefers workarounds over root cause analysis, and occasionally needs to be told explicitly not to move on until issues are actually fixed. It's powerful, but it's not hands-off.
In this review, I'll walk you through my real-world experiences using Kiro across multiple technology stacks and project types. I'll share what worked, what didn't, and the strategies I developed for getting the most out of it. Whether you're considering adopting Kiro or just curious about where development tooling is heading, I want to give you an honest look at both the promise and the reality of working with Amazon's entry into the agentic IDE space.
Is Kiro Really Different?
I've been using various AI-powered development tools since GitHub Copilot was released a couple of years ago. Each tool has carved out its own niche in the development workflow: Copilot excels at enhancing your typing speed with intelligent code completion, Cursor at debugging and helping you implement discrete tasks well, and recently pushing more into agentic territory.
In fact, many developers are already trying to use Cursor for complex, multi-step workflows by having it update and refer to requirements files, essentially trying to create their own spec-driven development process. The problem is that these tools weren't really designed for that kind of autonomous execution. They're great at the task you're currently working on, but they tend to drift when you need them to follow a complex plan over multiple sessions.
Kiro feels different because it was built from the ground up to handle this kind of work. Instead of trying to hack together a spec-driven workflow, Kiro already knows how to help you build and adhere to a specification and develop without deviating too far from the plan. You can tell it how to implement something, create complex plans, and then let it run largely by itself, filling in the implementation details.
The shift is subtle but significant. With Cursor, I'm constantly course-correcting and re-explaining context. With Kiro, I spend more time upfront articulating what I want to build, but then I can step back and let it execute. It's the difference between being a hands-on manager who needs to check every detail versus setting clear expectations and trusting the process.
... continue reading