From Prompt to Production: AI Spec Driven Development with Kiro - Six Five On the Road

How is spec-driven development transforming the way developers use AI for rapid prototyping and production-ready applications?

‍

From AWS re:Invent 2025, host Jason Andersen is joined by Amazon Web Services' Al Harris, Principal Engineer and Kiro Tech Lead, and Jessie Vanderveen, Global Head of Product Marketing, Agentic AI, Developer Experience, for a conversation on Kiro, AWS's AI-powered integrated development environment (IDE). They explore how Kiro drives the adoption of spec-driven development, enabling the creation of maintainable, production-quality applications by bridging the gap between rapid prototyping and scalable production.

‍

Key Takeaways Include:

‍

🔹Genesis and Evolution of Kiro: Harris explains the origins of Kiro, the principles of spec-driven development, and how feedback from the public preview phase shaped the approach to generalized availability (GA).

‍

🔹Market Response and Adoption: Jessie Vanderveen shares insights from the launch, highlighting how the community received spec-driven development in contrast to prevalent trends like "vibe coding."

‍

🔹Team Productivity and Metrics: Kiro’s impact on development teams, with observed metrics for accelerated and high-quality code deployment.

‍

🔹Market Positioning and Developer Enablement: AWS’s approach to supporting both AWS and non-AWS developers in navigating the competitive landscape of agentic AI tools.

‍

🔹Future Directions: Key themes and customer-driven areas of focus for spec-driven development in Kiro looking ahead to 2026.

‍

Learn more at Amazon Web Services.

‍

Watch the full video at sixfivemedia.com, and be sure to subscribe to our YouTube channel so you never miss an episode.

‍

Or listen to the audio here:

Disclaimer: Six Five On the Road is for information and entertainment purposes only. Over the course of this webcast, we may talk about companies that are publicly traded, and we may even reference that fact and their equity share price, but please do not take anything that we say as a recommendation about what you should do with your investment dollars. We are not investment advisors, and we ask that you do not treat us as such.

‍

Jason Andersen:

Hi, this is Jason Andersen. I'm a VP and Principal Analyst with Moor Insights and Strategy, and I am here today with Six Five on the Road at AWS reInvent. Today's topic is Kiro, a new IDE built for the age of AI, if you will, and I'm joined by some distinguished guests. I have Al Harris, the Principal Engineer, and I have Jessie Vanderveen, who leads the business side of the Kiro team. Why don't we just kind of dig into the origin story? Because I think Kiro is so interesting, Al, in terms of how you came about it, what you saw going on in the market maybe a year or so ago that made you say, you know what, there's a better way here.

‍

Al Harris:

Well, I mean, when the Kiro team was, when we were started, we had a PR fact like most things at Amazon. And we were basically sitting down and saying, hey, how can you help developers go from natural language to code and code to natural language to improve the development flow?

‍

Jason Andersen:

Okay.

‍

Al Harris:

It's a pretty vague brief. We knew we wanted to do something. We had kicked around the idea of spec a little bit, but we didn't even know at the time what spec could mean. There's so many variations of spec, and I think we've done a few talks in the last few weeks about this is maybe the seventh iteration of what spec-driven dev really means.

‍

Jason Andersen:

So why don't, that's a great breaking point though, is because what really sets Kiro apart is this idea of spec driven development. Right. So why don't we just talk a little bit about that, probe into what it is, why it's important, how it's different, say vibe.

‍

Al Harris:

Yeah, yeah. I mean, so I think what, 11 months ago or so, Andrej Karpathy had his blog post that coined the term vibe coding, to which we said, oh, there's a word for what we're doing. But at the same time, we wanted to bring the rigor that we have from Amazon's 25 or 30 years of software development experience. We want to take that software development lifecycle and bring that to the age of AI. So instead of just chatting with an LLM or something like that, we wanted to say things like text completion matters, things like being able to do inline editing matters, but we want to be agents first, and we want to be structured and somewhat rigorous in the way we approach development. So we landed on spec-driven dev, which is a way to say, I want to have a natural language representation of the work I'm doing, and use that as the control surface for my code base, rather than dealing with code directly.

‍

Jason Andersen:

Cool, cool. So my recollection is that you built something and you tried it out internally before you even brought it over to turn it into a real product.

‍

Al Harris:

Yeah, no, I mean, absolutely. Initially, we just built a VS Code extension because we wanted to see what this thing could feel like. But we had something like three attempts at specs. The goal really was to build a tool where if you're the person using Kiro on your team, you're going to be the best developer on the team. And people are going to go, what's your secret? And so that initially came down to this really tight TDD life cycle where you can write tests faster and better than anybody else in the team, which means you can do other code changes much more quickly and safely. That eventually expanded because we found that the ergonomics of that didn't match what people wanted. But yeah, we initially had built Kiro. We gave it to a bunch of internal developers, testers at, I think, the end of 2024. Got feedback. People said, I like this, I don't like this, yada, yada. We iterated on it, and then we eventually launched a video internally on our internal sort of video distribution system at Amazon saying, this is Kuro, welcome to this thing we built. It's an IDE, test it out, give us your feedback. And that was in Jan, and I think that's when we started to loop in folks like Jesse and co to the product.

