AWS re:Invent 2025 - Accelerate multi-step SDLC with Kiro (DVT321)

🦄 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 - Accelerate multi-step SDLC with Kiro (DVT321)

In this video, Derek and Kieran from AWS's Developer Agents and Experiences team demonstrate how to use AI throughout the entire software development lifecycle, not just for coding. They showcase Kiro CLI with a custom agent configuration using the AI-DLC (AI Development Lifecycle) methodology to build a browser-based game called Flappy Kiro. The session emphasizes the importance of proper agent composition—selecting the right LLM, managing context windows, and configuring MCP (Model Context Protocol) servers and tools. They walk through requirements gathering, system design, and implementation phases, demonstrating how AI can facilitate cross-functional collaboration between product managers, developers, and stakeholders. The demo includes configuring custom agents with specific resources like Mermaid MCP for diagrams and the AI-DLC workflow, then using a single prompt to guide the agent through business requirements, technical specifications, and code generation. They stress that spending time upfront on requirements and design leads to better implementation outcomes, contrasting this structured approach with "vibe coding" that jumps straight to building.

; 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: Accelerating Multi-Step SDLC with Kiro

Hi everyone, and welcome to Accelerate Multi-Step SDLC with Kiro. I'm Derek, and with me is Kieran. We both work on the Developer Agents and Experiences team at AWS. We've both been on the team for the last year or so, and it's an exciting time to be in this space. We work with our agentic software development products, including Kiro, and with customers around the world who are using these products to develop software. Our team consists of former software developers who are now engaged with other software developers around the world that are adopting these products.

I'm curious—show of hands, who in the room is a software developer by profession? Okay, at least maybe half. Who has done AI-assisted coding before? Some of the same hands, some other hands. AI-assisted coding is obviously a hot topic, and these tools are getting better all the time. I think AI-assisted coding is a great start, but the conversation we're having a lot with customers is about going beyond using AI just for the build step. The question is, how do I use AI at every step in the software development lifecycle, not just the build step? That's the purpose of our talk today.

This is a coding session, so I'm going to do a little bit of talking up front and try not to do too much, but I want to set the stage for a few things. We'll talk about the software development workflow that we're going to use with agentic tooling, and we'll discuss how we compose agents, what they're made up of, how the agentic loop works, and how we can configure them in Kiro CLI. This is a very important step before we go into actually using AI for software development workflow. We'll do that up front, and then as quickly as I can, I'll hand over to Kieran, who's going to do a bunch of live coding today.

We're not just going to write code. We're going to start at the beginning of the SDLC. We're going to do requirements, we're going to do system design, we're going to make some decisions, and eventually we'll write some code. Hopefully we'll have a working game to play by the end of the session. Live AI coding is always going to be a fun time.

Beyond AI-Assisted Coding: Using AI Across the Entire Software Development Lifecycle

So just to level set, I think any of us could draw a picture of the software development lifecycle, and there are lots of different ways we could express it. If you ask different folks, they'll have different opinions about which steps there should be, in which order they should be in, and how fast you iterate on the different steps. But broadly speaking, we need to have requirements, we need to do system design, we need to plan, we need to build, we need to test, we need to package, and then we need to deploy and operate. When we talk about AI-assisted coding, we're really just talking about skipping to the code step, which can be great for prototyping or for trying something out or maybe just scratching an itch in a language that you don't know.

But when it's time to actually do professional software development, we don't want to skip steps. So the question becomes, how can we use AI for all of these steps? There are a few approaches for this. We've got two Kiro products now. We've got the Kiro IDE, which just went into GA in the last month or so, and then we also have the Kiro CLI, which we'll be using today. The approach that we're going to use for the live coding session, you could use in Kiro IDE or Kiro CLI. This is really a preference thing in terms of the user experience that you like. Kieran and I are both a bit of console enthusiasts, so we're going to invite you all to be console enthusiasts with us for Kiro CLI today.

The framework we're going to use is called AI-DLC, and we want to show one way that you can approach this. This is not the only way. Kiro IDE has spec-driven development built into it, and that's another way that you can approach using AI-powered requirements, system design, and planning. AI-DLC is another way. It's a little bit more granular than what you would see in the Kiro IDE. This is something that we've actually open-sourced and released on GitHub in the last week or two. We won't go too much into the details of AI-DLC. It's going to be in the background sort of guiding us along as we go through the steps, but we have a slide at the end that has a QR code and a link.

If you like what you see and you'd like to try out AI-DLC for yourself and some of these prompts, you're welcome to do so, and we'd love to hear your feedback. AI-DLC roughly speaking has this concept of an inception phase where we're going through the requirements, the design, and the planning, and a construction phase where we're doing the building and the packaging.

And then an operation phase. We're going to go through the inception and the construction phase today and hopefully get to a working game by the end of the hour.

Understanding Agent Composition: LLMs, Context Windows, and Tool Selection

