AWS re:Invent 2025 - Reinventing software development with AI agents (INV205)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Reinventing software development with AI agents (INV205)

In this video, Deepak Singh introduces Kiro, AWS's AI-powered development tool that transforms software development through spec-driven development and autonomous agents. The session demonstrates how developers achieve 5-10x productivity gains by fundamentally changing their workflow rather than just using AI as a tool. Key features include Kiro CLI for terminal-based development, property-based testing that generates hundreds of test cases automatically, and Kiro Powers that integrate with tools like Datadog, Figma, and Stripe. A remarkable case study shows how an AWS Bedrock team of 6 developers completed an 18-month project in 76 days using Kiro CLI. The video also features Brittany Doncaster from Delta Airlines explaining their journey to 120% adoption by extending Kiro beyond developers to product owners and analysts. Three new frontier agents are introduced: the Kiro autonomous agent for continuous development, a security agent, and a DevOps agent, all capable of working independently for hours without human intervention.

; 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

Developer Testimonials: How Kiro Transformed Their Coding Experience

Before I used Kiro, I was very stuck in the details of syntax and switching between programming languages for different code repositories. I would struggle with basic things like how to declare a variable, but Kiro can do it for me. We now have a way to understand, interact with, and define our code, our business, and our requirements in ways that we never did before. Gone are the days of spending hours debugging, looking for a tiny hidden semicolon. Kiro helps me through the entire process.

I started coding in my early teens, and the first time I wrote a piece of code and was able to successfully run it, it gave me a lot of joy. I feel that Kiro brings back that spark. Going down the ordinary routes of just building code from scratch would have taken us weeks, but with Kiro, we were able to go from zero to hero in the space of three days. It is a partner I have with me throughout the entire process. I ask it questions, I start the development with it, I create specs with it, and I learn while using Kiro.

I've been working on trying to add some new features to this large system. It is helping me from start to finish with ideation, from actually coming up with requirements, tasks, and execution. I can have my idea become reality without the most mundane part of it, which is just the typing of the keystrokes. It gives me a different perspective and enables me to do whatever comes to mind, honestly. I'm Kiro's biggest fan, I'm pretty sure.

The AI Revolution in Software Development: From Autocompletion to Collaborative Agents

Please welcome to the stage Vice President of Developer Agents and Experiences at AWS, Deepak Singh. Good morning, and thank you for joining me today. My name is Deepak, and I run the Developer Agents and Experiences Organization at AWS. As you just saw, and as you've probably heard throughout this conference, it is an incredibly exciting time to be a developer and to be working with artificial intelligence.

Over the last few years, we've witnessed a major transformation in how software is being built. We've gone from simple autocompletion using a coding assistant to sophisticated AI agents that can write complete applications, multi-file applications in one go. They can reason, they can help you plan, they can implement your software, and usually all you need is simple natural language prompts or a diagram or two.

Refactoring projects which used to take days now get done in hours. Debugging sessions can be done in a few minutes, as I just saw in that example. Projects that used to take months can get done in weeks, and features that used to take weeks can now be done over a single weekend. We are quickly shifting to a world where agentic AI not only allows us to write code faster, it's actually a collaborative assistant.

You work with the agent, and it helps you achieve a different kind of flow state. You get to continue working, but now you almost have this second assistant sitting with you, a powerful brain that helps you move so much faster. This is a brain that learns from every line of code it sees. It recognizes patterns and opportunities for improvement, and it gets smarter with every interaction, every commit, and every deployment.

This is what today's agents give us. You could call them superpowers that enable new ways of delivering software. They significantly accelerate innovation. We are seeing this every day, both at Amazon and with our customers, especially in a world where speed and differentiation are absolutely key. This transformation has been quite remarkable, and yet it still feels like it's the early days.

A Personal Journey: From EC2's Launch to Today's Developer Empowerment

As I look back, I'm reminded of August 2006. Show of hands, who remembers what happened in August 2006? That's when EC2 was launched. EC2 came out in August 2006 in beta. I was not at Amazon at the time. I was a bioinformatician at a bioinformatics company, and I already had an S3 account that I had set up a few months earlier when S3 had come out, and I launched my first EC2 instance.

A few days after that, there was an evening where I, on a whim, fired up twenty EC2 instances, which was the limit you got at the time, and ran a protein secondary structure algorithm, a simple single layer feed-forward neural network to predict the secondary structure of a bunch of protein sequences, just because I wanted to. That felt absolutely magical. It made me feel empowered in ways that I had never felt before, and less than two years later, I joined AWS because that experience was so amazing.

This kind of empowerment is what I see builders around me experiencing every day, and it's the kind of empowerment that you get as a software developer once, maybe every fifteen to twenty years.

AWS's Mission: Eliminating Friction Between Vision and Execution

Being a developer is an extraordinary role. You get to build meaningful solutions, push technological boundaries, and leverage cutting-edge cloud technologies to create exceptional software to help customers. But it's also quite challenging. You would love to keep building features for everybody, doing things that spark your innovation, your passion, your fulfillment, but you also often get stuck in tedious, mundane activities. They're not bad, they're important, but you have to do them.

At AWS, our mission is to empower developers by harnessing the power of AI, and what we want to do is eliminate the friction between vision and execution. We want you to create at the speed of thought. We want you to achieve breakthroughs that were once unimaginable, or that you're constantly putting aside because you're busy with other things. The developer landscape is evolving rapidly, and our goal is to help you navigate this transformation.

For a very long time, the only way you could build was by handling most of the work yourself. Some of you remember when you had to write every line of code, debug issues, update documentation, manage your dependencies, and then work through deployments. Today, AI agents help in two ways. They help you spend your time effectively on things that matter. They either offload the tedious tasks—you have a bunch of things that you need to get done, but you're busy with something else, so you can give those to the AI—or you can collaborate with the AI, as I said earlier, and accelerate the things that you really care about. So the things that you want to pay attention to yourself. In the end, you get to focus on what matters to you, ideally bringing innovative ideas to life.

