Developing with Kiro: Amazon's New Agentic IDE

My experiences testing Kiro with TanStack Start + React, Spring Boot + Angular, Open Source Dev Tools, and Internal Dev Tools

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.

But I want to be clear about something: this isn't magic, and for now, there are still times when your coding skills will be required. There are still times that Kiro is unable to solve your bugs for you. At this point you need to solve them yourself or guide Kiro very explicitly regarding the approach to take. You need to develop a sense for when to let it run and when to start interfering or take over control.

The comparison that keeps coming to mind is the evolution from text editors to IDEs. We didn't abandon text editors because they were bad—we moved to IDEs because they let us think at a higher level of abstraction. Kiro feels like it might be the next step in that evolution, though it's still early days and the product does have some rough edges.

Real-World Experiences

Building with TanStack Start + React

With that introduction to Kiro out of the way, let me walk you through my actual experiences using it across different technology stacks. My first real test of Kiro for web development was building a portfolio website from scratch using TanStack Start and React. I wanted to see if it could handle a complete project end-to-end with new tooling that is probably not in its training data. I've wanted a portfolio website for a while but haven't built it because it means frontend development, and I don't love frontend work. At least I didn't until now.

The process started with me describing what I wanted: a clean, professional portfolio site with project showcases, a blog section, and contact information. I mentioned I wanted to use TanStack Start for the framework and shadcn for the component library, but beyond that, I was pretty vague about the implementation details.

I was quite impressed by what happened next. Kiro didn't just start writing code—it created a requirements document, a design document, and a detailed task list. This spec-driven approach meant I could review and refine what we were building before any code was written. I made a few tweaks to the requirements (added some specific sections I wanted, adjusted the visual direction), and then Kiro got to work.

The execution was largely autonomous. I had to set up a couple of MCP servers first—one for DuckDuckGo to help it search for documentation when it got stuck, and another for GitHub access. But once that was configured, Kiro handled the heavy lifting. It scaffolded the project structure, implemented the routing, created the components, and even handled the CSS styling.

What was particularly clever was how it handled content generation. Rather than me having to write all the portfolio content myself, I simply pointed Kiro to use the MCP server integrations to scrape the data it needed about me from a couple of links. It pulled information about my projects, background, and experience automatically, then structured it appropriately for the site.

Here's where it got interesting: I know very little about modern CSS, especially the kind of complex layouts and animations you see in professional websites. But Kiro managed to create something that looked genuinely polished. When I pointed out rendering issues or asked for visual tweaks, it understood what I meant and made the corrections without me having to explain the technical implementation.

The whole process took about four hours, and I wrote exactly zero lines of code. More importantly, when I wanted to make changes later—adding new sections, tweaking the design, or fixing bugs—I could describe what I wanted in plain English, and Kiro would implement it correctly.

That said, it wasn't completely hands-off. I had to interrupt the process a few times when Kiro started going down the wrong path or when it needed clarification about specific requirements. The key was learning to be specific about what I wanted upfront and not being afraid to course-correct when needed.

Spring Boot + Angular

While the portfolio website showed Kiro's strength in building from scratch, my experience with Spring Boot + Angular projects has been more limited so far, but it's shown me another side of the tool's capabilities—particularly around project onboarding and generating insights about existing codebases.

When I pointed Kiro at a complex Spring Boot + Angular project I needed to contribute to, it didn't just read through the code. It generated comprehensive steering documentation that broke down the project's architecture, identified key patterns and conventions, and even highlighted potential areas for improvement. This kind of project analysis would normally take me hours of manual exploration, but Kiro delivered it in minutes.

The onboarding assistance was genuinely helpful. Instead of spending time trying to understand how different modules connected or what the data flow looked like, I could ask Kiro specific questions about the codebase and get detailed, contextual answers. It understood not just what the code did, but why certain architectural decisions were made and how they fit into the broader system design.

