AWS re:Invent 2025 - Kiro: Your agentic IDE for spec-driven development (DVT209)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Kiro: Your agentic IDE for spec-driven development (DVT209)

In this video, Rory Richardson from AWS and Vidheer from Delta Airlines discuss the evolution of agentic AI and Amazon Q Developer's Kiro IDE. They explore the shift from traditional coding assistants to agentic IDEs, emphasizing spec-driven development over pure vibe coding. Delta shares their journey achieving 1,948% growth in Q Developer adoption within six months by building trust through dev champions. Vidheer demonstrates how Kiro's spec-driven approach transformed backlog grooming into efficient design sessions, enabling business product owners without coding experience to generate production-ready prototypes. Sam showcases Kiro's features including steering files, MCP integration, Kiro Powers, and agent hooks. Delta reports 94% satisfaction scores and successfully delivered their first intelligent developer portal using Kiro, with developers now focusing on architecture rather than implementation details.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: The Evolution of Agentic AI and Autonomous Agents

Alright, 21, woo! All right, we can finally start. But even though you guys have been here for 15 minutes, it feels like already. So you must be really excited about this session, but if you've already been using Kiro, I don't know how much of this is necessarily going to be net new information because, well, if you're a practitioner and you're playing with it daily, you're going to get a lot of information already. Also, I bought these shoes today, and if I fall, I want my CSAT scores to be super high, OK? I need the sympathy vote. Whoa.

All right, so my name is Rory Richardson. I am joined by Vidheer from Delta Airlines and Sam, who's a solution architect focused on Kiro. And what we're going to do is we're going to talk a little bit about the preface of where, how we got here in the evolution of agentic AI. Then we're going to talk about the importance of spec-driven development in relationship to vibe coding. We're going to do a quick introduction to Kiro and then we're going to get some real world tactical experience by talking about how Delta Airlines has been incorporating Kiro into their software development life cycle and eventually their AI development life cycle. And then lastly, we're going to wrap up with a demo.

The demo is coming in pretty hot. As you know, we've made a lot of announcements yesterday morning in Garman's keynote. Did y'all see Garman's keynote? Raise your hand. Yeah. Was it good? Yeah, one of my favorite parts is the autonomous agents that we're introducing because it greatly expands the context and the ability of combining multiple agents together in order to do more and more complex tests. It's a very foundational concept that I think is going to continue to grow over the next 6 months, year. I think more and more folks are going to do more and more complex things with the agents themselves and combining them for the autonomous agents to be able to orchestrate, monitor, and even verify the work of other agents to build them together.

The Agentic Mindset: Starting with Toil Removal, Not Core Business Problems

So let's talk a little bit about the agentic mindset because there are a few things that we've learned probably the last 2 years or 18 months. When I would talk with a lot of customers, usually they would come with an idea or a business problem that they wanted to solve, but unfortunately a lot of folks started with really, really hard problems and things that were customer facing and things that were about the core competency of the business. Great, we're going to get AI to do the very thing that we sell to our customers. Uh-huh. The problem is that's taking on the most risk, right? And especially if you haven't done one before, why take on the most amount of risk?

Instead, the companies that we've seen to be the most agentic in nature are starting with the muck. I was talking to this business consultant a year and a half ago from Boston Consulting Group, and he said, Rory, generative AI is fabulous. It can make music. The problem is nobody wants it to. What they want is for it to go do the dishes, so that you can go off and make music. So where we're seeing the most exponential value out of the application of generative AI and agentic AI is removing toil and muck to free humans up to be human.

Now, it means a lot of developers are like, oh my God, you know, AI is coming for my job. How many think AI is coming for your job? Raise your hands. Right, just you. I don't, Gartner said it best when they said that AI is probably not coming for your developers, but a developer using AI is probably coming for a developer that is not using AI. And I think that's kind of a true thing because a lot of agents I kind of view as various ages of children, right? You know, they have really great ideas like, oh, let me tell you, let me help you, let me help you, let me help you, and it's like, no, I don't trust you to touch the dishes. You're too young.

So how we are dealing with the agents depends on the level of sophistication, how much we trust the information that we're getting back from them before we incorporate it into what we're doing, because you're not going to fire AI, but I will fire a developer if they write bad code or malicious code or introduce risk into the application. Yeah, these are all things. The humans are still responsible, y'all. This is super important. But can a developer be augmented? I mean, think about all the muck that you do in your software development life cycle, right? Who loves Jira? Raise your hand. Yeah. Jira.

Being able to search through Jira, automate Jira tickets, and optimize that experiment will give everybody else here a better day because when you're messing with Jira, you're not creating that new application. When you first started being a developer, you wanted to make cool stuff, right? So everything that is not helping you make cool stuff is muck.