‍

Jason Andersen:

OK. So great, great segue to Jesse. So Jesse, you know, we met talking about this. Well, we met before Kiro working together on QDeveloper. And then we started talking in late winter last year about something. And then the idea was, okay, you've tried it internally, we want to bring it out, but we're going to do a preview, right? and kind of build this thing and really listen to the market as to what happens. So when you did the preview launch early this year, what did you learn? What were the big takeaways once people outside of the AWS world started to see it and how they reacted to it, especially the spec part, because it was so different?

‍

Jessie Vanderveen:

Yeah, for sure. And I think the community also played a big role in helping to shape the actual preview. So that was a big part of listening and getting feedback. But in terms of what we learned to share a little bit more of how we got there, we took a totally different approach to launching Kiro than we have in previous DevTools launches. And so part of the discussion that we had when we saw something really special and unique with Kiro, we wanted to think about what does the launch look like? What does a go-to-market strategy look like? And we took a different approach where we looked at, you know, starting from, you know, naming and positioning, looking at launching it off of, you know, the traditional AWS naming convention. So you'll see it's obviously called Kiro, it's not AWS or Amazon Kiro. And that was in a large part because we wanted to reach, we want to be great for developers building on AWS, but also you can use Kiro if you're not building on AWS. So a lot of times with DevTools, if you have that kind of AWS naming, it's like, only for building on AWS. So that was one of the rationales behind that. But we also wanted to build a really developer first brand. And so you'll see if you go to like, we have a separate website, we have separate look and feel, totally different brand style guides, the way we talk, as a brand is very different and it's meant to be very developer first and developer focused. And so when we launched Kira, we took this very different non-nativist approach where we looked at leading first and foremost with developers and really wanting to reach developers in a really authentic and organic way. So we stood up new channels, we looked at, we have our own, you know, community channels for Kiro, social channels, and really leaning into the audience and taking a very community developer-first approach versus some of the traditional AWS channels. We didn't avoid them, but we led first with Kiro and then amplified through some of the AWS channels. So I think from a learning standpoint, that was one of the biggest takeaways, was that it was a successful way of launching for developers and taking a very developer-first approach. And we could see early signals. I mean, the first week we reached over 100,000 developers were trying Kira, which was kind of we weren't expecting that level of demand. It was really exciting to see and it kind of Yeah, we had to implement a waitlist in the first few days, which was I mean it was it was it was great It was like a good a good problem to have I think but it was really exciting to see the momentum and I think that really showed how Kira kind of struck a chord with developers. And so in, I think like Tal's point about vibe coding and spec, I mean, it's not like you have to choose either or you can do, you can start with that. Yeah. And it's like, and it's kind of, kind of really hitting, I think a chord that a lot of developers were seeing was like, you know, vibe coding is great, but sometimes it can only take you so far. And so like bringing that spec approach, um, you kind of have some of those conversations about implementation upfront that sometimes you don't have until later in the development process. And I think like having that structure really, was something that resonated.

‍

Jason Andersen:

So, Jessie, one of the things that stood out with Kira was that you could start with vibe or spec. And there was this kind of notion during the launch, like, where did the developer journey start? Did people turn to you because it was, hey, this is a cool vibe tool? Or was it, hey, this spec thing is kind of interesting. I want to try it out. Like, where do you think people's starting point was?

‍

Jessie Vanderveen:

I think it was a little bit of both, but when we launched, we were really leaning into SPAC and kind of introducing that as a new way of working with AI, with agents. And, you know, I think a lot of developers were kind of intrigued by what Kiro offered in terms of the spectrum and development. But, you know, we weren't looking to alienate people who are using Vibe coding and prefer that way of working. But it's not like an either or decision. You can start with Vibe and you can build with SPAC. But I think initially there was a lot of intrigue and a lot of interest in the spec-driven approach.

‍

Al Harris:

Well, something I would add there is actually I think the vibe spec separation is sort of this false dichotomy we've imposed on users. Initially, these were two entirely unrelated features. And for folks who use sort of our early preview builds of the product, you basically either interacted with an agent or you did spec-driven development. which was kind of a weird separation. And so we still have this sort of two agents in the system, right? There's the one that just does generic general purpose coding or development tasks, and the one that knows really crisply about how spectrum development works. And over time, we want to figure out how we actually merge those and make them a more seamless experience. Because to sort of say you can do one or the other is, I think, a false promise you make to customers.