This rise of human-agent collaboration has revealed some super important patterns over the last few years. We started with AI just generating chunks of code, sometimes initially just a line or two at a time, to multiple lines to multiple files. Today you can collaborate with agents and humans, and increasingly agents are collaborating with agents on larger and more complex tasks. So your role is to give the agent the right context, the right set of tools, the right input, and provide that human judgment and guidance that only you can.

Developers need these AI capabilities embedded throughout their workflow from initial planning all the way through testing and deployment. Perhaps the most crucial insight that we've had was that to truly transform software development, it's not just about having access to an agent. You need to think about how AI is going to get embedded from the beginning all the way to the end. So not just with coding, but also how you shape your architectural decisions, how you identify edge cases, how you maintain best practices throughout your flow.

These lessons are inspiring, and we get them from watching teams where we work, watching our customers. They help inspire how we think about the future of what developer tools are. They are shaping our vision for building integrated AI solutions and integrated AI development experiences. This is not a future trend. It's happening right now. Six months ago it felt like the future, but six months in the world of AI and agents is almost like six years. The most successful developers are already embracing it.

The Productivity Gap: Why Some Developers Achieve 10x Gains While Others See Only 20%

I like to say they're jumping into the Olympic pool without a life preserver and saying we're going to figure this out, and they do. We've actually noticed something super interesting as we talked to these developers. Some developers are seeing 10, 15, 20% productivity gains as they start using these tools. Others are achieving 5 times, 10 times more productivity improvements. They're using the same tools. So what's the difference?

The difference is becoming increasingly clear. It isn't just about using an AI tool. It's just a tool. It's how you use the tool, how you're helping yourself move faster. You get there by fundamentally changing how we approach software development. The most successful software developers, and we get to see them in action often, are rethinking their entire process, rethinking how their teams think about the process of software development, and they're using AI agents as collaborators and constantly working with them to achieve these kinds of crazy results that we are seeing. It's a mindset shift, but that's what you need to get that level of improvement.

I talked about EC2. Cloud computing transformed how we think about infrastructure. You no longer had to think about how you rack and stack hardware. Agentic AI is freeing us from this code-first development. It's not a bad thing to think code-first, but it's changing how code is developed. I'm a musician in my free time, a terrible one, but there's this piece of software called Ableton Live. For those of you who've used it,

it has a nonlinear way of developing which takes you away from the standard left to right tape track way of building software music that all the other software used to do. This completely revolutionized software and music and how music is made. AI agents are doing the same thing with software. We are working towards a world very, very rapidly where natural language intent or an image or a diagram or pseudocode, that intent becomes working software. It is a world where tools that we need to build software look quite different.

I like to think that what you need is not a code editor, but a more conversational context management system, something that helps you drive and write down what the agent needs, drive its behavior to get to the place you want to go to. You're almost spending more time supervising, managing, and reviewing the work of AI agents than you are typing on a keyboard with some coding programming language. The other way to think about this is just the early coding assistants were just tools. Agents are not mere tools. You can refactor an entire code base and manage multi-file changes. Your role as a developer is no longer just typing. You're orchestrating these agents, and that's not something that happens right away. You have to learn.

Agents, the craft of software engineering is evolving. Software engineering is a craft you learn by doing it. Yes, there are college courses, school courses that will teach it to you. You'll learn a language, but to become a really good developer, you have to do it for a long period of time. We are seeing a lot of people learn this, relearn this craft, take what they have learned as software developers, as systems thinkers, and apply it to agentic software development. It's a change in the calculus of how software is built.

Rethinking Software Development: From Code-First to Intent-First Paradigm

So think about it, your team size, how the team is structured, your development velocity, how you think about technical debt. All of these things are going to get reshaped over the coming months, I'm not even saying years, and it'll get reshaped because you're going to build software differently. It's going to change because we approach our teams and how they approach building software differently, and it changes how we think about what's possible or if I paraphrase Matt Garman from two days ago, why not. So let me illustrate what this shift means in practice, as I said a few seconds ago.

Software developers are craftspeople. If you want to take it to an extreme, a lot of folks take pride in meticulously writing every line of code, how their code is structured, what it looks like on screen, how they orchestrate these tools and manage every aspect of the development themselves. But there is a challenge that comes with it. Sometimes as you write code, as you're building your software, some of the critical decisions, strategic, architectural, business, often come later down and you have to go back and make some costly changes.

This AI agentic paradigm kind of flips this on its head. As a developer, you can front load a lot of these high value strategic architectural and business decisions and the discussions you may have with your design team or your product team, and then you work with the AI agent to explore what the implications could be. You can work through trade-offs really quickly because you can build prototypes really fast. You can do it even before any code is written, but you can also write a quick application to just get your mental model right, to make sure that you're thinking straight. Part of this is all the execution is being handled by the agent itself.

It is not just that you've taken the level of abstraction higher, because you know in the world of software that's every few years you try and come up with a new layer of abstraction. It's about enabling developers to think through the entire system holistically to ensure that there are implementation details aligned with what your vision was. How do you take what's in your head and convert it into a running application that's going to be maintainable for a period of time. What we've seen and what we observe is these rich technical conversations, these conversations about why you're even doing what you want to do, they happen up front.

Then the goal becomes how you drive the agent to get you to where you want it to be, and that's where you get these 5x, 10x developer productivity gains. It's not just about how we write, changing how we write code. It's how we write software, and developers can join it at any point you want. You can start by writing a concept. Your product manager or your designer can come up with a concept and bring it to you with the prototype, and then your job becomes how do you convert that into a working solution with the help of your friendly neighborhood agent.