From IDE Plugins to Agentic IDEs: The Rise of Atomic Agents

So, quick history lesson. I know you're all on this journey with us. We started off with plugins into the existing IDEs, VS Code and JetBrains IntelliJ, and that seemed like a really great idea. Then we got this idea: wouldn't it be cool if we made agents that go off and do bespoke tasks within the software development life cycle, like slash review or slash doc? This was great, except we were teaching a bunch of people how to work with agents and not teaching the agents to work with the people.

How many of you have a smartphone, like an iPhone or something? Yeah. And do you remember that you were told specifically you had to use that device, how to optimize it, and then you had to take an enablement session to fully use it? Of course not. You just get started and you get to choose whatever device that you want. That's the developer experience, right? So instead of teaching developers or anyone how to interact with technology, we should have the opposite approach, and one of the ways we're able to do that is to have an agentic AI approach to software development.

So now, instead of having just plugins into the IDE, we've seen the rise of agentic IDEs. And this was great. I mean, vibe coding is cool, right? You just get started. How many have had to debug one of your colleagues' vibe coding projects? Yeah, super fun, right? But it's also kind of an anti-pattern. I mean, first of all, the democratization of people being able to create something just through natural language was the dream of low code, no code. It's always been the dream: how can I just prototype this? How do I just get started? It was great. But then how do I work with other developers to do more and more complex things? And that's combining spec-driven development with vibe coding to accelerate how you're getting something from prototype into production.

The other change that we've seen this year is the rise of protocols for agent-to-agent communication. How many of you people are using MCP servers? Right? It wasn't that way last year. I mean, this is a radical change in how we're thinking about the very architecture of agents themselves.

So earlier this year, I was asking, well, what is the definition of an agent? Because if you look on the internet, no one could agree. You get three people together, they would have all different definitions of what an agent was. So we're going to go with my definition because I'm the one with the mic. I started out with: well, it has to be able to perform tasks asynchronously. It has to go off and come back. It has to have some degree of autonomy. It has to have agency, and I mean that in a very Pride and Prejudice sense, right? It has to be able to make some decisions on its own.

But this last idea, this last idea of adding the word atomic, is fairly new and the most controversial. And yeah, they all start with A. I did that. Atomic is meaning that you're able to make more bespoke agents and then combine these bespoke smaller agents in different ways to do more and more complex things. So instead of using a really, really large model that has been trained on a really, really large dataset, what if you could do something that was more bespoke? So instead of being good at everything, what if you could be great at a few things?

The idea of making atomic agents kind of brings me back to my microservices days and the idea that you can combine microservices together to do more and more complex applications and also reuse those agents. This was sort of the foundational concept behind what we're trying to do with autonomous agents: being able to use the right agent for the job but not necessarily having to teach you which agent that is and when to call it. These autonomous agents have the ability to help make those decisions for you now.

The Jarvis Vision: Empowering the Next Generation to Dream and Create

This kind of feels, I love a lot of sci-fi. I'm a huge sci-fi fan. And it feels almost like what we really want is Jarvis, right? Now don't go full Ultron, right? But in Iron Man One, Jarvis was a natural language interface for IoT devices in Tony's house.

By the time you get to Iron Man 3, Tony is able to go to the holodeck and directly into the most humanistic areas of innovation. He's able to just start to vibe code the next Iron Man suit, and then when he's done, he's able to look over at Jarvis and say, "All right, now go off and build the Iron Legion," because Jarvis is handling all the supply chain management of all the resources in the house, managing all the design specs, managing search within the libraries of Tony's work. I mean, can you imagine what the world is going to be like when your kids have access to that level of assistance for anything that they want to make? That's the world that we're living in.

I mean, I have a 15-year-old, and I've been trying to teach this kid to code since he was four. I can't get those 10 years back because what is the role of Python by the time that kid hits the job market? I mean, the syntax is kind of taken care of. I'm not saying computer science is dead by any stretch of the imagination, but the world has dramatically changed for how our children are going to interface with solutions and innovation. And it's not about agents per se. It's about how fast and how hard can they dream, because they're going to be able to create it with the assistance of these tools.

Kiro's Impact: Marrying Vibe Coding with Spec-Driven Development at AWS

So we created an agentic IDE like Kiro that married the idea of vibe coding with traditional spec-driven development. This also changed a lot of the roles within our two-pizza teams at AWS. It's been highly disruptive because now we move much faster when we embed our PMs into those teams because we're able to iterate on the specs much, much faster. So engineering reaches a problem, they're like, "Hey, this isn't going to work." PM takes it and goes, "Yep, let's rewrite the direction of what we're going," and the entire process takes a matter of hours and not weeks.