I want to spend a few minutes on agent composition before we jump into the coding. This is a commonly accepted definition of an agent. This is Simon Willison's definition: an LLM agent runs tools in a loop to achieve a goal. The simplicity is what we like. For today's purposes, I'm going to modify that a little bit and say an LLM agent runs tools in a loop while building context to achieve a goal. I'll elaborate on that in a minute, but what we're finding is that managing the context and the tools are critically important to getting the results we want out of this agentic software development process. If we skip this step or if we don't get it right, we're not going to get the results we want. So this becomes an important step in the workflow to make sure that our agent is configured correctly.

Here's a diagram. The agentic loop is nice and simple. The user, in this case using the Kiro CLI, is going to ask it to do something as input. It's going to take that into its context. We're going to pass it to the LLM to decide what to do about our goal. The LLM is going to come back and say I want to take some action using a tool. We're going to call that tool, whatever it is. The tool is going to return a result that goes back into the context, and we go back to the agent again and say okay, we ran the tool. What would you like to do next? We'll keep iterating until the LLM decides we're done and we're ready to give a response back to the user. Let's talk about each of these parts briefly, starting with the LLM.

For today's purposes we're going to care about applied AI and not the gory details about how LLMs work. For our purposes today, I'm not going to talk about the semantic relationships that are in the model weights and dimensional vector space and all that stuff. I'm sure some of the folks in the room are experts at this stuff. What we're going to say is that an LLM gives us reasoning. We could debate how it gives us reasoning or the details, but if we ask it to reason about something, it will do that and come up with an approach for a problem. We're also not going to talk about autoregression and multi-head attention and all that stuff. What we're going to say is the model has knowledge embedded into the model weights, what we would call latent knowledge that's been trained into the model during the pre-training step. It knows stuff. How it does the recall, we'll leave for a different session, but our LLM is going to give us the ability to reason and it's going to have latent knowledge, facts that it knows about the world.

That's great, but next we need working memory for the model to be able to understand what it's doing and keep track of where we're going, and that's the context window. Here's a very simplified mental model of the context window. It's everything that's in the model's working memory. Starting with system prompts that are behind the scenes guiding the agent's behavior, any context files that we've loaded, we're going to see an example of that here in a minute. The history of our chat so far, so we've opened up our chat window and we're going back and forth working on a problem with the agent. That's all in the context window. Any source code that it's pulled up and looked at if we're working on an existing project. The output of all the tools that we've called so far. And then hopefully some free space so that we can keep going.

Managing this context window is extremely important for us to get the results we want. If I'm asking the agent to work with some custom library that I've developed and it doesn't know anything about that custom library, we're going to get a very different result than if I were to load up the documentation for that library into the context window. So we want to make sure that we get this right up front. And then finally for this section, tool selection and tool execution. MCP has taken over in the last six months or so as the de facto standard for tool use with agents. For those of you who aren't familiar, I think of MCP as the USB protocol for agents. I can take a plug, it'll plug into any agent, and it'll let me plug skills into the agent so that it learns how to do something new.

It will let me give it access to reading resources from another location that it needs, and possibly give it the ability to take action, so almost like an API where it can do a mutative or make a change on another system. Getting the MCP tools right is another critical piece of getting ready for us to do agentic software development. If we need access to Jira, if we need access to our internal wiki, if we need access to search the Internet, we need to make sure that any of these tools that we need are plugged in.

Custom Agents in Kiro CLI: Bundling Models, Context, and Tools

We talked about the agentic loop and how having the right LLM model to do reasoning is important. The right context window with content so it has that in its working memory and knows what it needs to know. We talked about having the right tools plugged in. These are all the ingredients to having the configuration that we need. So today we're going to be using Kiro CLI to do our live coding session. In Kiro CLI we have this concept of a custom agent.

A custom agent is really a bundle of all of those things that we can store, we can share with our teammates, we can publish internally if we want other teams to be able to use it, or we could just save it for ourselves. It gives us the ability to combine our model selection, what context we want in the context window, so system prompt, static resource files, hooks which give us the ability to do some dynamic context, and then tools, which MCP servers do I want to be using. Within each MCP server that could be exposing multiple tools, which ones do I want to allow the agent to use? Maybe not all of them. I can alias them if I want to give them different names.

All of this goes into one file, which Karen will show us here in a minute, that lets us build our custom agent. We're going to do that first. Karen's going to walk us through building your custom agent, and then we'll come back briefly and talk about what we're going to build. So with that, Karen, over to you.

Configuring the Custom Agent: MCP Servers, Tools, and AI-DLC Resources

Thanks everyone. I'll do the Not sure that's worked yet. The joys of a live demo. Yeah, good fun. They will. I saw a flicker. Yeah, I worked 2 seconds before we started as well. Do you want me to unplug and plug it again? Yeah. Hey, there we go, reboot, yeah.