Instead of, you know, you can get, even in AWS where historically we've developed features using product press releases and FAQs, very often the way a new piece of software is built is somebody goes off for a few hours, maybe the product manager, maybe a developer, maybe your dev manager who hasn't coded for a few years,

and they quickly come up with a specification, a design, a prototype, and then all of you can review it and say, yep, we know we can build this in the next couple of days. We see this happening all the time. This is quite a shift. It's not easy. It's not a technical change. In the end, you're still building software. It's how you build that software, how you organize to build that software, what you get comfortable with. All of that changes, and you get unprecedented speed from idea to implementation, and you'll see a few examples of this today.

This flow of AI coding workflows is kind of awesome. You can get going really quickly. I've stopped counting the number of applications I've built just to show my son an example of some scientific thing like how the solar system works or Maxwell's equations. Don't ask me why. But as these tasks become more complex and ambiguous, how you interact with an agent only takes you so far. You need to start thinking at the systems level. Very often, systems thinking happens only when you are a senior engineer. I would argue that as a junior engineer you need to start thinking about it less from the side of I'm writing a particular piece of software, I'm writing code, to how's my system going to work, why am I even building this, what are the components it needs to have, and then you work with the agent to get to where you want to. You're no longer thinking about the nitty gritty of the actual coding process itself, and that's for some people a huge change.

We've also found, especially over the last six to nine months, that when people started using AI agents, they got pretty comfortable with it. They'd start talking to it, or vibing, as they called it. That word, we live in the TikTok generation. I think vibing has almost gone out of fashion. I don't know why it came up and disappeared. But it also became increasingly clear, my favorite example is you build an app and ten days later you have no idea why the app is doing what it did, what prompts you had written, and if you hand it to somebody else, you completely lose all context. So you needed constant oversight from design decisions you were writing down to documentation and testing.

Introducing Kiro and Spec-Driven Development: Building Maintainable AI-Generated Software

And the question we asked ourselves was, is there a more structured framework that we could use to make this whole process a lot easier, to bring out artifacts that can help you remember six months from now, or if you hand it off to a different team, why you did what you did so they can continue going from there and not just looking at the code. How could we bring the lessons from very mature software engineering practices to build maintainable software using AI? And that's why we built Kiro and why we built what we call spec-driven development. The idea with Kiro is to help developers and teams do their best work by bringing mature software engineering practices to AI-driven coding with the idea of spec-driven development and the concept of spec-driven development. So what is it?

The way it does it is you want to go from idea to a functioning application, but you also know that application is going to evolve from there. It may go on to another team. You may add components to it. You may be part of a company that requires enterprise-grade controls. We wanted all of those things, whether you're an individual developer all the way to a very large team at a big enterprise, to be able to use these concepts and be able to build using AI.

So the way Kiro works is you can start off with a simple set of prompts. You can convert these prompts into a clear set of requirements and structured designs. Your prompts don't have to be natural language. They can be an image. They can be a diagram. They can be pseudocode. What's in your head, how you express them. It can be done by a product manager. It can be done by a designer. It can be done by a software developer. Kiro then works with you to convert these specifications into working code, into working documentation, into working tests.

You have a feature called agent hooks. It's a feature we don't talk about that much, but it's one of the most useful features of Kiro. Agent hooks automate routine tasks in the background, and what you can use agent hooks for is to enforce development best practices automatically. And Kiro is fundamentally multimodal. You have smart context management that helps you continue to work the way you want to. And your access to frontier models like Claude Sonnet 4.5, Opus 4.5, so you can pick and choose. You might want quality, speed, cost, all of those are factors that you as a developer get to think about.

So what happens at the end, you get the familiarity and fun of what we used to call vibe coding. You can just talk to your agent.

You can get going really quickly, but you have much more powerful, maintainable code and a developer experience that helps you get there, so you can tackle any project regardless of its size or complexity. This spec-driven approach struck a chord with a whole bunch of developers. When we launched Kiro in preview, just in the first five days we got over 100,000 developers, and since then hundreds of thousands of developers outside of Amazon have continued to use Kiro. You've seen some great examples throughout this conference.

What makes spec-driven development so useful and powerful? One of the artifacts that Kiro builds with a prompt is a requirements document. It's in ES notation. For those of you who are familiar with ES, it's a markdown-based, structured way of writing down a set of requirements. Kiro can then extract properties from those requirements, and this is why I love specs. From these properties, it can determine which ones need to be logically tested, and it generates hundreds of thousands of random test cases to check your code. It helps you figure out whether this intent that you had expressed with a set of prompts that got converted into a spec is actually doing what you wanted in the application and the code that comes out at the end.

Let's look at an example. Let's say you're building a car sales app. Your traditional unit test approach would be user adds car number five to favorites, car number five appears in a list, and you would do a unit test for that. You may do a few more unit tests. With this property-based testing approach, the way Kiro works is it writes a requirement which will be something like for any user and any car listing, when the car gets added to favorites, display the car in the favorites list. That's how it'll get converted into ES with some specific language that ES supports. Then what Kiro will do is extract a set of tests and build them for you, things like user A adds car number one, user B adds car number 500, user C adds five cars, user D has special characters in their username. You may have cars with various statuses, new, used, pre-certified, all of that, hundreds and thousands of more combinations that help you catch these edge cases. These are generated automatically, these are tested automatically, and what you are doing is verifying that the code and software that comes out at the end matches the intent in your head.

This is remarkably powerful, and it's just the first step towards software verification. If you saw Swami's keynote yesterday, I think it was yesterday, re:Invent just flies by, you heard Byron Cook on stage talk about neurosymbolic AI. Because you have structure in a spec, you can start applying neurosymbolic techniques which will help you make sure that your code is doing what you wanted, and that's how you build trust in AI agents. That's how you can move at the speed of light.

