AWS re:Invent 2025 - Teaching your AI tools custom languages and libraries (DVT341)

🦄 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 - Teaching your AI tools custom languages and libraries (DVT341)

In this video, Brian Beach, tech lead for AWS Next Gen Developer Experience, demonstrates how to teach AI tools like Kiro about custom languages and libraries. Using a fictional domain-specific language called MathJSON as an example, he shows a progression from complete failure to success through four demos. He explains two key Kiro features: steering files (organizational rules and standards) and Model Context Protocol (MCP) for connecting to external systems like GitHub. The demos illustrate refining documentation from 1,100 lines to 100, making steering files prescriptive, and using MCP to access real-time documentation instead of maintaining derivative copies. The approach applies to any custom organizational tools, from logging libraries to complete tech stacks.

; 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 to Kiro and the Evolution of AI-Powered Development

Hello, everyone. My name is Brian Beach. I'm the tech lead for our Next Gen Developer Experience team within AWS. I spend my time helping developers and customers who are developers with all of our developer tools, including CI/CD, infrastructure as code, and more recently, I've been spending most of my time in the agentic AI space, specifically for software development. I'm wearing a Kiro shirt and spend most of my time talking about Kiro these days.

This session today, I'm going to talk about teaching your AI tools all about your custom languages and libraries that you might have as part of your organization. Nearly every customer I work with has a series of custom tools. This might be something really simple, like a custom logging library that you're supposed to use when you write code within your organization, or it might be a whole tech stack that the large language models have never seen and are unaware of, or even to the most extreme, you've written your own domain-specific language and you need to teach your AI tool how to do that.

I'm going to walk you through how we do that with Kiro. Most of what I'm going to talk about is applicable to other tools as well, but I'm going to walk through using some of the constructs that exist in Kiro, since that's the one that I know best. We'll do this for the next very short session, only 20 minutes here. So quick agenda, I will start with just a brief introduction to Kiro. I promise to keep that really short, just two or three slides to get us going. Then I'm going to talk just a little bit about some of the tools that Kiro has for context management. Again, most of this is applicable to other tools, but I'll be demoing in Kiro. So let's talk a little bit about how that works.

Then I'm going to introduce a domain-specific language called MathJSON. This is totally fictional. I made it up, or more specifically Kiro made it up for this demo and a blog post that I put out. What we're going to do is go through a whole series of demos working with MathJSON. Being a language that we just made up, none of the large language models are trained on this. None of them know how to use it. So we're going to start from the ground up and work through a couple of iterations.

In the first demo, the baseline, Kiro will know nothing about this language and will fail spectacularly. Then we'll keep iterating and building on top of that, bringing additional constructs in to teach it how to work with this language that it's never seen before. I'm working with a domain-specific language, but everything that I'm going to talk about is applicable to you if you were just maybe doing a custom library. It doesn't have to be a whole language. All of this will make sense as we go.

So with that, let's do just a brief introduction to Kiro. Is everyone aware of Kiro? Maybe, who hasn't heard of Kiro? Okay, so Kiro is an agentic IDE that we launched a few months back. It launched in the summer and just went GA last month in mid-November. So it's very recently GA. You're going to see stuff all about it. If you go to the Venetian, we have this cool haunted house where you can do a tour and learn a little bit more about it. I'll tell you at the end how to get all the different opportunities to learn more about Kiro.

So let's do just a quick history. This is my third year doing some version of this talk. I did this back in 2023 about CodeWhisperer and talked about how to customize CodeWhisperer. If you've seen CodeWhisperer, it predicted the rest of the line you were typing or the next couple of lines, helping you as a developer develop code a little bit faster. We've come a long way since then.

Then last year I did this talk about Amazon Q Developer, and when we got to Q, it was much more about chat. We had evolved a lot, and I could go in and have conversations about the architecture and ask it to write code on my behalf and have it do quite a bit more work than it used to be able to do. Now, 2025, this year, I'm sure you know, is all about agents. We've really embraced this agentic approach where we can use some of these larger models that have reasoning capability and are goal-seeking. I can say, "I want to accomplish this," and let Kiro take over all the work of going through the architecture and then writing the code to implement that, really broadening the scope of what's possible.