All right, so the first thing we're going to do today is configure the custom agent so you can see exactly what Derek was talking about on those slides. Diving right in, I'm just going to go straight into Kiro CLI. And as Derek mentioned, we have an IDE that you can use as well, but for the purposes of this, we're going to use Kiro CLI. The first thing we're going to do is configure our custom agent before we actually go ahead and build the game.

In order to do that, I'm going to go agent and list out the agents that we've got. When you first start off, you have a Kiro default agent, you can see they're in green. And then I've got a flappy-kiro-agent here that I built specifically for this demo. But if you want to build your own, you just go agent and then create, give it a name, and we're going to call this demo-agent-1. Now, this is your agent configuration file. This one's empty. I'll show you the populated one in just a second. But this is where you will configure all those things Derek told you about: your MCP servers, the tools that your MCP servers have access to, and we should have called out the acronym. MCP stands for Model Context Protocol. The tool aliases, as Derek mentioned, in case you want to give those differentiating names, the tools that your agents are allowed to use, and the different resources.

What we'll do is we'll quit out of here and show you what that looks like. I've got the prompt saved here. I thought I had it. There we go. Sorry about that.

For this particular agent, we have a couple of MCP servers configured. I have a Mermaid MCP server that will help us build diagrams for the requirements and business requirements, as well as the implementation plan. I have a fetch MCP server to retrieve things from the internet. When we build the Flappy Kiro game, I wanted to be able to fetch AWS services from the internet and use that instead of a normal Flappy Bird game, making it more interesting with a Halloween and Vegas type theme. I have some tools loaded here as well, including read and write tools. The reason for not putting all the tools that the MCP server has access to is that, as Derek mentioned, you only have a certain amount of space in your context window. You don't want to overwhelm the agent with tools it doesn't need, so I've locked it down to just specific tools for this purpose.

Under the resources, I have the AIDLC workflow. As we mentioned, we'll link that in a QR code towards the end of the presentation, but it will give you a list of all the different components of the AIDLC and all the different questions and answers and how it all works throughout. I've told the agent to be able to access that as well for the purposes of building this out. Then we have hooks, which as we mentioned earlier, is something for the agent to take action on. It's really good for CICD pipeline type things that you might be doing. We're not going to do anything with that here; we're just going to focus on using the MCP servers and the AIDLC and the resources configured with that.

With that, I'm going to switch to my agent. We're going to select that one, and that's going to give us the agent that we're going to use to actually build out the game. Thanks Karen, and just to emphasize, this is a relatively simple thing to configure, but by pulling in those resource files, we're going to dramatically alter the behavior of the agent as you'll see in a minute here from what we would get by default. There's a lot of power under the hood that we can have here by developing custom workflows and specific ways that we want the agent to work. That's something that teams can work together on and refine over time, and we're seeing libraries of these emerge within customers as the different teams build their own repository internally just to refine these files and get them better and better over time. There's a lot that you can do here by just loading in a few context files and a few tools.

Building Flappy Kiro: Setting Up the Project with a Single Prompt

We're going to spend the rest of the time here building, and the goal is to build a game called Flappy Kiro by the end of the session. We'll see how it goes. It's live, so we have some backup plans in case we have any problems, but I'll try not to jinx us here. Flappy Kiro is a game where Kiro, the ghost—we decided his name is Ghosty—will be able to scroll through a side-scrolling game. When we push the space bar, he'll flap up in the air. When we let go of the space bar, he'll drop down, and he's got to avoid obstacles and get a score. The point here is less about the implementation details that we pick, what language we use, or hopefully whether the game actually works and whether it's good or not. What we really want to do is focus on the workflow and how we can use AI from the very beginning to help us get our requirements, our design, our thinking about our plan, our testing, and everything that we need to do in order to build production-grade software.

While we're not building production-grade software today and we're going to speed through some of the steps, I hope that you walk away today maybe inspired to go try some of these techniques yourselves. Try doing an end-to-end task or story from your backlog using this process and using AI from the very beginning of your project. So, is there anything else I should do to set up Flappy Kiro here? I think it's a pretty straightforward game, and we'll get into some of the details. We're going to try and get it to work on here as well as on a mobile phone, so we'll switch to the development tools and see if it works on a mobile, but we'll try and get it to work first and then go from there.

Let's see how we get on. Great, it did work. So to build this, we're going to use just one prompt. This is the prompt I'm going to use, and I'm going to spend a little bit of time going through it. The goal is not to do any prompt engineering or have any secret source baked into this. We're going to have one clear prompt, and then we're going to go through the AIDLC.

Which has been shortened to fit into the session today. The first thing we're going to do is use the latent knowledge that the LLM has from its training. The LLM is aware of a lot of this and can make many assumptions based on this, but we still want to guide it with proper requirements—business requirements, functional requirements, non-functional requirements, and implementation plans.