Kiro CLI: Bringing Agent Power to the Terminal

Developers are finicky. Some people like IDEs, some people like the terminal. While we've spent a lot of our time talking about Kiro as an IDE, you could put this agent in a terminal as well for those of you who sit in a shell and troubleshoot and write software. That's a very natural place to be, so that's what you get with Kiro CLI. You get the power of Kiro agents in your favorite terminal. You can put it in any one, you can use them in a couple. The Kiro CLI carries over your context, your steering files, and MCP configurations from the IDE. It helps you shift with precision from prompt to deployment in your terminal, and you get the simplicity and elegance of the terminal. I assure you it's not a lightsaber, although I wish it was.

Terminals are an environment that some of the most successful developers that I have worked with using AI like to use, and Kiro CLI gives them the power to get there. Kiro CLI uses the information across your entire code base. It helps you build features in complex code bases. You can automate workflows in seconds, analyze errors, trace bugs, adjust fixes, and what you're doing in the terminal is driving this highly interactive loop at the back. There's an agent, the Kiro agent happens to be written in Strands, so you drive this agentic loop, and the CLI is just a very easy place to do it.

Since you are in a CLI, you can use automation scripts. You can automate all of this. You can automate shell commands that invoke the CLI with the right context to automatically execute prompts, so if you want to troubleshoot a production failure or generate and publish pull requests, when your task requires you to get back in the flow, you can jump right back into your terminal and Kiro will adapt to your feedback in real time. It also helps you parallelize agentic tasks really quickly. Because you have five problems, ten problems, you can just send a bunch of agents to try and solve those.

You can also manage projects using something called custom agents. You can create an agent that is tailored to a specific task, so you can put a set of your custom prompts, your context files, and tool permissions all together and create a custom agent. For example, one that loves doing backend coding, while another custom agent can do front-end work. This is where some of this parallelization can get really cool. You can run three of these in parallel, one doing front-end work, one doing back-end work, and one maybe doing some other helper tasks that go and solve some other problem.

These custom agents allow Kiro to become an expert in a specific area. They don't require any reputation. They don't risk context degradation. And you can work at any scale. You could be doing just simple bash commands or some really complex workflow or running twenty of these agents in parallel all night. So it's lightning fast and super powerful.

Live Demo: Building a Production-Ready E-Commerce Store with Kiro

Las Vegas is really dry. I've been talking for too long, so it's time to see all of this in action. I'm sure all of you want to. And who better to show you than Brooke Jamieson. Welcome, Brooke. Thank you. I've built this serverless e-commerce store on AWS. We've got DynamoDB, Lambda, API Gateway, the works. But right now it's just placeholder products. I have real product photos and descriptions for the Kiro merch I want to put in the store, and I need to get this production ready.

Kiro works however you work. In the IDE or in the terminal, let me show you both. First, I'll use Vibe in the IDE to visualize the architecture. Kiro is reading my infrastructure files and using the AWS diagrams MCP server to generate the cloud architecture diagram. We've got Lambda functions, DynamoDB, S3, and CloudFront.

Now, I need some product descriptions. I put some vague descriptions of things and a style guide in this repo. Kiro is now reading my style guide, checking the available photos, and generating on-brand product descriptions for my store. Now it's time to optimize those product images, and some of you prefer the terminal, so here's Kiro CLI. Similar capabilities, different interface. I'll ask it to resize all my product photos for the website. Keep the proportions, make the grid consistent, optimized for fast loading.

Kiro's created a Node script with Sharp, installing dependencies, processing thirty-eight images to WebP at two sizes, full resolution and thumbnails. Same intelligent assistance, just in your terminal. Now we're done and all images are optimized. Now for the complex work, replacing all those placeholder products with actual merch. This touches the backend data layer, seed script, and front-end components.

For structured development like this, I'll switch to Opus 4.5 and use spec mode in the IDE. I'll tell it what I need. Put my actual products in the store. I've got photos and descriptions ready. Let's get ready for production. Spec mode starts by generating requirements, and it's breaking down what needs to happen. Updating the backend to handle multiple product images, modifying those seed scripts to use my real data, and updating front-end components for the new product structure.

Now it's creating the technical design. Here's what makes spec mode powerful. It defines eight correctness properties, not just does it work, but formal properties like for any product configuration, the seed script produces identical results, or all S3 objects must have correct metadata headers. Each of these becomes a property-based test later on.

Now, the implementation plan. We have ten tasks broken into subtasks. Each task maps back to the requirements and design. I'm making all tasks required so we can build this comprehensively. Let's watch it work and starting with task one. This is creating the product configuration file. Spec mode reads my product descriptions, maps the image paths from the optimized images folder, sets the pricing, validates everything, and creates the JSON config. Task complete, so now onto task two.

This updates the data access layer to handle multiple images per product, and here's the key part, it writes a property-based test. This test doesn't just check one product, it validates that all required fields are present across one hundred randomly generated scenarios with different IDs, categories, and data structures. Now, I'll jump ahead to show you something important. Task nine, the final verification. Task nine writes two critical property-based tests. Property seven tests seed reproducibility.

It validates that if I reset the database and reseed it, I get identical results every time. Property 8 tests configuration-driven pricing. It verifies that when I change prices in my config file, those changes are reflected correctly in the seeded products. These aren't just testing one scenario. Each property test runs 100 iterations with randomly generated data. That's 200 test cases just in this task validating that our system behaves correctly under all conditions.