And so as we move into this agentic era, what would the development experience look like if we could take full advantage of those agents? That's what we're bringing to you with Kiro. That's what Kiro is, right? Kiro takes all the way from prototype to production, going all the way from the design phase all the way through software development into deployment. I know that's really quick, we'll see it in action in a minute, but I want to talk about just a couple of basic features to give you a sense of the capabilities that we're going to use today.

Context Management Tools: MCP and Steering for Custom Language Support

There's a bunch more that I'm not talking about that Kiro can do that you'll learn about in other sessions, but there's a few things you need to understand for the demos that I'm going to do here today. All of this is about how you manage the context. What does Kiro know about your environment? And there's two tools that we're going to use for this. The first is MCP.

Which stands for Model Context Protocol. I assume everyone is familiar with MCP. This is what gives your agent access to additional information that it doesn't know and allows it to act on the environment around it. The second tool we're going to bring in is what Kiro calls steering. Steering is just the set of rules that are unique to me—how I want it to act. I'm providing it the rules necessary to steer it in the direction that is meaningful to me.

To give you a better sense of what that looks like, this is an example of an agent steering file in Kiro. You can see this is a set of Python coding standards. This is what I think good looks like. I don't need to teach Kiro how to write Python, but I need to teach it the way I want it to write Python. The two things I'm telling it to do here are: for documentation, I always want docstrings. That might be my organizational standard or just my preference, but I always want to see docstrings in all the code that you write. I also like to see type hints. I want to see everything typed. I put that in, and now Kiro will see these. This gets injected—if you see at the top that wildcard—anytime I'm working on a Python file, these rules get injected into the context automatically, and then Kiro knows that it needs to go do these things. This is called steering. We'll use this later to teach it about a custom language that it's never seen before.

The other tool that we're going to use is MCP, the Model Context Protocol. This is what connects me into external systems. You can see here I'm connected to two things. I've got a GitHub connector in MCP and I've got my Postgres database connected. You can see that this MCP server provides me two tools. One is to run a query and the other is to get table schema. If I'm asking Kiro to write queries for me, it's going to need to understand what my database schema looks like. This is probably something it was never trained on because this is unique to me. Now I can go and discover that in real time, and this makes it much more effective. Letting it run queries allows it to go and execute some of these and say, "Hey, is this right? Is this syntactically correct?" I can now test it and see if I'm getting back what I expect.

We're going to use these two things together in concert in a minute to teach Kiro about MathJSON. Before we do that, before we jump into demos, let's do a quick introduction to MathJSON. MathJSON, as the name suggests, is a JSON syntax for writing math equations. It can handle simple things like adding and subtracting. It can also do more complicated things that we're not going to get to today, like trigonometry and logarithms and so on. It uses a file extension called .math, but it's written in JSON syntax. This is completely fictitious. I am in no way suggesting that anyone should use MathJSON. We made this up just as a proxy to what I see so many customers doing. So many customers have custom vocabularies in XML or JSON syntax that these models know nothing about. You use them for workflows or to describe business logic and business rules. This is a way that you can teach it. That's all that this is meant to be—a proxy to the things that you have in your organizations. I don't want you to actually use this.

Here's an example of what MathJSON looks like. It's just a JSON syntax. This is the formula for calculating the area of a circle given an input radius, marked up as this fictitious JSON language. I keep this in a GitHub repository. Note at the top—this is a private repository. So the models have never been trained on this. They are unaware that MathJSON exists or how to work with it. Notice there's a whole bunch of documentation available here. If I brought in a new hire, I would point them here and say, "Go read through all the documentation so that you understand the function reference and you know what's available. You know how to use environment variables, you know how to troubleshoot." All of that's well documented. I have to onboard the agent the same way that I onboard a new hire in my organization.

Teaching Kiro MathJSON: From Baseline Failure to Successful Implementation