I'm going to say I want to build a browser-based game called Flappy Hero for a live demo at AWS re:Invent. We're going to follow the AIDLC methodology and workflow, and we're going to ask the LLM to ask us clarifying questions so that it can then provide the answers as inputs for each phase. I want to show you some Mermaid diagrams. When it actually builds out the file structure and the implementation plan, you can see what that looks like. If you look in the IDE, it actually gives you a really good visual of that. Because we're doing this in the CLI, I'm just going to use a Mermaid webpage that we have, and we'll show you all the architecture diagrams that it creates.

We've streamlined the process to fit into the session today. When we run this with our customers, it's usually a one-day workshop, sometimes two. But we're going to get this to work in forty-five minutes. We're going to maintain interactive questions and answering throughout the process, and we want to save the files in the working directory so it doesn't put them everywhere. I'm being quite specific with it, but we're still going to do quite a bit of guidance and give it themes and everything like that.

Are there any questions as you go? The question was whether we're taking questions as we go. I think while the agent is thinking, we'll have some time. Yes, especially through the build phase, it takes a good five to seven minutes, so we can take some time then. Okay, so we're going to go ahead and execute this. Fingers crossed.

Analysis Phase: Gathering Business Requirements Through Interactive Questions

The first stage is going to be the analysis phase where we're going to gather all the requirements. In the real world, this will be your business requirements that you might have within your organization. I give this agent permission to do that. It will be things like what sort of third-party systems you need to use, what sort of logging or anything like that you might have, and if you have any security postures that you need to follow, things like that. That will be part of your business requirements.

Here we go. It's created a file. Let me make this bigger. If anyone has any suggestions, we can take them as we go through this. Otherwise, it will just be me filling these out as we go along. As Derek mentioned, each time we run this, we get a slightly different result, so it's not always the same. The questions do come back a bit different, but when you use the full AIDLC, you get very specific and then you tend to get the correct response.

Just to elaborate, I think what we find is that the frontier models, the LLMs, they're eager to please. When we're doing something like vibe coding, often the model will take what you've asked it to do and start running with it and start building stuff rather than stepping back and thinking critically like a senior engineer might. A senior engineer might step back and say, "Hey, before we build this, I've got like fifteen questions about security. Did you think about this? What about this edge case?" That's the kind of conversation that we want to be having. What we've got loaded into the context here is a lot of specific instructions saying, "Hey, don't skip any of these steps. If we don't know the answer yet, let's get the answer before we keep moving."

The first step here is where we've told the agent, "Hey, I want to build this thing," and it responds with, "Okay, I've got a bunch of questions. Please answer those for me before we continue." We'll fill those out here, but it should keep asking us until it's clear. Exactly. These questions are predefined ones. This isn't like a final list. If you have something when you're doing this for an enterprise app, you can go and actually put those in there. If there's a question you feel hasn't met your organization's needs, that's something you can just insert in there too. It doesn't have to be the predefined list, and it won't freak out. I'll show you an example of that.

The way I answer these questions, I'm supposed to fill them in down here. I'm just going to say yes or no, and then for this one, I'll fill them all in down here for question two, and we'll go through it like that and see how the agent deals with that. For the first question, we want it to continuously fly or only when clicking or pressing the spacebar. I'll say press a button to fly, and then for easy or difficult, I'll say easy or medium.

Easy has larger obstacle gaps. Getting harder as the game progresses. Should the game speed increase over time? I'll give that a flat yes. This takes quite a bit of time when you're building out an enterprise app, but hopefully we'll get through this quite quickly.

So then we get to the visual side of things too. What I want to do is change this a little bit. We're going to use some of the AWS colors. I'll go with orange and black. I'll go with a Halloween theme since it was recently Halloween, and a Las Vegas theme as well. Let's see how it deals with that. There are a lot of typos today. Do you want the Kiro character to be a simple shape, bright, or custom design? Kiro is a ghost, so we're going to use a purple ghost character.

Should the obstacles be classic? Obviously, it's got that latent knowledge and knows exactly what that game is. So let's go with AWS themed obstacles. It's got that from the prompt we did with saying that we're doing an AWS re:Invent presentation, and then we want to use AI and coding services from AWS. There we go. For scoring and leaderboard, what kind of scoring features would you like? I'll take suggestions if you want to shout them out, otherwise I'll just fill these in. We'll go with simple score for now, and then here we're just going to use local storage since we don't have anything like that configured.

In the real world, obviously, if you're using an API Gateway, you can use something like CloudFront if you want this game to be globally available and closer to your customers in different regions. That's something you'd specify, but for the purposes of this, we're going to do this. We'll say yes to that. How long do you want it to be? I'll just go one to two minutes. I'll say yes to that, and on a mobile phone, test that towards the end. I like the ambition level here. You're adding a lot of features. HTML and JavaScript, let's use those two for the purpose of this.