This level of speed has created other problems because the number of code commits that we're able to do, test wasn't ready for, QA wasn't ready for. There's downstream impacts to the speed that we're able to get things done now. So having an AI IDE has greatly accelerated everything that we touch at AWS because, at Amazon, you can view Amazon as our first, best, worst customer because they know where we sit, and they come and they give us direct feedback, and we have to compete for their developer time as well in order to figure out what are the tools that we should be creating internally. And so that's our own internal test bed in order to refine some of our thinking and what we decided to build.

Also, we found tremendous uptick of the command line interface. The command line interface, we found a lot of people were using it who weren't necessarily having an IDE already installed on their computer. That means this is a different type of user that is using the command line interface to do different tasks, but also these tasks are associated with the software development life cycle. So we incorporated the command line interface also into Kiro, and so now Kiro is also available in the terminal.

This evolution of agentic AI has changed everything about what we're doing, and it continues to accelerate exactly how we're creating software, not only from just a traditional application development but also how we're creating the agents themselves. Now, I got my roots in microservices and breaking up monolithic architectures into microservices. I've been talking with customers lately that aren't doing that anymore because that's so 2022. Now they're thinking about breaking up monoliths into true agentic architecture and bypassing that step. So the foundation of these applications are agentic, and so the process of creating agents has fundamentally changed and accelerated.

You'll hear a lot about the tools that we are developing to enable that, whether it's a framework like Strands SDK or an agentic platform like Agent Core that gives you the building blocks for runtime and memory, but also choosing the right inference for your job. But the thing that I think is the most interesting is data, because now if you're able to create an agent that is directly responsible for your data, the responses that you're going to get are more bespoke to your environment.

The ability to create these agents in combination with the full tool chain is really exciting, and I'm eager to see what's next and what people are going to create. I've been working pretty closely with Delta because Delta has a mindset that is agentic architecture in nature. When they started sharing some of their architecture diagrams, I was super impressed with how they were thinking about those autonomous agents and what they call sub agents. That made me feel really old because in my architecture diagram, there was a load balancer and EC2, whereas theirs is different. They're trying to push the envelope of what's possible in the safest possible way that scales within an enterprise organization.

Delta Airlines' Philosophy: Building Trust Through Developer Experience

So with that, I'd like to invite Vi here to talk about their experience and how they've applied it directly to Delta Air Lines. Come on up. You are not going to catch me, I swear we're not going to trust Paul. I'm going to be fine. I'm going to be Jennifer Lawrence. I'm here to catch you. No, it's going to be fine.

Before I begin, how many of you flew on Delta to reach this amazing conference? That's great. Thank you for your business, genuinely. And for those who use the free Wi-Fi in our flights to finish last minute work or prepare for presentations like me, you are welcome. Delta is the first airline in the US that introduced free Wi-Fi across our flights. We are the pioneers of innovation and technology in the entire airline industry, with 100 years of legacy and history that we've created.

Now, decisions like this are made behind a philosophy which I would like to share with you all. We like to create the best experience possible for our customers and make it the new standard, executing it every day. That is the philosophy that we follow in every domain and every group at Delta, even in developer experience which we lead and serve for our Delta developers. We follow the same philosophy, providing the best tools and technology for our developers so that we can reduce their friction and improve their innovation every day.

Rory shared a great vision on the agentic tech roadmap that AWS is getting into, and it aligns very much with our vision and the roadmap that we are planning as well. How many of you have seen slides like this and started preparing mental mapping of how to adjust your roadmap, which things you need to prioritize and deprioritize? I'll raise both my hands. Because every tech conference that I visited, every executive we reached out to, whenever they shared something, immediately we started mapping how to adjust and which changes we need to make.

But here is what we learned: we can achieve this autonomous agentic architecture by building on trust, the trust from our developer community. With the rollout of Q Developer on the left-hand side, the coding assistant, Q Developer is fully adopted across entire Delta. Almost every developer uses Q Developer and they are giving great feedback, which laid that foundation. In the middle, we have Kiro IDE, the agentic IDE, which we are scaling now across the Delta Enterprise. We are marching towards the autonomous agentic systems which are going to be integrated into our developer workflows.

Scaling Adoption: The Dev Champions Model and Kiro's Entry into Delta

With the help of Q Developer so far, we've been able to capture the major wins that Q Developer provided and also helped us understand what are the areas of improvement and what are the automations that we can build for our developers. To increase this adoption and get to the stage that we want, we created a model. One thing that we didn't try was we didn't try to convince all of our thousands of developers in one session or ready to go, because it's not possible. At the same time, we are not staffed up to reach out and talk to each and every developer. So what we did was with the support of our leadership