By the end, we have 8 property-based tests covering everything. And now all tasks are complete, all tests are passing. Here's the live store, we've got real products, new categories and optimized images, multiple images with thumbnail validation. But wait, this image is a bit cut off, so let's go back to Vibe for a quick fix. Kiro analyzes the screenshot I pasted in, finds the component, identifies the issue which was some wrong CSS and some bullet points that needed parsing. Now it's fixed, so work however you work. Vibe in the IDE for exploration and quick fixes, CLI if you live in a terminal, and Spec mode for structured development with property-based testing. From architecture diagram to production ready store, that's Kiro.

Case Study: How AWS Bedrock Team Achieved 20x Productivity with Kiro CLI

Back to you, Deepak. Thanks, Brooke. I wanted to share a remarkable story. You've probably heard it a few times this week, but I'm going to share it again anyway, of how one of our AWS teams completely transformed the development process using Kiro CLI. So when Anthony Liguri, who's a distinguished engineer at AWS, was asked to rebuild the inference engine for Amazon Bedrock, the initial estimates were that it would take a team of say 30 developers, 12 to 18 months to build this very critical component of Bedrock. The team knew that 12 to 18 months was not going to be quick enough. They wanted to do it much, much faster. And they also knew that adding more developers is not going to help them at all, that there's a law of diminishing returns, so they wanted to think about a different way to solve this problem. They wanted to do that without compromising the quality or reliability of the system because this is such a critical component.

And so they went to Kiro CLI to assist with their development. And the results were absolutely remarkable. A team of just 6 people was able to deliver in 76 days what had originally been estimated to take 30 people 12 to 18 months. The individual productivity for developers jumped 20x on that team. Your weekly code commits, they started off, you know, when you're doing a traditional approach, were 2 check-ins per developer, went to over 40 check-ins per developer. On average, there were some folks on the team doing even more. And it wasn't just about the numbers, the way they were collaborating, the way they were building, the techniques that they built were fabulous, and they all had fun doing it. The job satisfaction ratings on the team were exceptional because they could use their AI to handle routine tasks, and the developers worked with Kiro CLI to solve the most intricate and hard and strategic problems that they had.

But it didn't happen overnight. Initially they used it the way a lot of people use AI agents, very discrete tasks. Just, you know, working with an agent, giving it some work to do, seeing what happened, coming back to it. The real breakthrough came when they fundamentally redesigned the workflow built around the AI capabilities as opposed to bringing the AI capabilities into the existing workflows. So they discovered three critical patterns that would result in this exponential improvement. The first one was they moved from task to task supervision to goal-driven direction. Their job was to give the agent the goals that they wanted to accomplish and then providing all the supporting information, your steering files, assistance, you know, what they should be doing, providing better prompts to make sure that the agent was able to do it.

Then they scaled out to a number of concurrent AI tasks to increase velocity. I talked about custom agents earlier. They were unleashing swarms of custom agents often overnight to solve these problems, and when they came back in the morning, they would then go and review the changes that had happened. And finally they were able to extend this AI beyond coding to every aspect of what they did, from how they talked to each other, how they worked with each other, how they collaborated, to every part of the software delivery process. And that is what allowed them to achieve the level of productivity that we were talking about. They went from cautious experimentation and started seeing massive gains, and this is something that we've seen not just with this team,

but with many other teams that have learned these lessons. So as they mastered those patterns, the development velocity basically went from the 10 to 15% we had talked about earlier to the 5x, 10x, 20x that this team is getting right now. You've heard me say this a few times now. You only get those levels of gains if you change the way you build around the agents as opposed to applying the agents and getting them to add to the work that you're already doing today.

Kiro Powers: Extending Agent Capabilities with Specialized Domain Knowledge

Even small teams can dramatically outperform traditional approaches, so your developers can do a lot more. They can actually do things they may have been putting aside for the last 10 years because it'll just take a week and they don't have the time. Now you can go ahead and do it, and you see examples of that every day. The Kiro demonstrates what's possible when developers have access to powerful agents, but even with this foundation, agents don't automatically know how to use every tool out there. They don't know how to use every tool correctly. They don't know how to exactly work with an MCP server, for example, where they are translating a design to implementation, handling some security pattern, managing a deployment, making them less effective without constant human guidance. These are all lessons you have to learn.

So we started asking ourselves, how can we help? What can we do? How can we capture this knowledge and best practices that are often scattered across people, documentation, wikis, a blog post somewhere, or YouTube video somewhere? It makes it difficult for AI agents to access the relevant information to get the right context. MCP provides connectivity to development tools, but there's additional configuration required. You often have to write really good spec files. You have to write hooks so that you can get the right level and quality of code at the end, otherwise you'll have to refactor like crazy.

So developers need their agents to work with the tools they use every day. And we started thinking about how we could help, how we can make these tool connections really work for them without overloading context. Rather than leaving developers to figure out the right context through trial and error, we came up with this idea of Kiro Powers. And what we've done is come up with a system that you can build your own powers, but we also worked with a bunch of top technology providers and tool creators to build the first version of Kiro Powers which launched yesterday. You can start using it right away.

They extend the core purpose of Kiro by enabling developers to bring structure to AI, which is what we started off with. But now you can give the Kiro agents specialized capabilities or powers on demand as you need it across the entire software stack. So what is a power? It is a package set of artifacts in this particular case created by a set of tool vendors, but you can also create your own artifacts, MCP servers, spec files, and hooks. They're bundled usually around a specific domain such as backend development or UI or observability or API design.

And we've also done it in a way that instead of relying on generic agents and overloading with documentation, we dynamically load the context and exact tool access, so the way you go through your credits and tokens are also a lot more efficient. This is available inside the IDE right now. It'll come into the CLI soon, and we are working on ways to make it available to any IDE or CLI that you may be using. You don't have to use just Kiro with Kiro Powers.