Single file or multiple files? I think we'll use multiple files because I want to have proper structure for this. That way, if we need to go back and change something or we want to document any of these decisions and come back and ask why we did that, it's all nicely documented. So we'll go with multiple files. It's pretty good at picking up all my bad typos. Any AWS services you want to showcase? Should we do Amplify? I can do that. Let's see what it does there, and I'll put maybe Bedrock since it's going to be running on that.

Let's try those. For start screen instructions, I would just suggest yes with easy, medium, and hard. Maybe just make a note that we need a way to test locally since we're not going to have time to deploy to an AWS environment. Cool. Alright, restart button, I'll just say yes and then we'll move on to the next phase. Mobile support, or support for mobile browsers, I think. Maybe we want to use Chrome and Firefox. I think those are the two most commonly used ones. Okay, great. And that's it. So we'll go ahead and save that. Close that up and then we can say done.

Design Phase: Defining Technical Requirements and System Architecture

We're still using that single prompt, and it should now go ahead and read those answers and start building out the design phase. The whole purpose of this is we're bringing the agent and the LLM into the decision-making process, which saves a lot of time. We were just doing a lot of what I would call classic product manager work and less software development, but it's very important.

One thing we're finding is that getting together cross-functional teams that might not work together next to each other day by day, but getting the product managers and the stakeholders along with the software developers, maybe QA and ops—getting that cross-functional team that's going to be responsible for this thing, sometimes physically together or at least on the same call and working together on answering these questions can help teams get this right up front and skip a lot of back and forth that we might traditionally do where we need to email or cut a ticket to someone to find out information. If we're able to do this collaboratively up front, we can dramatically cut down on the time needed for us to get all of this right. The agent in this case is really our helper to make sure that we're documenting it properly.

Now we've moved on from what to build and we're going on to how we're actually going to build that. We've taken some of the suggestions of SageMaker, Amplify, and Bedrock, and now it's going to come through and ask us how we're going to do these. These are now your more technical requirements. We've defined the business requirements in the first phase, and we're moving on to more of the technical stuff right now.

Earlier on in here, using that agent that we configured, we told it to have the Mermaid MCP server, and it's gone in and actually built out some Mermaid diagrams for us. It's already documented and drawn out what it thinks this is going to look like. Do you remember that one prompt about whether you want everything in a single file or split it up? It's gone ahead and split that up for us as well, with specific files for different things. We have JavaScript files and HTML files, so you can go there and make changes later.

If we look over here, it shows you the different components that we've got. It's showing you the different layers it's going to build out and how that's going to look. We find this really useful. Our customers have told us that this saves a lot of time with the documentation and how that's going to look, and they can use that for all their different change controls and when they're submitting tickets to have this all built out.

We're getting all of that. You remember I said local storage only—we're not going to deploy that to anything else, so that's done over there. We already talked about how we're going to do the obstacles, it's gone and filled all that in. The scoring, I said do that as we pass the obstacles, and the difficulty controller from easy, medium, and hard. So all of that's already in there.

Let's go back in and fill out the rest of that for the technical requirements. The first question it's got is which AI coding services should appear as obstacles. I'm just going to say use all and use them randomly. How should the difficulty levels differ? When I've been building this out and testing this, I found that the gravity is way too strong, so the board just falls like a stone no matter how quickly I press the spacebar. The gaps are way too short, so I can never get past the first couple of hurdles.

I might go in here from my previous knowledge and tell it to be a little bit better with that. I'll say start slower, larger gaps, and less gravity. I want to use 60 frames per second. Now we've got the visuals, so shall I generate a simple CSS canvas, or do we have any image assets?

I'll start with a normal simple CSS canvas, but then you can go back in, download specific assets or any audio images that you've got for the game, and you can put that in. It does a pretty good job of filling in and coming up with stuff itself. So we'll go with CSS.

Then for ghost animation, do you want a static, bobbing, or flapping wings? Let's animate the ghost. When it was flying, let's use official AWS icons. I don't think it's going to be able to do that unless we actually give it to them, but it's going to try and draw them up and then typically it uses emojis or something like that too.

For sound effects, I'll just say use suggested effects just in the interest of time. And then this question here about Bedrock integration: how should Amazon Bedrock be integrated? Dynamically, AI-powered difficulty adjustments, generate. What do you think? This is quite interesting. I think those are all future enhancements, right? So it probably doesn't matter for this demo.

Here's the file structure that it's going to create for you. Instead of creating that one big file, it's going to break these down for you in the different files that you're going to use, and that means you can come back in and put in your own images and your own sounds when you want it to do so.

We're almost speed running through the steps and vibe coding in a way by not engaging more here and doing a much richer discussion in the interest of time. But you can imagine this is where the interesting work is going to happen, around these decisions that we're making around technology selection and what should we do first and what's a P0 versus a P1 feature and what our architecture is going to look like.