we reached out to all of our domain leaders and asked them to nominate some of the champions who are technically and technologically very sound and very trustworthy, and who can influence the developer community without any title and authority, right, with trust. So with the help of these dev champions, we were able to scale this model. We went domain by domain, trained each domain, and also built the train-the-trainer model.

Because these days everyone knows AI, right? When Rory was sharing that the technology is always like technology, how it's going to help for children in the future, that immediately reminded me of a personal experience at my home as well. A few weeks back, I have a seven-year-old daughter, so I asked her just casually two simple math problems, multiplications. I gave her, try these out. So she took, okay, I'll try. Five minutes later she came back and asked, can I use ChatGPT? I'm not making this up. It really happened. I was really shocked. I was really surprised. Where did you hear about ChatGPT? I was expecting maybe you were going to ask me, can I use a calculator to do this? And she was like, what is a calculator?

See, the AI advancements are happening very fast that everyone knows how to use AI, how to adopt them, but the most important thing is inputs to this AI, the inference that we're going to provide to this AI. Because everyone knows, like I said, everything, AI is an amplifier. So the more structured problems, the more context we provide, the more guardrails we introduce, we're going to get the best output that everyone is looking for. At the same time, if we have chaos, it's going to amplify that chaos. So that's why we focused a lot on setting those inputs right, getting our community ready so that we can scale this model.

Now these dev champions, this is not their primary job. They have their day jobs. They need to work in their sprints and scrum models. So when we reached out and formed this community, we clearly said we wanted to clearly set the expectations because we want to approach this outcome-based, right? So we clearly said that this is what we expect from you. We want you to participate in the initial session so that you can know, learn how to train, how to train your teams. We need you to participate in our office hours so that you can help others and also listen to their questions, and we need you to contribute your prompts, any prompts that you worked, and we need you to bring along your entire team, not just developers, your product owners, scrum masters, how to use Q Developer.

They helped us to reach almost every developer in entire Delta IT, which is the best part that any email campaign or marketing campaign could do because nobody reads emails, that's the fact, right? So using the dev champions we were able to establish that community and able to scale this model and increase the Q Developer adoption.

But well, we started seeing that developers are writing code. We started seeing that we're writing more code much faster. But still we're not able to see the result. What is the end result? What is the outcome that is aligning with our business expectations? So this is the pivotal moment, which is the very important part. The feedback that we got from our developers is it is very important to understand that moving from help me write this function to help me build this feature, we need AI that understands the business context, our governance, our compliance rules, our integrations. It needs to understand all of those, then only we can get to the stage of delivering the feature-level output.

That is when Kiro entered into our story. So we partnered with our AWS team. And we are one of the early pilot users of Kiro. We introduced it to our, again, our dev champions community and also some power users of Q Developer.

Developer Feedback: Production-Ready Code and Transforming Backlog Grooming

And we asked them, go ahead and use Kiro and start giving us your feedback because we already built the trust. When we rolled out the Q Developer, we started to gain their trust and they started responding with feedback. Four main themes evolved from their feedback. They clearly said that using Kiro versus any other tool, they were able to see that it can understand our complex code base, our business rules, our existing logic, and extract it and build the context that it is expecting.

At the same time, they clearly said that it was able to break down the given requirement to easily implement a design and executable tasks. And most important thing, we started seeing that with the help of Kiro, we are able to build production ready code. I want to underline that: production ready code. No two enterprises will have the same set of governance and compliance rules to build their products, so it is very important for a tool to understand, establish the context, and adjust and deliver the code that is production ready and readily deployable into the higher environments, which we are able to see using Kiro.

We also heard feedback from our architects and some of the developers that they were able to use Kiro to be a critic in their architecture decisions. Some of them use that as a soundboard to validate whether their design and approach is correct or not. That is the most exciting part. So we started seeing that Kiro is becoming one of the team members who has this beautiful memory of memorizing thousands of lines of code, establishing the context, and at the same time giving you advice and suggestions on which direction you need to go for your next product and next implementation. That is the most exciting part we started seeing and we started realizing with the help of Kiro.

And the spec-driven development is the most unique and innovative feature that we came across in Kiro. It's not that complex. Three simple steps. Step one, lock your requirements. You give your detailed requirements. Step two, Kiro automatically breaks down your requirements and starts building the design, generating the design. And step three, it will also give you the tasks, giving power to the developers. That is the most important part: human in the loop. Ultimately, developers have the power whether they accept the design or they're going to execute those tasks, or they're going to refine or alter any direction that Kiro needs to implement. So we started seeing that level of flexibility and at the same time, context awareness.

And the most important part: the backlog grooming. How many of you are familiar with this? I see a lot of nods. Everyone, right? Backlog grooming, several hours of backlog grooming, a lot of debates about story points, definition of done, acceptance criteria, a lot of feelings get hurt, and so much drama, right? So what we started to see, this is the thing that we never expected when we introduced Kiro to our pilot users. They transformed these backlog grooming days into Kiro spec design days, Kiro spec design sessions. So they use that time to refine the requirements.