With that quick foundation, let's look at a couple of demos to get a sense of what this looks like. I'm going to start with a baseline, and this is not going to work. I haven't done anything yet; I haven't taught it anything. I'm in Kiro here. Hopefully that's big enough to see. In the bottom right corner, I'm asking Kiro to create a function to look at mortgage overpayment. How much savings am I going to have over the life of a loan if I overpay on my mortgage? Let's let that happen. You see Kiro starts thinking about that and says, "Okay, let me work on this." You see right away that it starts writing a Python function. Over here on the—I just need to make this a little bigger so I can see what I'm doing here. But you see over there, it starts building this mortgage calculator Python function, which is of course not what I want. I want it to do this in MathJSON, but it doesn't know that MathJSON exists. It does an excellent job, by the way, of doing this in Python. It's really well-documented code. You can see over on the right, it also tested it.

I executed it a few times to make sure it's working correctly, but it's not what I wanted. I need to go and teach it about the things that I want.

After our first demo, the issue is obvious: Kiro has no awareness of MathJSON. It doesn't know that it exists. So the first thing I'm going to do is use steering. These are the rules that can guide and steer Kiro about how I want it to work. The simple, naive approach is to grab one of the documents I had—in this case, the function reference—which teaches it how to use all the different function types, and just stick it in steering.

You can see over on the left side that I stuck that into steering. If we come in here, you can see this is the documentation I brought down from GitHub. It's easier to see this if we go into preview. You can see it walks through how to do arithmetic, gives me the prototype, provides a couple of examples of simple and more complex operations, moves into subtraction, and if we kept scrolling, we'd go through all the different math types that are supported.

Let me go through and ask the same question again: "Give me a function to model mortgage overpayment." You can see that Kiro was once again doing Python, right, despite the fact that I gave it the MathJSON document. It's doing Python while it's working. I just want to give you a sense of the scope of this. If we scroll down, there's about 1,100 lines of documentation in just one of the dozen files that were available on GitHub. I've given it all of this, but it's still not doing what I want. It's still writing a Python function.

I could come in here and simply change my prompt ever so slightly to say "Using MathJSON." I ask it again, and this time it will start to do the right thing. It's building a JSON file this time, which should have a .math extension. We covered that, but it doesn't know that yet because I didn't tell it. But it's getting the beginnings of this. However, I had to tell it what to do. I had to be prescriptive in my prompt and say "I want you to do this with MathJSON."

So what happened? We were on the second of four demos. What was the issue here? First, I was not prescriptive enough. I gave it documentation for the function reference that told it what it could do, but I didn't tell it what I expected it to do. I didn't tell it when to use MathJSON. It also didn't use the correct file extension because that's not covered in that piece of documentation. Additionally, the docs are very repetitive. If you go through there, that doc was written for a human, and it just gives me examples over and over again—the same information for add, subtract, multiply, and divide. It's super redundant, and I'm dumping a lot of stuff into the context that I probably don't need.

So the next thing I want to do is continue to iterate. I'm going to refine that steering document a little bit. We're back to about 1,100 lines of documentation, and I'm simply going to ask Kiro to refine this. There's this nice Refine button up here, and when I click that, what I'm asking Kiro to do is go read through all this documentation and essentially refine it down to what it actually needs. What do you think you need out of this? This is going to be a theme here. I'm going to keep asking Kiro to do things rather than trying to do them myself. Let it make decisions about what it needs to do. The models are getting really smart.

I sped this one up. This is a pretty complex ask, and it takes about 90 seconds to go through and analyze this doc and figure out how to refine it down. Note that sometimes when you refine it, it will actually expand the document. If you have a really terse, simple statement, it will make some assumptions and expand it, and you can look it over. But generally, it's going to make it smaller. You can see here now it went through and really refined what was 1,100 lines down to just about 100. So it got it down to about 10 percent of its original size. If you looked at those examples, it gave me one example of how to write the syntax and how to nest things. It didn't repeat that for every type because it's the same over and over again. So it did, in my opinion, a pretty good job of refining this down. I haven't been prescriptive yet, though. I've shrunk it, but I haven't added that prescriptive element.

So let's go in and do that too. I'm just going to take off this header, and what I want to do now is paste in this much more descriptive statement that says "Hey, this project uses MathJSON." This is when to use it: "You must use MathJSON anytime you're doing math." I also tell it about the linters and how to run them, how to actually execute these so you can test, so that like it did in Python, it can actually go and test this and make sure that it's working right. Now I'll come back in and start a new fresh prompt.