This is where we as humans should be spending our time, and if we get this right up front, the actual implementation phase is almost the easy part hopefully because we've already done all of this hard work up front. So if you're not already, I would encourage you, if you try AI DLC, spend a good amount of time up front in these phases, get this as refined as you can, and then see how the implementation step works out for you.

Did you get to do this in phases just by saying I wanted AI DLC? Yeah, so we'll link at the end to the GitHub repo, but our teams have put a good amount of work over the last few months working with lots of different customers to refine this. We're using conditional context loading because we have a finite amount of context window space.

There's an initial context file that we loaded that kicks off things with the agent and tells it, hey, you're using this workflow, you're going to use these very specific steps. Then depending on what you're doing, if you're doing greenfield or if you're extending an existing application, if you want to do microservices, there's a bunch of decision trees that it'll make and say, oh, we're using a, we're going to extend the legacy application. It'll actually load in additional instruction sets to make sure that we're doing things in an orderly way. So there's a lot behind the scenes here that's getting loaded in as needed.

There's just the one markdown file as the entry point and it has instructions that says conditionally load these other files depending on what you're doing. We found that approach works well to keep the context window not too busy. And then to your point, the other thing you can do is you can have different agents for different phases of your development as well. So if you're doing front-end development, back-end development, you can have different agents with different MCP servers, different resources, and that way you can do, and they can just switch between those agents as easily as I showed you there. That's a good way of getting a project done without loading everything up.

Implementation Phase: Generating Code and Building the Game

So now this is the part where we move to the actual implementation phase. We still haven't written any code yet, but now we're going to have it start cutting code.

Now we're going to have this create Jira tickets for you, and you can have your junior developers go ahead and run this based on the architecture diagrams that your senior developers or Kiro has built for you. We're just going to go through this real quick and see what we can get from all of it. So approved to implement. We're just going to go through the resolution size and link all the modules together. If you have any specific styling that your organization might use, this is a good place where you can do that if you're building an enterprise app. If there's anything you'd be sitting with different teams across your business, going through all of this and figuring out if this is the right thing to do. If it's not captured in here, you can obviously add it in there and change some of those files as well. We'll go through that as well.

We are going to use JavaScript and HTML. I think we decided that was going to be the best thing, so we're just going to go ahead with that. It's just asking for that final verification before we do anything. Are there any Jira MCPs or integrations? Yes, there is a Jira MCP and I was just thinking the same thing. Like once you get to this step in the real world, each of these might be more complicated and take more time. So you can imagine each of these becoming a story that goes on to the Jira board and gets pulled down for sure, and that could be as simple as us taking this file and saying go create Jira stories for each of these. I'll be honest, this is different from the other ones that I've done before. Normally it's another bunch of questions, but here it's just basically saying you've provided me enough and just give me the verification for that. So just answering yes. We'll have a look at this diagram that it's given us. This should be the implementation diagram. I didn't grab everything there for some reason. I thought I had it all. Yeah, I did. Didn't like that. Okay, try it once more. I suggest Karen, in the interest of time that we, yeah, we are running short, keep going.

You can see when it gets to this part, the agent's already thinking about how it's going to generate the testing, so it's going to have functional testing and any sort of unit testing and stuff you might want to do for your code. It'll generate that in the next phase too, but it's already thinking ahead about how am I going to test this end to end. This is quite something. Obviously the different, I've said to it use Firefox and Chrome because it's going to go on mobile phones. It's figured that some people are going to have iPhones and it's put Safari in there as well, which is great. Chrome mobile, Chrome desktop, so we'll go ahead and save that. Now it's going to go ahead and create all the different files for us to actually build the project up. And there we go. It's going to create the assets file, the CSS files, the JavaScript files, and hopefully we'll get a working project again.

This is where it takes a few minutes, five to seven minutes if it works, and we spent a lot of time on requirements, design, technology selection, not coding, right? We've got sixteen minutes left in the hour. We'll see how we get on, but again, this is sort of the almost the opposite of vibe coding and starting with build. This was really the thing that we wanted to impart is it's time well spent doing this upfront. AIDLC is one framework. Again, there are other approaches. You could build something yourself. You might consider forking what we've got if you're interested. In fact, send us a merge request if you find a way to improve on the process. But the idea is to have a plan going into the process.

Discussion: Iterative Development, Context Management, and Accessibility Considerations

Yeah, I'm working in a similar way process, but my struggle with that is it's always very linear, so you've had everything, all the details. I feel some of the questions we have seen seem relevant at this point in time we don't really care. And then when it starts building, you realize oh wait a second, actually I want to change my mind and change things, and it's very difficult to go back because you're forcing not only the model but also yourself in this linear process. Do you have any experience with that? It's more like looking for a more iterative development, like build a very simple first version or whatever, and then I'll extend it when I've seen it.