They started with Kiro instead of backlog grooming. They started with Kiro with their requirements and gave Kiro the prompt in a way that this is the format we create our features and user stories, and this is our model we would like you to create accordingly. They started seeing those results, and those sessions, because Kiro can remember the context and it can automatically adjust based on your code base, the amount of time even to do the spec refinement is also getting shorter and shorter. And surprisingly, no one complained or petitioned to bring back those backlog grooming sessions. We'll take that win.

Delta's Results: Bridging Business and Technology with Kiro

So with the pilot, right? I'm not talking about scaling Kiro. We didn't scale Kiro. We're getting ready to scale Kiro. With just the pilot users, right, we were able to deliver the first ever most intelligent developer portal, end to end production ready.

Meeting all of our compliance and governance rules. I'm sure many of you are familiar with the typical workflow. Whenever there is a business group with product owners and their technology counterparts, countless handoffs happen and numerous meetings take place. Our business product owners create their mockups, the requirements, detailed Word documents, and God help us, some Excel sheets with all of the requirements. But still, even after all of this back and forth, there will be some gaps whenever the end result and the end product is delivered.

What we wanted to try out was something different. Recently, we trained our business product owners how to use Kiro. These are people who never coded a single line in their life. All they did was Word documents and mockups. So we trained them how to use Kiro. The end result was that they were able to provide or generate working prototypes aligning with the roadmap, aligning with the new features that they wanted. And they were able to easily hand off that working prototype to their technology counterparts, who were easily able within hours to actually integrate with their working application.

Again, I'm not making this up. These business product owners said that the prototype or the design usually takes us a quarter, one increment to get that, and we're able to complete it in a matter of days and weeks. It's not only about the time we are saving, it is also about fixing those gaps. We started to see that the gap between the technology team and the business product teams was disappearing because now everyone started to see and talk everything in the same language. No more assumptions, no more imaginations. Product owners are able to give the working prototypes, and technology counterparts are able to immediately visualize and integrate the actual application. And like I said, production-ready code is getting delivered every time.

I shared with you what we delivered, and at the same time, I would also like to share what our developers were saying. I'm highlighting here three quotes from the feedback that we got from our pilot users. One of the engineering leaders, who said that he forgot his coding practice several years ago, gave it a try using Kiro. He said that now he can give tasks to Kiro and go back to his meetings. In the background, Kiro is able to continue executing those tasks, and once he's done with the meetings, he comes back and refines and reviews the code that it generated.

One of the developers said that spec-driven development stopped her from going in circles with vibe coding. Anyone heard about vibe coding? No? So it is, I think it's the official word of the year for 2025, vibe coding, isn't it? A lot of prompting, iteration, prompting, screaming, a lot of tears. We think that there is progress being made, but our commit history will tell the actual story. Using Kiro with the spec-driven development, what she shared was that it is remembering the context. It is giving her the destination and at the same time, the path to get to that destination. It is not building code out of a vacuum. The code is getting generated based on the context.

One of the senior developers said that breaking down technical design into stories with full repo context is very important. There will be a lot of freedom in greenfield development if you're starting from scratch. Sky is the limit, blue skies, we can make a lot of assumptions, a lot of imaginations, prototyping, all of that. But if we are implementing or doing a brownfield application, if you have code that is written several years back and it is the most important application, it's very challenging to plan any changes. But with the help of Kiro, they are able to create the work that needs to be done aligning with the context of the code.

94% of the pilot participants reported a satisfaction score of 4 or greater out of 5. IDEs are like rifles to the Marines, to the developers. There's so much attached to them. It is not a simple task asking developers to try out a new IDE, but yet all of our pilot participants were very open and flexible because of the trust we built. They used Kiro and started giving great feedback. I also shared that Q Developer success that we achieved, and this is what the trust looks like.

We launched Q Developer at the end of March in the first week of April, and in six months we were able to achieve 1,948% growth. That's not a typo, that's a real percentage. I really wish my stock portfolio gave me these kinds of returns in six months. Because of the trust that we built, the developers are embracing any technology that we are building. Q Developer laid that foundation, and on those foundations, we're getting ready to scale Kiro across the enterprise.

Of course, you need to measure any rollout, any technology enhancements that you're doing. Metrics are always very important. We created our own dashboard which helped us measure what the user adoption looks like, what the engagement looks like, and at the same time, what the Q Developer impact is. This clearly showed us that we're able to produce more code in less time.