‍

Jason Andersen:

So full disclosure to everybody, I was actually one of the initial private testers of Kiro. And my instant feedback was about spec, where I went back to the team and I said, you know, I look at this and I immediately think of team productivity. And it's funny because you mentioned individual productivity as a benefit in the last thing you said. I was just curious as to kind of your thoughts on the team aspect of it in terms of being like instead of iterating around the code, you're actually iterating around the spec. Right. Or even like any experiences or even team metrics you might have seen so far in terms of internal, external, anything like that.

‍

Al Harris:

Yeah, I don't have the metrics on hand. What we have done, on the Cura team at least, is once we had sort of an MVP, or what do we say now, an MLP, minimum lovable, spec-driven experience. Once we had this sort of bootstrapped spec-driven experience that we liked, and we said we're really happy with this, we know there's some rough edges to polish off. The team leaned in really heavily on spec is the way we now do development. And so that translates to when we do design reviews as a team, for example, what we'll do is somebody will go off and sort of synthesize the spec. They might even run through sort of a POC and implement it once or twice, because you can just very easily delete the code and rerun your tasks to iterate on this design. But then we sit down as a team and we actually just review those requirements in design. It's sort of breaking this promise we had when we started the project, which was Kiro should be this very inner loop development tool where I'm just sitting here churning internally. But that has made the team, I think, significantly more productive. Because as anybody who's built software or built sufficient software knows, you review a design, you've got your requirements, you review a design, and then something happens and a solution exists at some point in the future. And so the gap between that design and the solution can be significant, depending on how long it takes, how many people you add to the project, what roadblocks you encounter, et cetera. And so what we want to do is make sure that spec is sort of inclusive of all these learnings. So there is this inner loop of, I have an idea about my requirements. You expand the outer loop, which is, now I need to actually write and implement the design and realize that my requirements are not quite, maybe they're unsatisfiable in some way. And then finally, when I go to implement it, I realize, oh, there's this, something about reality doesn't align with any of these things. You almost need to do these full cycles to understand the full thing you're going to review. A good example, and it's sort of a trivial example, is when we added remote MCP support to Kiro. That was something where we just had somebody go off. They read sort of the new OAuth standard. They understood what they needed to do. They generated a spec. We talked about it. We sat down in a room for 30 minutes, reviewed the spec, and provided feedback. That gets fed back into Kiro. We all said we're happy. and then we just churned it out. And so now a lot of features that we had to cure end up taking that sort of life cycle where somebody might iterate a few times internally, but then we will sit down as a team, review the spec, the spec gets committed back to the code base, and we have this manifest of 20, 40 specs of the things we've built. We're still figuring out how to sort of manage the life cycle of those as the list accretes over time. You don't want this constantly growing list, but so those are challenges we're trying to figure out now, which is how do you, what is the full life cycle of a team that is doing spec driven data? And we're excited to figure that out over the next, you know, three, six, 12 months.

‍

Jason Andersen:

Yeah, I mean, it's also interesting when you get into things like, you know, there's new feature development, but then there's also like your maintenance and your bug fix and kind of, you know, your kind of second order types of releases. So that probably also plays into that idea.

‍

Al Harris:

Hugely. And that's, you know, there's a lot of feedback we're getting from customers, both internal and external, asking for those things, right? There is, I want a spec that describes not the feature I'm building, but the invariance of the system I'm operating on. Because I want it to be really crisp and clear if, for example, I add a requirement that is conflicting with an a priori assumption the system has. Let's say the system has some requirement that I'll take native push notifications and the ID is a good example. So we added notifications, I think, before we went to preview where if you're away from your desk grabbing a coffee or whatever and Kiro needs intervention, it can pop up a little badge on your Mac or there's a different API for Linux and Windows. And that was great, right? We sort of had this list of what are the event types you want to be notified on, if the IE is in the background. Simple, not too complex. We had a spec for it. We came in down the road and realized, well, if you're actually working on Kiro and you're getting close to, for example, your credit cap, because you've just been plowing away for a month and let's say it's the 28th and you're about to run out. We want you to have the ability to do that. Well, now do you amend that existing list? Do you change the interface? Do you change the experience customers have? And so we were able to sit down and from sort of a system specification say, we're changing the way notification configuration works. We want to make sure that we're really intentional about this thing that is going to be customer facing. And that's something where using Spectre and Dev, we were able to go back and say, we are changing an assumption we've made about the system, and we're changing a requirement we previously made. That's super critical, right? Because that is something that I need to go chat with the team, sort of in a larger venue. I don't want one dev making that decision. I want to be in the loop. I want maybe my product manager in the loop. And the same applies to refactors, where you're sort of saying, I need to understand the system first, I need to mutate the requirements, and then I need to move ahead. And that's super important. And that really stood out. Yeah, and that's something that internally people are screaming at for. We're fortunate. We have, I think, 20,000 people in our internal user tester pool, and we've got a lot of opinions. But it's great to get that feedback really crisply and clearly.