To summarize the question, this process has been linear, where we do all these steps in order. In reality, in real life, we might start implementing phase one and say, actually, I changed my mind. I want to tweak the requirements. You certainly can go back to one of the previous stages, edit the requirements, and then ask the tool to update the design, for example. I don't think I have any real shortcuts for that. I think we've got to pay the price at some point. If we want to change the requirements, we're going to have to go through those steps again.

I think that by getting the right people in the room upfront, we can hopefully minimize that back and forth in terms of what the requirements should be. In terms of iterating on the design and the implementation, one of the benefits is we can move pretty quickly here. The iteration step, whereas in previous lives that might be like a whole sprint that we just used to build something and we'd have to start over again, we could potentially make that cycle time quite a bit shorter. But I don't have a way around needing to go back. It's more like the context is blown up, et cetera. If I want to go back, I'd rather build an MVP thing of this game, document what you did, then I'll look at it, change my mind, and then review everything that we have specified so far and maybe change the specification. So it's like a cycle process.

Yeah, you start with fresh context just with the key learnings from cycle one going into cycle two with more space in the context and starting from there. So just to repeat the question, the question is about being able to save the context and go back and edit it later, and be able to iterate based on what we've learned so far. We're writing all of the design decisions into markdown files, all of the Q&A and all of the descriptions of the requirements and design and such. There's also an audit log that automatically gets written of all the questions and decisions that were made.

One thing that we've seen is just taking all of these files and attaching them back into the JIRA tickets. So anybody that wants to go back and understand why we made this decision or what was used as input here, we can go back and reproduce it. We've also seen that the context window can get full, so in between each of these steps, we've actually cleared the context and then started fresh again. That kind of proves to ourselves that everything that's needed to reproduce what we've got is stored in these markdown files. Yes, and that's in our custom agent. And then so in theory, we should be able to go back to any step at any time, use one of these as artifacts, make a tweak, and move forward from there.

How is this different from using Cora IDE? Because I use it and it follows very similar phases where I believe we have the design, requirements, and tasks, and here you have analysis, design, and implementation. Do you think one is more powerful than the other, or depending on if you did your own custom agent, would this be more powerful than the spec? The question was which is sort of the better approach. Cora IDE has spec-driven development. We're doing this AIDLC workflow in the CLI. They have similar bits of functionality. We're moving fast in all of this. The IDE, I would say, spec-driven development is less customizable at this point, but you're going to kind of get what you get. For a lot of customers, they really like it and they're using it. This is much more configurable.

This AIDLC approach or an approach like this gives you the ability to tailor this process with your developer development teams over time and make it as granular and specific as you want—always do it this way, don't do it that way. In return, the process is more complicated, right? It's going to take more time. We're skipping a bunch of steps. If we were going through the full thing and we hadn't told that we were doing a demo, it would be documenting tons of user stories and asking what persona should we be doing, and so it'll go a lot deeper than this. So I would suggest that maybe as a starting point or for features that are a little bit more straightforward.

But I don't want to say straightforward. Kiro ID is a good starting point, but if you're looking for more ability to customize or the ability to get a few levels deeper into the requirements, I would suggest that this is a good approach. I also think that you'll see over time we'll continue to build out that spec-driven workflow in the IDE, and that'll get more and more features as well.

How are we doing here? It built actually quite quickly. There was no contention on Bedrock. I think we're good there. So yeah, I have to see if it works. Yeah, so it did build us an implementation plan, and then let me close that down and bring up the other one. So yeah, we got all the coding complete. You get a full report of everything that was done, how much code was written, all the features that were implemented, the stuff that we walked through in the beginning. And yeah, it tells you how to test it, and it also gives you a whole testing plan as well. This is quite a basic one, obviously, but you can obviously imagine what it'll produce when you do a proper document.

So yeah, with that, let's see what happens. I think it's just this file here, we can go. So there we go. We got the start screen. Looks all right so far. This is the worst part. I go easy. There we go. Actually it wasn't too bad. OK, nice. The Bedrock thing wasn't as impressive as I thought. I think that's a Pac-Man ghost. Yeah, it doesn't actually look like a thing, but it's picking up scores and I don't know if there's any sound on here. There's no, I think we said no sound. Yeah, they said no sound, but there should have been. I can unplug my Mac in a sec. Oh no, I mean when we set up the stage we said no sound. That was our mistake. That's actually better than I thought.

A lot of them just didn't work. It just plunked like a stone, but yeah, cool, nice. We've got eight minutes. I'm happy to take more questions and discussion about the process. I'm also happy to take modification requests to the game if we want to try that. Yes, I will put that up right at the end here. I'll do some crowd work here. So our team recently did a test where we went full hero and just had it kind of go crazy and make a whole web app. My issue with it was that a lot of it was inaccessible and had windows to open things and things like that, and I'm just wondering what recommendations you have. Like, is it adding a front-end MCP to the front of it? Like what would you recommend to help make sure it followed accessibility guidelines?