Again, what the developers are saying is that they're seeing a fundamental shift in our ways of working. They're no longer bogged down or tied to the implementation details because they were able to give those implementation details to Kiro and let it work. They are primarily focusing on architecture and design thinking. They're also focusing now on getting rid of technical debt, everyone's favorite word. They're taking advantage of Kiro and getting rid of technical debt, and we implemented a lot of use cases within this short span using the pilot group.

The takeaway that I would like to share with you all from this pilot experience and from the adoption of Q Developer with these agentic AI tools, developer tools, is that we are able to say yes more now. I know many people leaders here might have read the book saying no is very important, but these agentic tools are helping us to say yes more. Years' worth of backlog which got deprioritized because of competing priorities, now we are able to say yes and start solving those problems. We're able to bridge the gap between our business counterparts and technology counterparts, and everyone is now able to see the same vision, speak the same language, and see the same outcome.

Now the deliverables are no longer tied to the size of the team. They are no longer proportionate. Smaller teams are starting to deliver the biggest outcomes by leveraging tools like Kiro. What's next for Delta? We're getting ready to scale Kiro across our enterprise, and there are a lot of exciting announcements about Kiro agents that were announced. We're going to integrate all of the Kiro agents into our developer workflows and lifecycle.

With all of this journey, one thing that is our personal observation is that companies in the near future, in a decade or so, are going to win not just with the AI tools, but when these AI tools and people are woven together starting from the build, design, and deployment, from product owners all the way to production. We need to focus on introducing AI across the product development lifecycle, which we also call PDLC because we are Delta and we love our acronyms. Introducing AI tools and automation across the entire product development lifecycle is very important. Q Developer laid that foundation and helped to build the trust among our developer community.

Now we are taking the advantage and rolling out Kiro for our future. Now I'm going to ask Sam to come and show some magic, how Kiro is going to look like in the IDE.

Kiro Demo: Spec-Driven Development, Powers, and Building a Customer Support Agent

Thanks. It was really good to hear a practical experience with the tool here. You're supposed to clap as the bosses are here. So, I'm Sam. I'm going to show you a quick tour of Kiro here with a demo that I put together as a video because there's a lot to show and we'll go pretty quick here, so there'll be some time lapse that I'll include.

So Kiro is a full-featured IDE, so you'll see a lot of the stuff that you're kind of used to seeing in your IDE, but it's purpose-built for AI agent development. As you open it up, you'll see the spec versus vibe kind of options here, which is kind of new, and I'll talk a little bit more about the spec version of this or features. We have some tools included in here to help you manage your context, like being able to load files if you want, grabbing output from your terminal as you're debugging, and pointing to particular URLs if you need that. You can even include images so that if you have UI designs or sequence diagrams or something like that you want to include, you can add those.

And you can select the different agent models you want, including the latest like the Sonnet 4.5. We have Opus, and there's this option for auto mode. The auto mode will let Kiro automatically pick which model it's going to use that's optimal for that. It allows you to save a little bit on the credits as you're doing it that way, so it'll pick maybe a model that might be a little bit cheaper to use for the particular use case that it's going after.

On this panel on the left over here, you'll see all the Kiro tools, and these are the things that are going to really help you with your project and manage the AI agents. Particularly, we'll start with the steering files component here. So steering files are a way to give rules and guidance to the AI. You can have prompts that you share amongst your teams that you might put in there, coding standards, those kinds of things, and it will give Kiro a map of your code base as well. So you can click this button here and Kiro will just automatically examine your project if you have a project that you've already built and kind of creates these three foundational steering files for it. One that's just a product file that describes what the product is supposed to do, the features and functions. It'll create a tech file that outlines what all the tech stack that you're using, and a structure file. So the structure gives it kind of a map of where files are, what kind of data you have, anything that the agent might need to know so it doesn't have to load the whole entire code base all the time. It'll use this to navigate through your environment.

It also has a feature with a file match pattern that you can give it, so this particular steering file I have here is for my UX guidelines, and I'm telling it to only load this when it's working on HTML or CSS files. And that way this doesn't get into my context all the time because too much context can confuse the AI agent here. These are just markdown files so you can source them with your project and you can share them.

Of course, with Kiro we can manage MCP, but if you go to Kiro.dev, you'll find that we have a directory of MCPs that we recommend that are easy to just with a click get them added to your project. And we'll take that a step further with something that I think today is probably the first time we've ever really talked about this yet, which is powers. So Kiro powers is a little bit like MCP on steroids if you will. You get a little bit more than just an MCP when you're trying to, like you have an MCP file, you have several of them, you're not sure when you need them, when you don't need them, you'll maybe want to augment that with some rules and steering files. But with powers it combines those all into basically one. So you'll get, and we have some recommended ones here as well, but you can create your own. You'll see a bigger list in the actual released version that will come out. I think it actually was available this morning.