So each power is designed in collaboration with a set of domain and tool providers. Here you have a set of names. It also includes HashiCorp, and these are for areas like UI design with Figma, backend deployment, development with Supabase. You can have a power for Stripe. You can build a full application all the way using these powers. You can customize each power to match your organization's requirements. You can actually go in and make modifications. You can stack multiple powers together to create enhanced capabilities.

For example, you can use the Stripe power with the Datadog power or Dynatrace to build a new payments application with observability on performance and security. You can create and share new powers with other people. Just looking at Twitter since yesterday, I've already seen people creating a bunch of powers that they can use and they're sharing with the rest of the community. Let's see this in action. So we're going to use the Kiro power from Datadog. To set up telemetry on a front-end application for real-time user monitoring, so RUM as they call it.

Once this power has been installed, we're going to activate the power in a new session. And once we are up and running, you're going to ask Kiro to add client-side logic to our application in order to start tracking these RUM metrics. So in my setup, I also need to provide an environment to set up, to provide a set of environmental variables to my application. Once this is configured, Datadog will generate events whenever somebody clicks on a button or adds new products to the cart.

But guess what? We are starting to see some errors popping up. That's what DataDog is supposed to show you. You check them out and you see that the add to cart page is causing an error, so you want to quickly resolve this issue. You ask Kiro to fetch these RUM events that have errors and ask Kiro to suggest a fix. Kiro will review the errors and determine that the errors are due to a required hostname configuration for external images. It'll apply the fix, resolve the issue with the add to cart page, and voila. You have a fixed page using the Kiro power.

We are actually using Kiro to build Kiro. We do that. We've been doing that from day one. Kiro powers is one example. All of Kiro powers was built using specs by the Kiro team. Core capabilities like system notifications and error handling were all developed purely through specs, often in less than a week. One example from very recently is how we use Kiro to build its own caching system. We built a specialized analysis tool using Kiro that reduced triage time from two hours to a couple of minutes. Most importantly, because we built this caching system, we had a seventy-two percent reduction in infrastructure costs, and all of this was done over a weekend.

Frontier Agents: Autonomous AI That Works Independently for Hours to Days

This kind of rapid, purpose-built solution development represents the power of spec-driven development in action. Building Kiro with Kiro was a way for us to learn how we could get insights into what the transformation could be, and we'll continue to add capabilities like Kiro powers that help the Kiro agent be that much more effective for the things you want to do. These lessons are super important. AI agents are changing at a rapid pace. New models come out. New science comes out. They increasingly grow more powerful because you can do more reasoning. You can handle significantly more complex work autonomously because of better context windows and better tool handling, and agents are constantly analyzing code. They're optimizing performance and flagging issues. You saw this example of the parallel execution that the Bedrock team was doing. But they're also actively collaborating with developers in real time.

So you have this fluidity of AI agents. You start off your day by working with an agent in front of a terminal or in front of an IDE, and you start assigning tasks to the AI in the background while you work with the AI on the tasks that you want to do. The background task could be anything from security scanning and dependency updates to architecture and implementation. We wanted to capture some of these practices, which a lot of developers are starting to learn by hand and implementing as products within Kiro. So earlier this week we introduced three new frontier agents that represent, in our belief, a major leap forward in AI-powered development.

So what is a frontier agent? They are a new class of AI agents that are offered by AWS. They have a few defining traits. One, they're autonomous. You direct them towards a goal, and they figure out how to achieve it without you having to constantly prompt it. They need to be able to figure out what they even need to go do. They're massively scalable. We've talked about scalability being one of the key lessons that the Bedrock team learned. How can we make that kind of capability available to everybody? The autonomous agents allow you to do that. They're able to perform multiple concurrent tasks and distribute work across agents automatically, and they work independently, sometimes for hours to days without intervention. That is a key capability.

I'm going to mostly talk about the Kiro autonomous agent because that's for software development. It helps you ship more product more quickly and focus on the highest value tasks, so you can assign all your refactoring tasks and your P3 tasks to it. The security agent is an application security agent that's constantly scanning your code. It's also doing penetration testing. The DevOps agent does incident response. It prevents future incidents, and it's constantly scanning your code in case you have new lessons that you need to apply to existing applications to make sure you are running and operating safely.

So with these frontier agents, you're no longer just being collaborative with a developer always sitting. You can deliver complete outcomes. You can add them as extensions to your team. You're going to operate in a new way of working where you are basically saying there's a teammate that you have that can help you as a team move much faster or as an individual. So let's dive deeper into the Kiro autonomous agent. This agent works with developers and with teams. It autonomously handles development work. One of the first things it does is it's constantly running. It's running all the time, building a comprehensive understanding of your code base and patterns, and it learns from your code reviews to improve with every task.

So every interaction you have with the autonomous agent makes it smarter and makes it more capable. Typically with an AI assistant, including the ones that we've talked about today, you're actively managing context, and that's the learning, that's the craft that you have to learn.

You have to constantly re-explain your preference or pattern. You have to build a system to show and share context across repositories, and they're almost always session-based. Once you close a session, the agent forgets about everything, and next time you start a session, it needs to remember.

Kiro Autonomous agent is not session-based. It's always available. It maintains context across all your work. It's running alongside you and your team workflows, so it constantly maintains context and automates development tasks, so you don't have to stop and slow down to tell it something. It's constantly going. It can tackle a full range of activities, so you can use it to develop new features. You can use it to triage bugs to improve your code coverage, and all of this happens in the background. You point it to your issue backlog and give it some tasks, so you keep doing what you need to do, and the autonomous agent will do what you asked it to do in the background.

It connects to tools you already use, Jira, GitHub, Slack in the team's version, GitHub in the individual version, to build a shared understanding of your work. So if you're part of a team, it's actually learning from Slack. It's learning from your GitHub interactions. It's learning from your backlog. And one of the coolest things is, and I think this is probably my favorite part of autonomous agents, on day 30 it's going to be more effective than it was on day 1. On day 60, it's going to be more effective than it was on day 30 because it continues to deepen its understanding of your code, your products, and the standards your team follows.