So you're talking about accessibility like WCAG, OK. How specific were you at the beginning about your accessibility requirements and what was must-have versus nice-to-have? I'm not sure I have delegated that. I got it. So I think that would be my answer, right? The more time we spend up front, again, if this is a web app, talking to the UX folks, the stakeholders, the product managers, getting really into the weeds on what are the non-negotiables for accessibility, and if we can get all of that decided up front and documented into one of these markdown files, I would expect that we would get better results there.

Is there a way to integrate WCAG guidelines more easily, like as a base, because there's actual specs and whatnot? Yeah, so one thing is, as you're developing your version of this for your teams, again you could imagine having a repo of these context files and a custom agent that you publish for the teams and say, "Hey, use this when you're building a web app." In that custom agent in the context, you could say the following are kind of company standards for accessibility. Thou shalt make sure that you hit these versions of WCAG requirements. The model is going to have a pretty good understanding of those requirements baked into its latent knowledge, but if you wanted to really make sure that you nailed it, you could say, "Hey, I'm guessing I would be willing to wager that there's a WCAG MCP server where you can go and grab the actual spec." So that would come at the cost of more context that you'd have to load, but you could imagine saying, "Hey, as part of our verification, I want you to make sure that you've built all of this in and actually go test it." So I think you get as sophisticated as you wanted to, and I would suggest starting by adding that up front into the context and having it build that in.

Q&A: Standardization, Model Selection, and Kiro's Differentiation

Thanks. You have one over here. Go. I work as a manager of a developer experience team in our company and we have like 300 engineers as a whole.

One of the difficulties we have is how we standardize AI knowledge because people like to use Kiro, some like to use Cursor, Cloud Code, or whatever. When I look at this, it's kind of concentrated on Kiro, or how is the difference with something like Agents.md, for example? That's a standardization independent of the tools. That's a little bit of my question here: how can we make that reusable instead of tied to the tool that a developer is choosing? Probably it would make it easier to adopt.

We're seeing a lot of innovation in all of the tools in this space, so things are moving fast. Agents.md seems to be a de facto standard that's emerging, which is good. The different tools have different ways for specifying this concept of custom agents. The AIDLC is just a bunch of markdown files, so it would work fine in Claude Code or Cursor or what have you. This isn't meant to be specifically tied to Kiro. We think that Kiro is a great platform for doing this, but we're not trying to lock it down to one particular tool.

Ideally, you're able to bundle together the AIDLC or the context files that you have that you want to steer the behavior of the model, as well as your list of MCP servers, together and have a way to publish that out to other folks in your organization. With Kiro CLI, that's just a JSON file. So all that could be is an internal repository where you say, "If you're building web apps, use this custom agent. If you're extending this old legacy app, go use this agent." That combined collective wisdom of how to operate around those different domains is baked into those agents.

First of all, thank you for that great presentation. When you have these different stages in the AIDLC and in the agent definition, there was this line where the model was null. So you leave the selection of the model to use to the automatic or would you suggest using different models for different tasks and stages in the AIDLC?

Thanks for the question. By default, we now have an auto mode in Kiro, and that's going to allow us to select the model and give you a discount in terms of credits. Our goal with the engineering team, and they're spending a lot of energy on this, is making that auto mode work great so that you as a user would never have a reason to change the model because you're very happy with the outcome.

So that would be our recommendation: start with the auto mode and hopefully you get great results. If you're not sure you're getting great results and you want to say, "No, I definitely want Claude 3.5 Sonnet or whatever the latest model of the day is," you could switch to that and see if you get different results. But our hope and expectation is that you can start with just not defining the model and use the default auto mode.

First of all, thank you so much for the presentation, the demo, and I just tried the Kiro app and also the CLI as well. They both work really fast. I really like the product. But the thing is, I know a lot of independent developers who try so many AI coding agents like Cursor and Cloud Code. So actually, I want to get more insight into how Kiro differentiates from those other coding agents. For example, are we going to have more integration on AWS or do some more integration work on enterprise integration?

In terms of differentiation, we want Kiro to be a great product regardless of where you're developing, even if it's not on AWS. So our intention is to just focus on a great developer experience. Of course, we want it to be really good at AWS as well. That's the thinking. There are a lot of smart folks building other cool tools in this space. I think it's a good time for end users because that competition is having folks leapfrog each other in capabilities. I expect that's going to continue to happen.

I'd say one nice thing about Kiro is that when you subscribe, you have access to both the CLI and the IDE for one subscription. We see a lot of folks that like to switch back and forth between those modes or maybe even use both at once. So I think that's a nice thing. I would say the spec-driven development in the IDE, which we didn't look at today, has received a lot of great feedback. That's a good way for developers to structure their approach.

So I would encourage you, if you haven't already, to try both. Try the spec-driven workflow in Kiro IDE and try the AIDLC, which is a bit more in depth, and see which one suits you best. That's a very brief answer to your question, but I know we're right at time. Thank you all.

---

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