For this particular project, I'm going to build something that I'm going to use Strands for. So I can just go to the directory, include the Strands power, and now I've enabled Kiro with the information it needs in order to help me build this Strands-driven power. So I'm going to build a project here. I'm going to show you, this is Kirosan. This is my fake retail site that I built for my demo, and I want to add a customer support agent to this using Bedrock and Strands.

So I'll just jump into Kiro here. I'll give it a prompt. In the past, I might have to be very, very careful about the prompt that I'm giving my AI agent, but here I'm going to do fairly simple because I'll get a chance to refine this and work through this. And I wish my play dude would disappear, but okay.

So Kiro will go off, examine this prompt and create a requirements document for me. This is an MD file. I'll be able to share this with my team, so a chance to review this with stakeholders, go back and forth a little bit and iterate on the requirements for this. And then if I need to make some updates to it, I can do that. So I'm reviewing these requirements and just kind of for the sake of demo I'm noticing something missing. I want to make the window movable and resizable. So I could do this with just adding the text in there, but in this case I'm going to ask Kiro to add this to the requirements so that I can then go ahead and when it builds it, the window will be movable and resizable.

And when I'm happy with those requirements, I can just click this button here and we're going to move on to the design phase. So Kiro's going to analyze what it saw there. It's kind of figuring out that I wanted to do something with Strands, and so it's going to do a little research in the background, and here it activated the Kiro power. And the cool thing about these powers is if you're using an MCP server, it might get loaded all the time, but here this is on when it's needed. It will load this power because it knows from what it's working on, the context, that it's going to do something with Strands.

It'll deliver this requirement design document for me. I'll get some diagrams. I'll get pseudo code in here, and then it does this other neat thing that's these correctness properties. So this is a set of properties that it derived from the requirements to kind of validate and tie everything together to help us get back to make sure that the requirements that we're building match what we asked it to. So it's another way for it to do some testing and reasoning to make sure that it's getting things right, and it's also really useful for you when you're reviewing the design to make sure that it covered everything.

And I noticed that when I was covering this that I would like a little bit more robust, it talked about input validation, but I wanted some more robust validation to make sure that there was no toxic content getting into my agent. So I went ahead and asked Kiro to add that. And then once I'm comfortable with the design, we move to the next phase, which is creating the tasks for the project.

And it gave me this option for if I want those tasks to be all included or do I want just some of them to be optional or not. And if I, I chose optional for making the demo a little quicker. But you can see these things that are gray are optional tasks and I will get in, I can turn them on if I want to. I can review this and decide, okay, some of these I want and some of them I don't.

For the demo that I'm going to do here too, I also have all these tasks and I want to make sure that they get synced up in Jira. I know not everybody loved Jira, but it's a good way to illustrate what we're doing. It's a good way to illustrate the work that we're going through here. So and also the power of the MCP, which I think a lot of you are already familiar with, but within the IDE here I can add this Jira MCP server, and we have OAuth authentication, so it logs into my credentials and now I'm wired up to my Jira account. And I can go in here and just ask Kiro to take all the stories and tasks that it created in those files and create stories and tasks for me in Jira.

The system created stories and tasks for me in Jira. This is a spot where I definitely needed to speed up the video because it took a little bit, but we can go through and see that it created eight user stories and nineteen subtasks for me, all in Jira. Now I can track these, and I can distribute this throughout my team if I wanted to. This is a pretty small example for this demo, but if you had a bigger project and you maybe wanted to parallelize some of this work throughout your team, you can, because here you can see everything in Jira with the descriptions and the details and all that of what the project was doing.

I might want to sync this up a little bit with the work that I'm doing locally. Kiro has agent hooks, and so the agent hooks are a way for Kiro to respond to events that happen in your environment and then call the agent and take some action on your behalf. So what I've done for the demo here is I'm going to set up a hook that will, if anything changes in my task file, check that and then do the right thing to update my Jira for me. I can describe this in natural language, so I don't have a whole bunch of configuration that I have to do. It figured out that it needs to monitor the tasks.md file. It kind of broke down to make sure that I'm clear, and I can iterate back and forth with it about what I want. I want it to, like, if I mark a task done, check to see if that's the last task in the story and if I can mark the story done. It kind of updated and kept track of that for me in my task file.

Now that I'm ready to get working, these markdown files are embedded in Kiro in a way that I can just click on that little button there that says start the task. It gives me a little indicator that tells me the progress of the task, and I can watch it in the chat dialogue and see what it's doing. If it needs permissions for something, it might ask me. You probably noticed it was a little red there. I found that it kind of ran into an error, but it figured it out and moved on, and kind of built that first task and gave me a summary of what it did.