‍

Jason Andersen:

You mentioned a lot of internal developers, but Jessie, kind of moved outside the market, right? If you think about it, you know, everybody now has an IDE, right? It was not quite that way even two years ago, right? Even companies that didn't necessarily, not necessarily because they're a company building an IDE, are releasing things. It's a very noisy market right now. So, I mean, when you look at that market, what are you thinking in terms of how you set Kiro apart, but also in terms of what else you're seeing out there that may influence next steps or something like that, even at a very high thematic level?

‍

Jessie Vanderveen:

Yeah, I mean, initially, our approach has been community and developer first. So we're focusing a lot on how we can help developers in their daily workflows and showing what's possible. And a lot of that is just leaning into technical content, showing what's differentiating about Kiro. and reaching developer communities, both AWS and non-AWS. I think we were talking earlier about Kira Discord, we have our own community, and they're not mutually exclusive. We just want to make sure that we're really plugged in and we're kind of growing and listening. and reaching beyond some of the traditional AWS channels. So that's one of the bigger, I think, approaches we have right now is just showing up in different communities, getting feedback, and leading with authentic, helpful content and information about Qro. So that's kind of on a very high level, what we're focusing on.

‍

Jason Andersen:

The discord for me is important for all the reasons you said, but the second piece of that is also closing the loop for the developers. So kudos to the team for being so quick to respond. I've seen things get responded to on that site very quickly and knocked down pretty fast. So that's great. If you don't do that, then people won't use it, right? And your engagement drops.

‍

Jessie Vanderveen:

Yeah, and it's across all kinds of developer platforms. We're definitely listening and actively engaged, not just Discord, but some of the others. So it's something that we take very seriously and we want to make sure that we're listening and responding.

‍

Al Harris:

Yeah, we've got a great team of people monitoring there and helping people out. Actually, the coolest thing for me is when people in the community in Discord or in our internal Slack room help each other out. That's like the coolest thing. It's like, oh my gosh, yeah, yes, I didn't need to say anything.

‍

Jason Andersen:

So could you maybe give us a couple thoughts on what's kind of next in your thought process, roadmaps, whatever, whatever you're happy sharing would be great.

‍

Al Harris:

Yeah, yeah. Well, I can talk maybe about specs first and then you can talk about the products. Okay, great. From a spec perspective, one, we want to make the IDE better, obviously squashing bugs, making it more, improving performance, all those little things that are super critical. Those micro interactions matter so much. But from a spec perspective, I think the theme you're going to see coming out of us is reproducibility and reliability. The promise of spec that we are still living up to is, or working to live up to, I should say, is that you can move faster, you can move more safely, and you can move more reliably. And so for us, reliability means when you say that this is a requirement, we help you understand if this is the right requirement, we help you remove ambiguity from your requirements, we help you identify if your requirements are conflicting, and it means that we introduce safety mechanisms like property-based testing. So, you know, coming all the way back from, I think, John Hughes in the 80s with sort of like QuickCheck, we have a large corpus of work of people thinking about how invariant testing and property testing works and how you can actually, I won't say prove, but you can sort of demonstrate correctness of the software system with these things. We launched that just a few weeks ago, but that's really just the tip of the iceberg. I think you're going to see a lot in the next year. around sort of neuro-symbolic AI, neuro-symbolic processing, how do we start to prove that the software you're building is correct? I should probably steer clear of the term prove, but demonstrate sort of correctness to the requirements and help you get the right requirements that you meant, not just what you said. Because ultimately, I mean, right now, the LLM is a part of the tool, but it's not the only tool we want to ship in Kira, right? We have this large suite of sort of automated reasoning people who are much more intelligent than I am and saying very big words. But ultimately we want to make sure we can sort of democratize the really cool stuff they're building that we think will help developers move more safely. That I think is the big one for me.

‍

Jason Andersen:

And how do you see that translating into product releases or anything like that maybe?

‍

Jessie Vanderveen:

Yeah, I mean, we'll see some interesting launches, I think, this week. We're really focusing a lot on things like the next phases of agentic AI and how that impacts workflows in terms of scope and velocity of work that can be performed. So I think that's like a big area that we're leaning into. And also the ecosystem. So thinking about how we're working with our partners and community to build, to help kind of provide best practices and context to agents for a variety of development use cases, which we'll see this week.

‍

Jason Andersen:

Great. So, Jessie, Al, thank you both for your time talking about Kiro. It was a great discussion. And just to wrap up, this is Jason again with Six Five On The Road at AWS re: Invent and hope you have a great day. Thanks.

‍