🦄 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 - Epic journey: Navigating the AI-powered SDLC from backlog to production(DVT208)
In this video, AWS's Ali Maaz, Dr. Ricardo from Ericsson, and Doug Clauson discuss AI's transformation of software development from AI-assisted to AI-driven and AI-managed approaches. They introduce a maturity framework showing how AI evolves from assistant to orchestrator, addressing the persistent challenge of shipping against capacity constraints. Dr. Ricardo shares Ericsson's journey implementing AI-native development using Amazon Q and Kiro CLI, deploying seven specialized agents across 1,500+ engineers to handle complex telecommunications software, reducing specification time from weeks to hours. Doug demonstrates Kiro CLI's spec-driven development, custom agent profiles, Model Context Protocol integration, and agent hooks for autonomous workflows. The session emphasizes that successful transformation requires not just technology but also change management and cultural shifts, with AI handling undifferentiated heavy lifting while developers focus on architectural decisions and validation.
; 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: AI's Transformation of Software Development and the Capacity Constraint Problem
Hello everyone. Welcome to DVT208. Thank you for joining us here today. I'm Ali Maaz and I head the go-to-market for AWS's portfolio of developer services. Today we will be talking about how AI is transforming the software development life cycle. We will share some practical frameworks for you to think about this transformation and the maturity of this transformation. We will share real-world examples about how some companies have undergone this transformation, and towards the end, we will also talk about what the future holds for all of us.
This is an image which is super interesting to me, and I want you to spend five to ten seconds looking at it and imagining this as a parallel to shipping software. As you think about it, what do you see? It's a busy road with a lot of delivery happening and a lot of software getting shipped here. What you don't see, and what I am sure you don't see in the real world either, is the backlog that never gets addressed because that is what never comes out. So this is an audience moment for me. With a show of hands, tell me if you have been part of a developer team where you have had more backlog than you can possibly deliver.
Exactly. Keep your hands up. Tell me if you have been in those rooms where you have had to sit in gruesome, painful meetings where you have had to make decisions about prioritization. Thank you. So there are things about software development that are very awesome and amazing, but then there are things we never talk about. Regardless of whether you use agile, waterfall, kanban, or whatever methodology is your flavor, the reality is there is almost always more work than people available to deliver it.
Before AI, there are only two possible solutions. Either you increase the number of people, or you ruthlessly prioritize. The issue with that is that even when you do both together, nothing happens. The problem still persists. There is this notion in the industry, and before I introduce the two gentlemen here, I want you to think about this. We are shipping against capacity and this constraint has defined software development for the last two or three decades.
The idea of AI-driven software development is all about AI taking over the undifferentiated heavy lifting while you and your developers focus on the critical and creative aspects of software development. Now I am sure you would have heard about this many times, and today we are not going to talk about that because that is a boring topic now. As we get into the session, you will see me talk about the problem space, how and why AI matters, and how to think about maturing the organization that you represent and what maturity looks like.
Then we have Dr. Ricardo from Ericsson. He has been leading that effort at Ericsson, particularly leveraging Kiro CLI to drive change in software development processes. Finally, we have Doug, who is the principal product manager for Kiro CLI, and he will talk to us about what the future holds for us and for you, and how that future fundamentally redefines how software is going to get shipped in the future.
Evolution from Human-Centric to AI-Native Development: The Journey from Waterfall to Autonomous Workflows
Now that we have set up some preamble of what we are going to talk about, let's spend a couple of minutes on how we got here. Let's date and age ourselves and go back to the 1980s. For some of us, at least that is a reality. Software development matured as we started with waterfall, then became agile as Internet speeds came in and you could ship and update software on the fly. We then realized that developer teams and ops teams need to work together really well, so we have DevOps.
Then we said, why don't we automate everything and manage only things that matter. We started automating CI/CD, we started automating testing, and so on and so forth. In that journey of thirty to thirty-five years, notice that humans are almost always at the center. Any tool, any process, anything we do was all about making the developer more efficient. Here comes 2023 and all our worlds changed. We ushered into an era that we personally call the bolt-on era.
You had AI plugged into everything. Everything you're writing in code, you need AI to assist you there. You are writing unit tests. You need AI to assist you there. You're doing code reviews. You need AI to assist you there again. No human is still at the center. If you go back to that highway, that road, the driver is now going faster. That's the intent.
Now as we end 2025 and get into the world of 2026, we are now in that era of AI-native, and in that world increasingly with LLMs getting smarter and tools getting smarter, we are increasingly getting into the era of asynchronous and autonomous workflows. Now it doesn't mean that anything is going away. It is that technology is adding itself into your existing processes. And so now it's not just about technology. What we really need to think about is how do we change processes, how do we change culture.
Before we get there, so far we have talked about two or three things: shipping against capacity, we are moving from human-centric to AI-native, and the third is remember some of you might remember the capability maturity model. As organizations get into that journey of people and culture change, you need to have a rubric with which you measure where you are in terms of maturity and where you need to be. That's where we are.
Achieving Paradigm Shift: Positioning AI as Central Collaborator Rather Than Assistant
Now let's talk about the few concerns that some of the personas have. That's what our internal teams tell us. That's what our customers tell us. That's what you tell us. So 28 million developers out there talk about an unprecedented change coming to my industry. I don't know how to be prepared now. Some of those developers are also practitioners or managers. They have evaluated for the last two years 12, 13, or 14 development tools, and they are concerned about reliability. They almost always compare these tools at a point in time and by the time their evaluation is complete, the product has fundamentally changed, so they are concerned about real reliability.
Now when you go to the top, you talk to the CEOs, CTOs, CIOs, CFOs. They basically understand the value of AI, but for them it is all about scaling it across the organization. All of them. Developers are worried about relevancy, practitioners and managers in the middle tier are worried about relevancy, and C-level executives are worried about scale. But underlying all of this is one big question that they're all asking, and that's to us, that's the common root for all of us.
And that question is: how do I achieve a paradigm shift rather than a step increment? That is the question that matters. Everyone can add another AI tool to their toolbox. It's a step increment. It does not fundamentally change the way you are going to think about software today. The debate and the discourse is all about how can I make my development processes or developer 10% more effective. You know what? I will be awesome if I make it 15% more effective. How about 18? But that's not the problem. I think we're still thinking too small. I think where we are going in 2026 and beyond is about 10x thinking, 10x creativity, and I think that requires a paradigm shift and it's not just about performance improvements or doing it faster.
The answer for us is we prepare the development teams of tomorrow by positioning AI as the central collaborator. That does not mean that the human is out of the loop. All it means is that AI is orchestrating. In the bolt-on era you had AI that was acting like a GPS. So if a human-centric design developer is designing or working, AI is the GPS that guides, so you accomplish the task faster. In the world of AI being the orchestrator, the relationship completely flips, and once it flips, the paradigms are different.
I'll give you an example. So today AI is not just an assistant. In this world of AI-native, it is actually a collaborator. It is participating with you in planning. It is helping you decompose complex requirements into tasks. It is also helping you design or create architectural patterns that are relevant to your situation. So for all practical purposes, it's no longer an assistant but a peer. It's no longer a tool, but somebody sitting right next to you. And once you make that mental shift, possibilities open up because if you go back to that highway, now you have literally created another lane. And that's where it's not humans driving, it's somebody else driving while humans are still involved. So now the question really is, should we as developers be worried? I don't think so. Quite the contrary.
It's actually elevating the developer from just a practitioner to something that they do really well, which is decision making. It's all about insight and validation. You've got to be there to steer the lane that AI is operating on more efficiently and more productively.
Framework for AI Development Maturity: From AI-Assisted to AI-Managed Development
Now let's culminate this into a very simple framework. It's as simple as this gets. You have AI-assisted development, which is where 2023 started and where you are now. We are increasingly getting into the area of AI-driven development, where AI is taking the role of the central orchestrator and you humans are staged around it. In that world, you're now moving from the realm of individual productivity to system-level or team-level productivity.
Then there's the area where nobody is yet and we will probably get to: AI-managed development. Think of that highway and now think about all the lanes being run by AI, with the human sitting on the side making sure all the decisions are being validated, all the right structures are being ensured, and system integrity is maintained. Roles are going to morph, and that's what we think. This is another way of thinking about where you are in that journey in terms of your organizations.
Now I'll give the floor to Doctor Ricardo, who is actually leading that effort in real time. How long has it been since you've started this journey? Over to you, sir.
Ericsson's Scale and Challenge: Delivering Complex Telecommunications Software to Global Operators
Thanks a lot. So I have a surprise for you because I think we have such a nice audience and we are prepared here for more like a rave party. I just talked to Steve Aoki to come here and give a show for us in the 30 minutes we have. No, I'm just kidding. We're going to talk about Ericsson's journey here. Thanks a lot, Ali, for the invitation to be here with you today.
As you said, we at Ericsson have started this journey quite some time ago, and it's a journey that we have had many people contributing towards its success. I should say we have colleagues here in the audience like Doug and other people who have been doing great work in parts of Ericsson to help the company be successful in this whole AI transformation. To add context here, the first thing I'm going to ask you is: how many of you have heard of Ericsson before? Can you raise your hands? Yeah, quite many. Maybe if it was years ago, I think the complete audience probably would raise their hands.
We used to be in the consumer market back in the days. We had very nice mobile phones, probably the best in the market, but the consumer market was never really our core business. Then we decided at some point to focus really on our core business, which is actually to provide top-class, high-performance networks.
In one picture, I'm trying to give you the scale of how impactful Ericsson is to the world. Around 50 percent of the entire 5G traffic outside China in the rest of the world is actually going through Ericsson Networks as we speak right now. So we're talking about billions of subscribers that are using Ericsson products even though they don't know that. Probably if you are navigating the web right now, you are using indirectly some of our products in the market.
More specifically, I'm part of one group in Ericsson that's responsible for the products that actually help the operators to monetize their networks. Basically, it's not enough to have the top radio equipment that Ericsson provides. You need to have software on top of that to be able to make money out of your networks. So here in the US, AT&T, T-Mobile US, Verizon, and others are examples of customers we have.
In this part of Ericsson that I'm supporting, we are actually delivering products to those big operators and also small operators in the world to enable them to sell whatever products they want to sell to the subscribers and deliver the services in the best way possible, enabling a very smooth experience for those subscribers and of course to get paid, because they are here to make money, and then we are helping them.
However, the reality is that this type of software is very hard to develop. This is true both here at Ericsson and globally in the telecommunications industry. It is very complex, and the complexity is just increasing because there are more expectations every day. People want to have extremely low latency in their networks. They want to have endless amounts of data flowing through the networks, and they do not want to pay much for that. So the challenge is how we help those operators provide great service. We need to keep improving ourselves to provide our customers, the operators, with best-in-class products and really compete in a very fierce market.
The traditional ways of developing software are simply not enough anymore. Even more than that, if you just bring AI tools to your set of processes, that will not help you either. You need to think beyond that and consider how you can actually transform how you introduce AI into your ways of working. This is what we call AI-native software development.
AI-Native Software Development at Ericsson: Seven Agents and Nonfunctional Requirements from Day One
In practice, AI-native software development is in a way back to basics. In the context where we develop software, we are handling very complex systems. We have thousands of engineers working together around the globe, so it is very hard to maintain those AI principles of small teams working very close together with no handovers, with people doing things end to end. Those systems are just too complex. In AI-native software development, we introduce a set of agents that actually help to handle this complexity associated with developing those very complex systems so that we can actually be true to AI principles even in large-scale software development, which is the case at Ericsson.
Another thing that is very important to highlight here is that in AI-native software development, I am able to do an extreme version of what you have probably all heard about, where I am able to introduce quality from the very first day until the very end when I am releasing whatever new requirement in my product. The agents support the process of designing the solutions I need to put in place. They support the process of developing the code following whatever conventions I need to follow. They review solutions and the code in real time to make sure I am actually taking into consideration very early whatever nonfunctional requirements that I need to take into consideration throughout the entire lifecycle of my features.
So AI-native software development is about having nonfunctional aspects being taken into consideration from the very first day. We are making sure that we are not catching things later. We make sure that we are getting code done right in a way that does not matter if we are coaching or an agent is doing that on our behalf. What matters is that we are fulfilling those requirements we need to provide in the best way possible with the right quality level and with the right time to market.
We have established a blueprint that includes the seven agents that you can see here. Of course, you could do this in various ways. This is the way we have done it, and this is the way we are doing it today. Will this be the same forever? There is a chance we keep evolving this. We might add other agents, but today those seven agents are the ones we have.
These agents have different skills. We keep adding skills so that those agents can help the cross-functional chain that will be developing each requirement end to end to take into consideration those nonfunctional requirements. I am highlighting nonfunctional requirements a lot because those are the hard ones to take into consideration very early in the software development process. We tend to focus a lot on functional requirements for obvious reasons, but if we do not have a focus on nonfunctional requirements early on, we know what happens later in whatever development process we need to put forward.
These agents are really helping us focus on nonfunctional requirements very early in this process. We have product managers working very closely together with engineers. I even highlighted this in red here because I was talking to my manager about why we have the product manager there in red.
The problem is there is always a kind of debate between engineers and product managers because they have different responsibilities and need to focus on different things. Very often they are not close enough. In an age of software development, product managers need to be here together with the software development teams because we want to do things end to end. When I'm developing one requirement, I want to see it realized from the very beginning when the product manager is pushing out a specific requirement and helping to clarify what needs to be done, and then following up until the very end when I'm actually releasing that software, taking into consideration whatever nonfunctional aspects I need to consider: security, performance, UX, and everything else.
Partnership with AWS and the Game-Changing Introduction of Q CLI with Agentic Capabilities
This is where we have had great support from AWS to realize this. We have been working together with AWS from the very beginning when this product was called Code Whisper. I tell you, it was a bit painful at the beginning because the tool was not where our engineers expected it to be, and they were complaining. I'll be very open here. They asked, "Why are we using this?" I said, "No, we're at the beginning of the journey. Give it some time. I have confidence this will improve fast." In a very open relationship, the AWS team showed us time and time again that they had what it would take to evolve this product very quickly, and they delivered.
Today the product is now called Amazon Q in QuickSight, as you probably know. There was actually a big breakthrough around April when AWS introduced what was called Q CLI, providing agentic capabilities to this product. You have heard a lot of hype about agents. The thing is, this is really a game changer. Before and after, it's like day and night. Before Q CLI, our engineers were not as excited about using this type of tool in the software development cycle. After that, we had to start stopping them. We said, "No, wait a bit. We need to take into consideration security aspects and other things. You cannot just go on your own because everyone got so excited about having agentic capabilities supporting them in realizing their ideas and letting their creativity flow."
This was really a game changer. The other two things that make this really spectacular are combining the right context that we give to the agents that we have here, which are operationalized using Kiro CLI, but also giving access to tools. If we don't do that, then we are limiting it. It's like your agent has no arms. How much can you do without that? The Model Context Protocol has been the other breakthrough that has helped bring things to the next level. The combination of these, which we call the System Knowledge Plane, actually provides more digested information to the agents so that they know about our products. Otherwise, they would never know about our secret sauce.
I cannot expect it's there in Kiro because if it's there, we have a big problem, right? I need to provide that, and it's more than just giving access to everything. We're talking about millions and millions of lines of code here. Of course, lines of code alone don't mean much—you could have a terrible code base—but just to give you a sense of scale, we're talking about millions of lines in large, massive products here. I cannot just give you everything. I need to help the tool know where to look.
That's what we do with this system knowledge plane, where we've developed a few knowledge graphs and basically provide this digested type of information at the right time to Kiro so that it will help us realize the features we need to develop. Together with the tools, we can achieve a lot here using this product. So I'll ask you another question: how many of you are using Kiro CLI, using MCP servers, and so on? How has your experience been so far? Do you like it? Maybe what we're missing is exactly the system knowledge plane that we have here, right?
We're talking about thousands of people at Ericsson that we are going through this transformation now. Many people are excited and going on their own, right? But with all this work we're doing here, what we're trying to do is raise the bar so that everyone starts from a much higher baseline. I want to have as many 10x engineers in the company as possible. The ones that are 10x engineers today will become maybe 100x engineers or 1000x engineers, right? But globally, we're going to enable the community of engineers in the company to achieve much more. I need your help for that.
Ericsson's Four-Level Maturation Model and Results: From Weeks to Hours with 1,500+ Engineers
Those people should know where they are. We've introduced a maturation model that helps people compare where they are today to where they need to be. This is actually very simple. We have four levels here. The first level is software development with AI. We just give access to the tools, and people start exploring using the best effort they can. The second level is where I start providing templates, access to some MCP servers, and so on, so that rather than just spinning around wondering what the best way is or where to start, people already have a good starting point to begin having impact.
At the third level, I add more dynamic agents plus the system knowledge plane, where I have those graphs that provide the right context at the right time. Finally, I merge this technical enablement with a complete revamp of how the teams are organized and how they should behave. Then we finally achieve what we call AI-native software development, where I've completely transformed the process of developing software by introducing agents natively in the ways of working, really transforming whatever we have today.
How do we really do that? Technology is essential here, and of course we have this great partnership with AWS. We are working very well together, and that's a key element to it. We also realize at times that we actually need to do some things ourselves, and when we should do that, we do that. But that's part of the story. Without the other two pillars you see here, without proper change management—where you have the right governance approach in place—it's very hard to change a large organization. You don't need this kind of very structured approach if you have maybe five to ten people, but if you have a thousand people, if you have ten thousand people, sorry my friends, you will never succeed in introducing a big change like this. You need to have a really formal governance approach to be successful here. And finally, as part of this change approach, we focus on the cultural side of things.
If you don't focus on the cultural side of things as part of this change approach, you won't be successful because this really requires people to think differently. You probably find yourself thinking, "I have worked like this for 15 years and it just works for me. Why am I going to change?" But you can do better, and that's what we're saying here. We need to help people realize and understand they can actually do better. How do you do that? You need to help people upskill themselves. You need to give the right incentives and use this in your performance management of people.
At the same time, we should provide a good baseline to people. We should not stifle innovation. Let people innovate. They will bring things here and surprise you. Then you realize that what you started here will just explode and become bigger than what you thought in the beginning. Basically, to wrap up here, it's not about replacing people. It's about augmenting people. As I said, I want to have 10x factor engineers everywhere in my organization. It's about getting code done, not about coaching again. AI will be doing more and more of that path for us, but we still are in the driver's seat. We still need to be accountable for whatever goes through here.
Having the support of those agents will actually make the difference. I can give you some numbers about this transformation. I'm showing the numbers connected to my part of Ericsson, which is one part of a very large company. But we have other parts like in other organizations as well where the transformation is happening. If I see Ericsson as a whole, the numbers are even bigger. Of course, I'm talking about the ones I'm responsible for. We have 1,500 plus engineers already using the design approach here, making use of some of the agents. We don't have all those agents yet because it is a journey.
We have heard of spec-driven development. AI and humans is bigger than that. Spec-driven development is part of it. We have some of the agents already there, and people are already using them and helping us keep evolving that. We already see the benefits. Rather than weeks to have software specifications in place, now we can have it in some cases in hours or just a few days. Software testing and troubleshooting can be very tricky. Imagine these are very complex systems. Here we're seeing situations that previously took weeks. It's not because people are not good—we have great engineers at Ericsson. It's just that the complexity is too big.
But now with the support of AI, those agents are helping us read it in weeks, and in some cases, a few days or even hours, helping us troubleshoot and test things. Are we done? Not at all. We are just going through this journey as I speak here. We have already achieved a lot, but we know we're going to achieve even more. That's where Doug will actually talk more about what is yet to come when it comes to Kiro and how it will help us in our journey. Thank you.
Kiro IDE and Spec-Driven Development: Structured Requirements, Design, and Implementation with Context Management
Thanks Ricardo. I really appreciate your insights and learning a little bit more about Ericsson and your journey and how you've adopted this AI-native approach. My name's Doug Clauson, and I'm the Principal Product Manager for the Kiro CLI. I'm going to walk you through how we're building that future of AI development here at AWS. I want to start from Ricardo's last slide and talk a bit more about how we see Kiro and how it fits into this picture. We want to support you across all three of these initiatives, but the reality is, as Ricardo said, that change management and the cultural shift are likely very unique to your organization.
Your governance requirements are unique, or your legal frameworks might vary by industry or region, and your culture and how you see yourselves adopting AI is something that really only you can define. What we think is a bit more universal is that technology layer, and that's where we've been actively investing in building over the last couple of years—the tools, the infrastructure, and the capabilities that will enable this AI-driven development. Now I'm excited to show you today how Kiro can provide that technology foundation, but before I jump into a few demos, I want to level set on what Kiro is and what you can do with it.
Kiro gives you flexibility in how you want to work, and we have both an agentic IDE as well as an agentic CLI that will integrate AI development from prototype to production. I'm going to talk about the IDE first. We just launched this in preview earlier this summer. We launched it in GA on November 17th, and one of the coolest features to me of the Kiro IDE is that it has this structured spec-based development where Kiro can guide you through the requirements definition, the design, and then the implementation. Has anyone tried that? I see a few. What I think Kiro forces you to do is align on the spec first, and then Kiro executes the plan step by step after that. Or you can choose to use a conversational approach, what some call vibe coding. You can vibe code as well and then iterate on that. It's really your choice. You choose how you want to work.
You can also automate workflows with a feature that we call agent hooks. Agent hooks trigger on what you set them up to trigger on, and then they take an autonomous action after that. It's probably easiest to explain by an example. If anyone has ever worked with localization files where they help your app work across multiple different languages, it can be a lot to keep them up to date. Agent hooks solve that problem. You can set up an agent hook so that whenever your English localization file gets updated, the hook triggers and automatically updates your other localization files as well, keeping everything in sync. These agent hooks allow you to focus on those repetitive tasks, allowing you to focus on other things.
And then finally, there's context management. Feed Kiro your documentation, connect the MCP servers like Ricardo showed you, share UI designs to help Kiro understand your whole project context, not just an isolated request. On the context side too, Kiro can automatically generate what we call steering files. Steering files are a summarization of your project, but also give you the ability to customize how you want Kiro to build. The result here with the Kiro IDE is you get an AI assistant in the IDE which adapts to your way of working and not the other way around.
Now, before the demo, I do want to talk just a bit more about spec-driven development and why we feel like it matters. Spec-driven development means creating specifications as the central artifact of your development process. It's really not new, and in fact, I would argue that most of us have done it before. It's just that the whole introduction of vibe coding has caused us to sort of walk away from it. Spec-driven development is a set of proven principles and formal requirements, but the introduction of AI agents has made it even more important to cycle back to this.
As I mentioned, traditional vibe coding with an AI is great for prototyping or maybe a low-risk task, and it focuses a lot on that implementation phase. But it focuses less on the other aspects of software development which are just as important. You can iterate fast, you can generate lots of code, and maybe you get a working solution. But what it does sometimes as well, especially if it's a complex task, is create this stream of consciousness problem where your design and requirements get buried in the chat log. Your requirements from what you started with have now drifted to something else, and six months later you come back to it and nobody knows why you built what was built because there's no documentation to go with it. Anyone had this issue even without AI? This happens, and certainly we have as well.
Now spec-driven development solves this. Specs serve as a contract between you and Kiro, and Kiro translates your natural language into a structured format that will preserve the intent while being actionable by the agents under the hood. The result is higher quality output with better alignment between you and Kiro. I think it's easiest to see this as a demo, so let me show you what it looks like. Kiro supports vibe-based development, but for this demo we're going to use spec mode with Kiro assisting us through this process. We're going to start by submitting a new prompt just like we would normally, telling it what we want to build. In this case, we're building an events planning app, and we want to add the ability to add a category to these events and then sort by the category. This change is going to require some database updates and some new UI components, so Kiro is going to analyze that prompt and get to work.
Now to access Kiro's specific features in the IDE, the easiest way is to navigate to the Kiro tab, and here you'll find the features I mentioned before like the specs, the steering, and the hooks. We're going to click on our spec. Specs generate three key deliverables: requirements, design, and then the implementation task list. We're going to start with requirements. These are structured as user stories with well-formed acceptance criteria, and you have the opportunity to review these for completeness and modify them as you see fit. In this case, I saw that it wasn't going to display any events that had no category, so I'm asking you to make that change. I type in natural language, and Kiro is going to make that required update to the acceptance criteria. And there we go.
With these requirements finalized, we're going to move on to the design by clicking the "Move to Design Phase" button. The design outlines high-level components like the API routes, the air handling strategies, and testing strategies. You can modify this or continue to the task list. Overall, this looks really good to me, so we're going to move forward by clicking the "Move to Implementation Plan" button in the lower right. It's going to create our task list.
Here's the task list. Notice the requirements traceability here, which links each task back to the specific requirements that it's addressing. Now Kiro gives us a choice. It wants to know whether we want to build the MVP or build everything at the same time. If you know anything about how we like to build at Amazon, we call them MLPs, the minimum lovable product. You've probably heard that a few times, so we're going to choose the MVP first.
With that selection, Kiro is going to automatically go through and update the implementation plan, the requirements, and the design to that new MVP scope, and we're ready to get going. You start building by clicking the "Start Task" button on any of those tasks in the task list. This gives you control over the execution, letting you verify each task individually as it becomes completed. Our first task here is going to create the category model. We're going to go ahead and it's asking to run a Python helper script, so we're going to let it do that.
It's running and I fast-forwarded a little bit here, but you can see the code is all generated and the tests are passing, so we're in good shape. It's also asking now to run another command because it wants to validate that the database schema was run properly. You can see there in the lower right it's asking if it can run a command. So we're going to give it approval for that. Now with the test passing and the database schema validation done, this task is complete and you see it marks the task as complete up top. It's really that easy.
I did a little bit of demo magic here and I fast-forwarded through some parts, but I think you'll find that for some of these larger tasks, these specs add structure to what you're building. It'll feel familiar if you've done this before. It'll give you the features you're looking for and it'll also help you build some additional artifacts along the way that will help others understand why you did something that you did. Now I mentioned this up front, but Kiro is more than an IDE. Ericsson is one of our great customers on the CLI, so let's talk about the CLI as well.
Kiro CLI and Custom Agents: Terminal-Based AI Development with DevOps Agent Demo
The Kiro CLI is your AI-powered companion that lives right in your terminal. First, it handles your complete workflow from planning and debugging issues, writing code, and deployments, all without switching any context between different tools or interfaces. Second, and probably my favorite thing, is it adapts to how you work. You can build custom agent profiles and use steering files that match your team's standards, your performance frameworks, or your specific use cases. It's really not a one-size-fits-all. It's configured to your workflow.
These custom agents are what Doctor Ricardo just talked about in using, and what he built with their security expert, their architecture expert, and their user experience expert. It's all built on top of the CLI. They're a game changer because they let you adopt AI-driven development the way you want to adopt it, as opposed to what a more structured approach would take. Here's a real example going back to the steering files. I was using the steering files in an application that I was building for fun. I was building a Next.js application on Vercel, and for those that aren't familiar, each request that you make, like loading a URL, costs you what they call an edge request from your quota.
Kiro, which wrote all of the code, was using a capability of Next.js called prefetching, which was automatically loading all of the linked pages on each of the pages that got loaded. That's fine, except for the fact that it was costing me an extra request for every linked page that was getting loaded. Now as my project evolved and got bigger and I had a lot of linked pages, it was costing me far more edge requests than I wanted to. Honestly, for me the pages were simple and it was a fun project, so it wasn't worth the quota that I was spending on that. So how do I disable that? I use my Kiro steering files and I told it that I don't want to do prefetching anymore.
Now even if I forget to tell Kiro as I'm building something and it starts creating links, I get no more prefetching because it's in my steering files and it's something that I want to do. Third, the Kiro CLI is context-aware and it can share context with the IDE as well. You could feed it your documentation, your MCP servers, those UI designs we talked about, and it will understand that full project context. The result of the CLI is that you stay in flow in your terminal. For those that like the terminal-based experiences, this is the one I'd suggest that you try. It understands your way of working and it's very adaptable as well.
I'm going to show you now a demo of my probably favorite feature of custom agents because they've been so powerful in helping customers adapt the way they want to be developing. All right, so here we are in the Kiro CLI. I'm specifically going to show you those custom agents. The CLI works off of what we call tools and MCP servers. A tool is something that allows it to take a command like reading or writing a file or searching a website. I'm showing you those tools that are loaded, which are trusted for the default agent.
I've also built a bunch of custom agents for special purposes. I have a Jira assistant, a security officer, a solutions architect, and this DevOps agent that I just swapped into. This is changing the way the CLI is working based on how that DevOps agent is configured. Let's take a look at how it's configured. It has a set of pre-approved tools and MCP servers, and it also has a custom prompt, which tells the CLI how I want it to behave and how I want it to work.
Let's look at that custom prompt as well. In this case, you can see it's very verbose. I was very specific about how I want to build infrastructure code for my project. Now, I'm not an infrastructure code expert. One of the things that I added in my files is that when it proposes a solution, I want it to tell me why that deployment strategy is the right approach. This helps me learn as I go, but it also helps Kiro be more critical about the actions it's taking.
Now I'm showing you the MCP servers that got loaded because we switched into this agent, and you'll see that the tools have also changed slightly from before. Now I'm going to ask this DevOps agent to generate infrastructure code templates. Specifically in Terraform for this project, which is the same events-based planning app we were working with before. This would have taken me honestly hours, and maybe even days. I am not an infrastructure code expert, and my ability to write Terraform is not strong. While I know what I want to do, the specifics of doing it are something I'm not great at. But here you're going to see the DevOps agent creating all of this from scratch. These Terraform templates are not generic templates; they're custom built for me based on what I requested.
We're going to let this build for a second. I also told it, and I'm not sure if you caught this up front, but I also told it what I pre-approved and what I allow it to do on its own. I gave it the ability to read files, but upfront I had to give it approval to write any files. We'll get just a few more seconds to complete. While it's doing that, just remember these are custom built for me based on how I've configured that agent. If you want something different, you build it differently. Now you can see it's complete. It's giving me a summary of what was built and then what I need to do next, because that's how I told it to work. Again, these custom agents are super powerful, and as I've already called out, they let you build how you want to build. They're flexible, and if you haven't tried them, give them a shot.
Best Practices and the Future: Moving Toward AI-Managed Development with Proactive Autonomous Action
You can write a very long and verbose file about how you want to build, and it will follow all your rules when you're building. These custom agents have allowed a number of customers, including Ericsson, to build their AI-driven development processes the way they want to build them. Now we've been using the Kiro CLI for a long time, even before we released it, so we have some tips and tricks that might help you build a little bit faster. First and probably most important, provide the context up front. Don't just ask a question. Share the relevant files, paste an error message, or paste a compiler error. Even better, create a custom agent to change the way it works based on how you want to build. The more context Kiro has about your environment and goals, the more accurate response you're going to get, and the happier you're going to be.
Also be very specific about constraints. Tell it your security requirements, tell it your preferred programming languages. If you're building production code, tell it what production ready means for you. Be very specific, and it will work with that. Don't make Kiro guess. Often when I work with folks in teams, they're typing a single line like "generate this API," and then they say "Well, that's not the result I wanted," and I say "Well, but you didn't really tell it what you wanted. You just told it something very simple." So be very specific in this. This customization and the way you prompt is very important to get the results that you want.
Second, start with specifications for production code. This will emphasize good workflow hygiene up front and prevents the "generate everything and hope it works" approach. I'm sure we've all done this before, or the YOLO pattern as I like to call it. Reviewing these specs gives you and your team something to look at prior to the code getting generated. Often it's easier to look through natural language and a set of requirements than it is to look through the code to figure out if it met all of those use cases. This will position Kiro more as a piece of a disciplined development process rather than just an ad hoc code generator, which is not what we're looking for.
Third, iterate and verify. This is a conversation. Review what gets generated, test it in your environment, and refine. Even better, shift everything to the left. Give Kiro the ability to run your unit tests, give it the ability to run your integration tests, give it the ability to scan your application, and if you're using any canaries, run those canaries and see the output. Let it then regenerate a solution until it has a working solution and provide that to you. Your expertise combined with Kiro is going to drive the best solutions, but everything you can shift left will help you get a better answer earlier in the process.
Fourth, and probably another very important one, use it for the right tasks.
Kiro excels at generating code, as we've talked about, and plans and researching options and helping debug issues or maybe even exploring alternatives. But you're the team lead. You excel at knowing what done looks like, and you're responsible for assigning work. The more you use Kiro, the better you're going to understand what it does well.
If you get to the point where you understand what it does well, it's just like working with a new colleague or maybe learning a new programming language. It takes some time to understand how to work with the AI, but as you start to learn that, you'll get better and better at prompting what you want and the solution. You'll get even better results. Then, for example, I've been talking about partnership. Going back to the project that I was building, I wanted users to see the latest information on my web app. This is kind of an embarrassing story for me since I just told you all these things to do and I didn't do it myself.
I asked Kiro to help, but I didn't dive deep enough into what it had built. I tried it and it seemed like it was working. All the web pages were getting updated near real time, and I thought, oh, this is working perfectly, so I shipped it. I should also say, keep in mind this is just something for fun, not a production app. I wouldn't do that in production. Next morning I checked my Vercel dashboard and I saw thousands of edge requests. Again, this is a personal project. There's no way I had that many visitors.
So what happened? Well, I didn't look at the implementation, and Kiro had shipped the ability to do client-side polling on all of my sites. So when any of my web pages were open, every single minute on any browser that had the site open was asking for a new version of the site consistently. That's where my wizard requests went. I learned my lesson about the oversight and the partnership and about not passing all of the judgment onto the AI, because that's not something that I wanted to do.
The bottom line is Kiro is going to work best when you use it as a skilled collaborator and not a replacement for your judgment. So I want to close out by coming back to where we started. I changed the slide just a little bit from where we started, but we're at an inflection point for how software gets built. Kiro can handle the orchestration of development and the planning, the task breakdown, and the code generation. The transformation is about you making the architectural decisions and you're validating what gets built solves the problem. You're validating that what gets built is what your customers need. You're providing the judgment and direction that Kiro is not replicating today.
What I'm really excited for is the top circle of this. We're in this AI-driven development today, but we're just getting started. Today, Kiro is assisting and orchestrating based on your direction, but we're moving towards this AI-managed development world where Kiro doesn't just execute based on your plan, but proactively considers other alternatives, maybe suggests improvements, and then even potentially takes autonomous action based on your performance or real-world user data.
So imagine that future where Kiro is not asking for your approval and doesn't wait for you to ask, but instead it's telling you what needs your attention and where it needs help. With Kiro, we feel like we're not, and we don't think you will be, just writing code faster. It's more about building better software with more context, more consistency, and more of what matters to your customers. So we think AI-driven development is here, and we're super excited to see what you do with it. Thank you. If you have any questions, we're going to stick around up front for a few minutes, so come see us.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)