So let's see it in action. You saw the Kiro Swag store. It's grown, and you want a simple way to save your favorite items. So you want to add a wish list experience. On GitHub, all you need to do is add the Kiro label to your issue and hand this off. And the moment you do that, it hands it off to Kiro, and the agent takes over. It immediately creates the task, pulls the entire issue context, and starts preparing a sandbox. Everything you do runs in the sandbox, and after a quick analysis, it proposes a clear plan and a breakdown of this task. You don't have to tell it anything. It already understands how this change should thread through the stack because it's built that understanding.

And then the agent will go and validate the plan. It'll analyze the repo. It'll make sure there's enough context to proceed, otherwise it'll ask you for help. It then explores the project. It maps the back end, maps the front end. It looks through your handlers. It looks through your API config, your data model, and it aligns itself with the approach that it knows how the system was built, so it's going to align its approach to the way the system was built, and it runs the change end to end.

It updates data access for the wish list. It hooks it into the product page. It keeps the UI and backend logic consistent with the patterns that you're already using. It runs tests, validates behavior, checks type safety. It ensures the agent integrates properly and cleanly, and then you get a clean pull request. You get a diff and a clear summary of what changed. And since the agent is not session-based, it doesn't forget. So when you give it feedback on one pull request, it'll automatically apply the learning to the next 10.

So back in the store, you have your wish list. Users can now tap the heart. You can save your favorite item, and we track how many people love each product. And you can go even faster. You can parallelize all of this. In fact, the agent itself will figure out how to parallelize all of it, each with its own context. So let's say you're implementing a new wish list feature. Kiro can also go fix a bug over here that you found last night or solve another, do a refactoring over here.

All of this, we believe, is the next phase of AI development, increasing the velocity and scope of work that can get done by an individual or a team. I've had the, we've seen how customers have been using AI assistance over the last couple of years. They've gone from pilot to production, discovering ways that AI can fundamentally change how their teams work across the entire development life cycle. And one of the people we've been lucky to see this with is Brittany Doncaster, who's the chief architect at Delta, and she's here to share their transformation story. Welcome, Brittany.

Delta's Transformation: Reimagining the Product Development Life Cycle with Gen AI

Thank you. Thank you, Deepak. I'm so excited to be here and I'm even more excited to share with you all Delta's journey in incorporating Gen AI into our software development practices. We all know that Gen AI is transforming how we build and how we deliver software, and we all want to do it faster. At Delta, we delight in our customers experiencing delight, and we want to build software that delights our customers. And so we've been on a journey to do that quicker using Gen AI. But introducing coding assistants just isn't enough.

And if we look at why that is, everybody's been focusing on just developers and giving developers coding assistance and generative AI coding tools and agentic coding tools and all these things. But at the end of the day, developers are only one piece of the puzzle, and a lot of developers across the industry only spend about 30% of their time actually developing. So if you optimize that 30%, that's great, but you're not going to see end-to-end improvements across the life cycle.

And so we've started looking beyond the tools to our processes. Here at Delta, we have taken a dual path approach. On the first path, we're taking our existing product development life cycle, or our PDLC as we call it, and we're infusing AI into that PDLC process. We're trying to do that in a way that makes it natural for folks across the activities that they already do today. So we want to do that with as little change as possible and really just smoothing out the transitions, helping them have better data when they're making decisions, and trying to automate the processes that exist today.

But then, we know that's only going to get us so far. To really get that next level of speed, we're going to take that PDLC and we're going to chuck it out the window and we're going to reimagine what a PDLC could look like given the tools that we have at our disposal today, given Kiro that we've been utilizing from AWS and Kiro CLI. And we're going to look and see what happens when we forget what we think we know about product delivery. The reason we've done that is because change is hard for an enterprise and change management's difficult. And so we know that we've got to introduce change in a really methodical way.

So let's dig a bit deeper into the first path and talk about how we started introducing the change into the existing product development life cycle. The first thing we knew we had to do was that we had to get adoption up, and we knew we weren't going to see any changes or any difference if we didn't have people actually utilizing the tools. So we focused on adoption. We held launch events, we held workshops, and we went in just a little over four months from 6% of our user base to over 120%.

Now for those of you who are sitting there going, her math is not mathing, how do you get over 100% of your users? I will tell you. You get over 100% of your users by originally anticipating that only developers are going to utilize the tool, because that's what we thought when we roll out a tool called Q Developer. You kind of think that only developers are going to be the ones utilizing it. But as we started to do these trainings and workshops and all of the enablement sessions, what we ended up seeing was that our technical product owners, our business analysts, all the people surrounding the developers actually wanted access to Kiro CLI too.

They also wanted to use it in their process in support of building software, and so we actually ended up partnering with AWS and bifurcating the training. We created a specific non-developer training with AWS that we could give our non-developers so that they could utilize the same tool that our developers were utilizing. Because at the end of the day, Kiro CLI and Kiro, a lot of it is about the context. And when you're giving the people around the developers the same context that the developers have, you end up unlocking some additional savings and improvements.

But we quickly had to pivot from adoption to impact. So once we started seeing we have people, not just we have these users, but they're actively using it daily, weekly using this tool, we started to look at what the impact of the tool was on our metrics. Like every other company, we have a ton of different metrics for developer productivity, and one of those is cycle time. But we break that cycle time down into development time and delivery time. And we define development time as branch creation to branch merge, and delivery time is branch merge to code in production.