I'm going to come back to that same question I've been asking repeatedly about writing a function to model mortgage overpayment. You can see right away that it finally got the extension right. It's nailing it, and I didn't have to go in and be explicit about saying "Using MathJSON." It knows that it's doing math and must use MathJSON because the steering file is now prescriptive. I'm starting to give it all of the elements it needs to understand how to do this, when to do it, and how to run the linter. You can see now it's actually executing the linter and validating that this is correct.

Optimizing with MCP Integration and Additional Learning Resources

We've mostly gotten to my goal at this point, but we added a couple of issues in the process that maybe you're thinking about. Some of the things that bother me a little bit about this implementation is that I just created a derivative copy of the original. I took this 1,100-line file out of the GitHub repository, went through this refinement, and now I have this derivative copy. If the original changes, and we're still working on and iterating on MathJSON, now I have this stale copy that's going to be out of date. I don't want to do that. Also, we only grabbed one of about a dozen documents that were available.

What I want to do now is layer in MCP into this. I'm going to grab the get_file_contents tool from the MCP server and update the file a little bit here to just tell it "Hey, when you need to learn about MathJSON, you can go use the MCP server. Here's a pointer to the documentation so you can learn more." I left in some of the best practices and guidance on how to use linters and such, but I've mostly condensed this down quite a bit and gotten rid of that derivative copy altogether. Now, let's come in and ask the same question that I've been asking repeatedly. You can see here that it reads in first the steering doc and then you see it start to make those MCP calls and say "Okay, I'm going to reach out and read the documentation."

Here it is reading that function reference that we've accessed multiple times along the way to pull in the information it needs in real time. Rather than leaning on that copy that we made, it's able to just go as it needs it and pull it out of GitHub or wherever you're keeping it. Of course, it doesn't have to be GitHub. It comes through and writes that MathJSON and gives it the right file extension here. You see it doing this, it adds a readme file and such that I don't think is terribly important to look at. Also, if we jump ahead here, you can see it going through and executing the linter and saying "Okay, I'm going to lint this and make sure that all of these are right. These five files look correct."

Then finally it writes a test case, writes a couple of unit tests essentially, and goes through and executes them as well. Pretty quickly, I'm able to get from Kiro knowing nothing about this to giving it the steering file to say "Hey, this exists, this is when you should use MathJSON, and here are all the pointers you need to go learn more about this." You can go read the documentation in real time as you need it.

With that, I'm almost out of time. I've mostly accomplished what I want to cover, but there are a few things that I just couldn't cram into this really short 20-minute session. I do want to talk a little bit about other things that you could do to make this even better that I didn't get to. One of them is asking Kiro to make updates on its own. I mentioned this when I said "Use the Refine button to shrink down the steering file," but you should always be thinking in this way. In this example here, there was a time where I was playing with MathJSON and Kiro's working on a big file and it says "Hey, I'm realizing that this is getting really complex. I'm going to try a new approach." We've probably all seen AI models do this. We're like "Hey, this is getting out of hand. Let me rethink this and try a different approach." This is a great time to go in and say "Hey, you said this is too complex. Do you want to go update the steering file? Would you like to go update your own guidance so that you don't make this mistake in the future?" So think about finding times to do that.

The second thing is that while we move the documentation out to GitHub, we're pointing at pretty big docs. Getting them into some kind of either vector database like Bedrock Knowledge Bases or into a semantic database like OpenSearch or Elasticsearch is a great way to allow it to go in and just grab out the piece of the puzzle that it needs. It can just grab the addition portion if it just needs to know about addition without reading the entire doc. That's an optimization you might think about adding in for a big project.

With that, I'm just going to point you to a few more things that are happening across re:Invent this week if you want to learn more about Kiro. If you've been to the Venetian, you probably saw the House of Kiro, the big haunted house up on level two right outside the expo. Get some time and go through that. It's a really cool experience to get you introduced. Also at the Venetian, we are running a Kiro kiosk in the AWS Village in the Expo Center. We have a competition running where you can win some cool swag and prizes. We're giving some swag away there too, and there's a lot to be learned. If you're spending your week down here at Mandalay Bay, over in the corner is the Builder Loft. We are there every day at noon and at 4:30 doing sessions there. So drop in there and you can meet with the service team and talk to people about it. With that, thank you. I appreciate it.

---

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