Now, as I mentioned, there's nineteen tasks in here, and I don't want to handhold them all. I want to go get coffee, so I just told it to go ahead and power through the rest of them. And I did. I went and got a coffee and came back about fifteen to twenty minutes later, and here we go. We've got all our tasks completed with a summary and a wrap up of them. It went to Jira and it updated the status of those, and just for fun, I'm like, let me check the burndown chart. There isn't granularity in Jira that can show you what actually happened because I got all those tasks done in less than an hour, and that's the smallest granularity in their burndown chart.

But I can go in and just like look at my terminal here and kind of show you that we can see the code here. It added, initializing the Bedrock agent, added the agent for us. It added two thousand six hundred forty-five lines of code and over eighteen hundred lines of just documentation. So it also updated all my docs for me. And here's my app, and I got a new button on my app. I can ask it questions about my catalog, so it knows about the API for my catalog and is able to have searched that and found what I had.

But it's not perfect. The font is not in a color that I can really read here. It did a fairly decent job picking up my styles, but I don't think we had anything in there for this particular issue. But let's just go back into Kiro and see what we can do to fix it. This is where we can just vibe code this one here. We can click the vibe code button and I'll describe the problem that I ran into. Also the output from the LLM there at the end, that big block was just a big block of text, but it's markdown. So I'm asking it, can you please format the markdown so that we can get bullets and headers and all that kind of stuff.

So it runs off and does that for me. We can just refresh the app here real quick and see what it did. I don't even have to really reload it, and there we go, now I can read it. I got bullets and headers, and it looks pretty good. But you probably noticed I was talking over it. It was very slow. That was not right, but that gives me a chance to show you the CLI. The CLI is, you know, just in the terminal. There's a ton of tools in it.

It's a little bit more hands-on manual kind of environment if you want to be a little bit more interactive and involved. You know, different tools for different folks. I like driving a stick shift, so for me this is really the world I like to be in. I really like, I use this daily for pretty much everything I do.

You can see the list of features and a lot of experimental stuff that's coming out. If you're using this, you should be checking the release notes pretty much every other day or so. They're using Kiro to build Kiro, so it's just fast. My job is to describe Kiro to you and I'm learning things from people because it's just so fast that it's coming out.

One of the features is this ability to do agents and you can kind of bundle MCP files and steering files and stuff like that, and you can switch those back and forth depending on what you're working on. So maybe you can say like you can bounce back and forth. We're doing some kind of agent core related stuff here, so I'm using my agent core, and I told it what I was experiencing. And it noticed that I didn't, we didn't use the streaming interface that were blocking on the calls from Bedrock. So it went ahead and is making the update. It's asking me if I want them, showing me the coding changes that it's about to do, and I just went ahead and approved them for the sake of this.

And then we'll come back in here and I'm going to ask it a question again about my catalog if it can go out there, and you can see this time it was a whole lot faster. So that's a lot of stuff. I went through a lot really quick and I could really could talk about this all day. There's a lot of really cool features within Kiro that you'll see if you play with it and experiment with it. Just neat little stuff like being able to automatically generate your comments for a commit. You click the button here, it knows what the context is, what the chat has been, and can create that message for you.

We've recently added checkpointing as well so that if the agent just did something that you kind of don't like and want to go back, you can revert that checkpoint and take it back. And things, like I said, things are coming out pretty much on a daily basis. So to get a real deep dive into this, there's some other sessions at re:Invent I would recommend. Just go find those, come see us at the kiosk. But more importantly, download it, play with it, let me know what you think, and I'm going to give this back to Rory here. She's going to close it out with some more information on how you can learn more about Kiro and get started.

Closing: Getting Started with Kiro and the Future of Development

Thanks. How do I switch it back to presenter mode? This one? Oh, nice. All right, so getting started with Kiro is pretty darn easy as far as, you know, downloading it. There was an Easter egg in that demo that I don't know if you're paying attention, but it was Kiro Powers. Kiro Powers is available today. It was an embargoed session, so if you want to learn more about Kiro Powers, I would recommend going to Nakil's session DVT 228 tomorrow to learn more how to get, what did you call it? MCP servers on steroids, yeah, yeah. Well, I don't think that's our official marketing line, but it is a way that we can accelerate the sort of connective tissue, especially with other AWS services like Agent Core.

So thank you very much for attending this session. We would love to hear more about what you like, what you don't like, because, like I said, our development cycle has been greatly disrupted. Take Kiro Powers. I don't think we had anything planned for Kiro Powers a month ago, and we went from inception all the way into production to launching it at re:Invent in under four weeks, and that's actually pretty slow for us now. So these technologies are massively disruptive not only to our own internal processes, but I hope they get to disrupt your processes as well and give you the opportunity to do more faster and put more human in your projects. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.