And what we ended up seeing was as Q and Kiro CLI adoption increased and became daily and weekly usage across our developer landscape, we saw our development time go down. But what we didn't see was our delivery time go down, and we didn't see our deployment frequency go up. And so we could see through our data and our metrics that we were coding faster, but we weren't delivering faster. And so we knew we had to go beyond development. And so that's what we did.

First, we went to the right of development and started looking specifically at delivery time because we could tell from our metrics that that was our bottleneck. That was where we needed to invest and to optimize. We looked at how we could use Kiro CLI to optimize and automate the processes that exist there. We explored how we could utilize it to improve our test automation, our integration tests, and improve some of the things that are just those paper cuts that hurt and make developers want to say, you know what, instead of delivering each of these code changes, I'm just going to batch them up because the process is kind of maybe not as optimal as it could be. So we started working on ways to make that more optimal.

At the same time, we listened to our developers and we heard that sometimes when they were getting features and stories from their product owners, it wasn't articulated as well as it might have been or it wasn't as clear to them what they wanted out of it. We started using these tools in order to help us standardize what is included in a feature and a story and what's articulated in those, and then also to help drive more clarity so that there's less churn going back and forth between the product owner and engineering.

But in order to really change the game, we know we have to go down our second path, and that is why we have started our second path and our second journey. The way we're approaching this is we are taking pilot workshops and we are breaking down the walls of the traditional teams that are part of product delivery. We are bringing the product owner and the engineering into a workshop. We did this recently with one of our product owners and our senior developers in one of our business units, and the feedback we got from that product owner was that it took them what normally would have taken them probably a couple of months to do, it took them a couple of days, really a little less, a day and a half in a workshop.

When we start looking at that kind of savings and that kind of speed, it really is transformational, and you have to start to think about a different kind of process, a different kind of team structure. What does product development look like in the future? We don't quite know yet, but we know we're going to keep experimenting, we know we're going to keep collaborating, and we know that we're going to use Kiro as the enabler for both of these.

So why does this matter? For Delta, we really want to deliver our products to our customers as quickly as we can, and so we're taking on the left-hand side what we know works today and making it more scalable and optimizing it, but then we're also innovating. We're doing this so that we can bring you the products you love faster and get more speed. But this isn't just about technology. This is about positioning Delta for long-term success. Our roadmap is clear. We'll improve today, we'll experiment for tomorrow, and we'll scale what works. Thank you. I'll welcome Deepak back to the stage.

The Future of Software Development: Multi-Agent Systems and the Path Forward

Thank you, Brittany. Delta is an amazing example of how quickly agents can help a business grow and thrive. It doesn't just help the developers build faster, it helps the builders of Delta think through entirely new ways of working across the development cycle, and they'll continue to evolve. What makes it possible is this ability of humans and agents to work seamlessly together.

So where is all of this going to go? We have seen examples of the possibilities, but we've also seen some of the challenges. Humans working with agents can ship code ten times faster than maybe you can do today, but that's only going to accelerate because of a couple of changes. If we can orchestrate multiple agents working together and redesign the software delivery processes that we have from the ground up for a world where multi-agent systems are writing and operating a good chunk of our software.

One of the questions we often ask ourselves is, what is the value of code as an artifact in a world where humans are working with agents and agents are doing most of the code analysis and writing? It is easy to imagine an expert planning agent managing context precisely, spinning up agents that implement features, review and deploy code, optimize performance and cost, and manage operations. Humans in the loop will continue to be critical. Humans provide the level of judgment and intent that nobody else can. You are the only people who know what you want to build.

But what they do, the processes they work within, the tools they use, the tools we all use, are going to look completely different from what we do, what we are doing today. I believe an IDE will evolve into a context management and agent orchestration system. The SDLC is going to be much more iterative and rapid fire than it is today.

And as all of that happens, we have many open questions. How do we make and communicate decisions faster? Humans are still involved. How do we verify intent matches output? How do we make sure that the output is verifiable? How do we build that trust? How do we reduce the blast radius of all of these changes, because things will continue to break?

The solution looks more like conducting an orchestra and less like playing an individual instrument, or if you're like me, a good band. You still need to understand what good music sounds like, and as a band you're responsible for the overall output, but you don't have to play each individual instrument yourself. And this transformation is not theoretical. It is happening right now. You have seen examples of this throughout this conference. Over the next 12 months, it's going to dramatically evolve, and we are committed to being your partner throughout this evolution.

Thriving in this rapidly changing environment requires more than just tools. It requires support, it requires continuous learning activities. And learning is just not about formal training, it's about community and connections. Learn from the people in this room. Learn from the people you see in other talks who are actually practicing what they're talking about, people like Brittany and Delta. And that's why we've built one of the technology's most vibrant and supportive developer ecosystems.

And in the case of Kiro, we have a Discord community with more than 14,000 developers, including developers of all backgrounds and skill sets. You can also join a local group within Discord. Ask questions, exchange ideas, learn about best practices through local community-led gatherings, and I encourage you to join the AWS community, the Kiro community, join a local user group, connect with community builders, discover new ways to learn, grow, and innovate together.

Over the last hour, I hope we've shown you that we are at the dawn of something extraordinary. It's not something to be afraid of, it's something to embrace. The possibilities that we have explored aren't incremental. They represent a fundamental shift in how all of us are going to imagine, create, and deploy software, and we're going to be with you throughout this journey. We're going to provide the technology, the resources, and the support, and I'm really excited about the future that's unfolding and what we'll achieve together.

To help you get started, we're offering every re:Invent attendee 1,000 Kiro credits. And for the startups in this audience, we're giving away up to one year's worth of Kiro Pro Plus tier, up to 100 seats credits as well through the end of the year. You can go apply at Kiro.dev. And thank you, thank you for being here today. I hope you're as excited about the future of software as I am, and I can't wait to see what you build.

---

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