However, this is also where I encountered some of Kiro's limitations. When development environment issues arose—things like dependency conflicts, configuration problems, or credential setup, Kiro would sometimes get stuck in loops. It would try the same approaches repeatedly rather than stepping back to diagnose the root cause. In these situations, I found I could use Kiro's insights to understand the problem myself and then either fix it manually or guide Kiro very explicitly through the solution.

What's interesting is that even when Kiro couldn't solve environment issues directly, its analysis of the codebase was still valuable enough that I could resolve problems independently using the context it provided. It's like having a very knowledgeable colleague who can explain the system architecture but might need help with the practical setup details.

I'm planning to do more extensive testing with Spring Boot projects specifically, but so far the pattern seems to be that Kiro excels at understanding and explaining complex systems, even when it struggles with the operational aspects of getting them running.

Open Source Development: Contributing to alchemy

One of my most challenging tests of Kiro was contributing to alchemy, an open source Infrastructure-as-Code library that lets you manage cloud resources using pure TypeScript. Unlike tools like Terraform or Pulumi, Alchemy runs entirely in JavaScript runtimes with zero dependencies, making infrastructure management feel more like regular application development. I am a huge fan of its approach, and while it's still early days for the project, it has picked up really good traction.

The pull request I ended up submitting (https://github.com/sam-goodwin/alchemy/pull/657) was a substantial 8000 lines of code, and Kiro generated roughly 80% of that. But getting there required a completely different approach than the portfolio website project. This is where I really learned about the importance of spec-driven development with Kiro.

My initial spec for the changes I wanted to make was not detailed or clear enough for Kiro be effective. It wasn't a great experience. Kiro wouldn't follow the project's contribution guidelines, struggled with the async nature of resource management, and kept implementing solutions that didn't fit Alchemy's patterns. I spent hours going in circles, with Kiro repeatedly making the same mistakes. It would run into issues and create new files to debug the issues because it couldn't root cause the actual issues independently. It would then fail to debug those new files, and we were going around in circles.

The breakthrough came when I stepped back and created a much more detailed specification document. I had to create a new spec with much more specificity to get Kiro to perform well. Instead of trying to explain everything in chat, I had Kiro write out clear requirements, acceptance criteria, and implementation tasks. I iterated through those tasks with Kiro spending time fleshing them out to leave no room for ambiguity. I even included details about how to implemet the tasks. The result was a spec of discrete, manageable pieces that Kiro could tackle one at a time.

This spec-driven approach was a game-changer. Suddenly, Kiro could work across multiple sessions without losing context. When our conversation would expire (which happens frequently with complex projects), I could start a new session, point Kiro to the spec, and it would pick up exactly where we left off. The specification became our shared source of truth. When I changed my mind about anything, it went straight into the spec, which it turns out is the secret to getting Kiro to listen to you.

The whole process took about a week of aggressive prompting and iteration, but the end result was a high quality pull request adding substantial functionality to a really awesome project. More importantly, I learned that Kiro's real strength isn't in quick, one-off tasks—it's in sustained development work where you can invest time upfront in creating clear specifications and then let it execute consistently over multiple sessions.

Internal Dev Tool

My experience using Kiro for internal development tools has been surprisingly rewarding, particularly when building command-line interfaces and developer experience utilities. This is where Kiro really shines in understanding niche use cases and collaborating meaningfully on user experience refinement.

I've used Kiro to build several internal CLI tools that would have been labor-intensive to create manually. What impressed me most was how it understood not just the technical requirements, but the developer experience considerations that make command-line tools actually pleasant to use. It would suggest helpful error messages, implement sensible defaults, and even add progress indicators without me having to explicitly request them.

The collaboration feels genuinely like pair programming with someone who understands exactly what you're trying to achieve. When I described a workflow problem our team was facing, Kiro didn't just implement a solution—it asked clarifying questions about edge cases, but helped me evaluate user experience decisions, and helped refine the tool until it felt really intuitive to use.

The development speed for these internal tools has been remarkable. Kiro's understanding of the business domain has led to me being able to build experiences for my developers that I simply would not have had the time to build from scratch.

Getting the Most Out of Kiro: Practical Tips and Best Practices

After testing Kiro across different project types, I've developed some strategies that have led to a really good development workflow. These are hard-learned lessons taken from doing real work, with plenty of mistakes along the way.

Embrace Spec-Driven Development

Kiro shines when you invest time upfront in creating detailed specifications that are detailed enough for autonomous execution.

Start by having Kiro help write the spec itself. Describe what you want to build, then ask Kiro to create requirements documents, design documents, and implementation task lists. The key: iterate until they're specific enough that there's no room for ambiguity. What feels like over-specification to me is often exactly the right level of detail for Kiro.

When you change your mind about anything, update the spec immediately. This becomes your shared source of truth across multiple sessions—it's the secret to getting Kiro to listen to you consistently.

Master Project Management for AI Development

Working with Kiro requires different project management than traditional development. You're steering an AI that can get overwhelmed by complexity and sometimes prefers workarounds over root cause analysis.

Key rules:

1. Explicitly tell Kiro not to move on until issues are truly fixed

2. Insist on root cause analysis rather than accepting quick fixes

3. Keep specs and task lists updated as living documents

4. Pause periodically to ask Kiro to align the spec with project state

5. Let Kiro do project management and suggest plan improvements

Generate Steering Documentation Early

One of Kiro's features is its ability to generate steering documentation for existing projects. This is not something you have to do, but it’s something that you always should do. As soon as you start working on any project—especially one that's poorly documented—ask Kiro to analyze the codebase and create steering documentation.

This documentation captures the product vision, technical architecture, and development patterns in human-readable form. It's not just useful for you; it becomes a resource that Kiro uses to understand project conventions and maintain consistency throughout development. I've found this saves hours of onboarding time for me and helps Kiro make better decisions from the start.

Leverage MCP Server Integration

One of Kiro's most powerful features is its ability to integrate with external tools and data sources through MCP servers. Add MCP servers when you need to interact with data or tools that the language model doesn't know how to access directly.

For development work, I've found the DuckDuckGo MCP server essential for documentation searches when working with newer frameworks. The GitHub MCP server is invaluable for understanding project context and contribution guidelines. If you're working with project management tools like Jira or need to access specific APIs, setting up the appropriate MCP servers can dramatically expand Kiro's capabilities.

The setup is usually straightforward, and the productivity gains are immediate. Don't hesitate to configure these integrations early in your project—they're not optional extras, they're essential tools for complex development work.

Use Agent Hooks for Automation

Kiro's agent hooks feature lets you automate repetitive development tasks by triggering agent executions based on specific events. For example, you can set up hooks to automatically update and run tests when you save code files, ensure translation strings are updated across languages when you modify them, or run code quality checks when you commit changes.

I've found agent hooks particularly valuable for maintaining code quality and consistency across team projects. Instead of remembering to run various checks and updates manually, you can configure Kiro to handle these tasks automatically, ensuring nothing falls through the cracks.

Recognize When to Step In

Learning when to let Kiro run versus when to take control is crucial. Kiro excels at sustained development work where you can set clear specifications and let it execute over multiple sessions. It's particularly strong at understanding business domain requirements and translating them into working code.

However, there are times when traditional development approaches are still faster. If you're doing quick debugging, making small tweaks to existing code, or working on problems where you already know the exact solution, it might be quicker to just write the code yourself.

The key is developing a sense for when Kiro is struggling. If you find yourself going in circles, step back and either provide more specific guidance or handle the problem manually. Don't let perfect be the enemy of good—sometimes the most productive approach is a hybrid where Kiro handles the bulk of the implementation and you step in for specific challenges.

Common Pitfalls and How to Avoid Them

The biggest mistake I made initially was treating Kiro like Cursor. It's not—it's a fundamentally different approach that requires different strategies.

Don't expect Kiro to work well with vague requirements. The more specific you can be about what you want, the better the results. This includes being specific about coding patterns, architectural decisions, and even implementation approaches.

You will need to change the way that you have been developing and adjust to Kiro's learning curve. You need to develop a feel for how to work with specs effectively.

Finally, remember that Kiro is still early. There is still occasional unexpected behavior and bugginess, and times when it simply can't solve problems that seem straightforward. The key is maintaining realistic expectations while taking advantage of its genuine strengths in sustained, specification-driven development work.

The Head Fake: This blog post was written with Kiro

Before we talk about the future, I want to share something that perfectly illustrates the spec-driven development approach we've been discussing throughout this post: I used Kiro to write this very blog post.

In preparing my reflections about my experiences with Kiro, I didn't just start typing. Instead, I worked with Kiro to create a comprehensive specification that included requirements documents, design documents, and detailed implementation tasks.

Kiro created the requirements that captured what the blog post needed to accomplish—introducing Kiro to developers, sharing authentic experiences across different technology stacks, and providing practical tips. Then I iterated with Kiro to develop a design document that outlined the narrative structure, writing style, and content approach based on analysis of my existing blog posts.

Most importantly, Kiro broke down the blog writing into discrete, manageable tasks. Each section had clear objectives, specific requirements to address, and detailed guidance about what to include. This plan served as a detailed enough spec that Kiro could use to execute each section autonomously while maintaining consistency with the overall vision.

You're reading the result. This long (hopefully substantial) blog post was written collaboratively, with Kiro handling the bulk of the content generation while I focused on steering the direction, providing authentic details from my experiences, and refining the voice and tone.

This meta-example demonstrates my shift from writing to steering. Instead of spending hours crafting each paragraph, I spent time articulating what I wanted to communicate, and then let Kiro handle the translation from intent to polished prose. The specification became our shared source of truth, enabling us to work together effectively across multiple sessions.

All I needed to do was sprinkle in my authentic voice by adding sentences like this one!

The Future of Development, Productivity, and Creativity

Looking ahead, I think we're witnessing the early stages of a fundamental shift in how software gets built. The evolution from writing code to steering development isn't just a productivity improvement—it represents a qualitative change in the role of software engineers.

As context windows grow and models become more capable, I expect software engineering will gradually become more about conversations regarding requirements and user experience. The technical implementation details that consume so much of our mental energy today will increasingly be handled by AI systems that understand not just syntax, but software architecture, user experience principles, and business domain requirements.

This doesn't mean engineers become obsolete—quite the opposite. As the AI handles more of the mechanical aspects of coding, engineers can focus on the parts of software development that require human judgment: understanding user needs, making architectural trade-offs, ensuring quality and maintainability, and solving complex business problems.

We're still a long way from language models that can one-shot optimal design and solutions for complex systems. There's still significant value in understanding good software architecture, appropriate technology choices, and effective development practices. But the day-to-day work is already shifting from writing code to steering AI systems and ensuring they produce quality results.

Kiro feels like an early glimpse of this future. It's not perfect: it still stumbles and has limitations and requires a learning curve. But it offers a preview of what development might look like when AI systems can truly understand and execute complex, multi-step projects.

The key insight I've gained from my testing is that success with tools like Kiro isn't about becoming a better prompter, it's about becoming better at articulating what you actually want to build. The clearer you can be about requirements, user experience, and architectural decisions, the more effectively these tools can translate your vision into working software.

Whether Kiro specifically becomes the dominant platform in this space remains to be seen. The agentic IDE landscape is evolving rapidly, and there's plenty of room for innovation and improvement. But the fundamental shift it represents toward vibe-coding for complex and significant systems is real.

I don't think the spec-driven development paradigm will remain restricted to building software. This blog post already proves how it can help with writing. Over the next few years, I expect that engineers will build tools for many different industries enabling spec-driven creativity, and spec-driven workflow execution.

For developers considering whether to invest time learning Kiro, my recommendation is straightforward: if you work on complex, multi-step projects where you can benefit from sustained AI assistance over multiple sessions, it's worth the investment. You can visit Kiro's website to get started!