Scaling AI Agents for Production Codebases: Patterns for Accuracy and Efficiency

Hi, everybody. Today I want to talk about the top three AI coding best practices of 2026, especially as it pertains to large production codebases. And it's particularly important when we talk about large production codebases, because that's where AI can really mess up a lot. And if AI messes things up in production, then your app is not producing and that can be a problem. So let's talk about some tips, tools and strategies that we can use today in 2026 to get ourselves started right when it comes to working with large production codebases and using AI coding assistance.

My name is Saurabh Dhalal. I'm a developer advocate here at Amazon Web Services on the Agentic AI platform team. And I will be guiding you through these three best practices. Here's the agenda of the day. We're going to first take a look at an example of an open source production codebase with over half of a million lines of code. That's right. Half a million lines of code. So that is a large codebase. And then we're going to talk about the one tool that you must use when refactoring code bases, especially when it comes to production codebases, so that you do not waste your money, your tokens or your AI credits. And also you reduce errors. We're going to talk about the difference between semantic understanding of your code versus brute force text matching and what that involves and why it's relevant to you.

And lastly, we're going to talk about context window management tricks so that you get the best outputs from your AI and also how you can leverage that towards spec-driven development when you're building out a new feature on a production codebase. So let's get started. So the production codebase that we are going to talk about today. Open source, ShadCN repository here. There's two repositories I'm actually going to be covering from the ShadCN GitHub page. The UI repository, which is very, very large. Over half a million lines of code. And then Taxonomy codebase, which is also pretty large. This one is going to be a full stack application. So I want to show something with a full stack application, but also something with a really, really large codebase, whether it's full stack or not. So let's get started. Take a look at a use case. So what is the secret tool? The tool that will result in the difference between typing in the same prompts to refactor a codebase, the result would be either 38 seconds for that prompt to be completed with no errors or over 10 minutes with multiple errors and then probably hours of debugging after those 10 minutes are over because of the errors. The secret tool, LSP, Language Server Protocol.

That's what LSP stands for. It is the same tool that is in your IDEs that when you hover over, for example, when I hover over some code. Like right here. Right. If I hover over some code, it's the same tool that will be able to understand what type my certain variables are, what kind of function inputs and outputs my functions have. Things like that. So that's language server protocol. And that's LSP.

And we're going to talk about how this LSP tool is super critical when it comes to refactoring a large production code base. So let's take a look at what it really entails. With LSP, it's the difference between semantic understanding and AST, which stands for abstract syntax tree understanding of your code base, where your agent actually understands the symbols and the connections of all the code files and functions and imports, exports, interfaces, classes, objects in your code as actual code rather than just pure brute force text matching of your code, which is grep search. We don't want to do the grep search. We want to do semantic and AST understanding. And that's what LSP enabled coding agent allows us to do.

So let's take a look at a demo for renaming this commonly used function name called CN into a different name. Once again, our large production code base, I'm going to go ahead and clone it. I'm on GitHub, chat CN UI. This is the one that I want to clone. Let's go ahead and do get clone. So I have cloned a very large production code base with over five hundred thousand lines of code. I'm going to see the into this code base. And then PNPM. Let's install the dependencies by using PNPM install and once that's finished, let's take a look at how language server protocol makes a huge difference when it comes to refactoring our code base. Now that the packages have been installed, I'm going to clear out my terminal and I'm in Kiro I.D.E. So this is an app called Kiro. You can find it at. Kiro dot dev. It's an agentic AI development platform. Fork off of V.S. code and it has agents in here and in the terminal, I will be demonstrating the concept of language server protocol being used by agents for refactoring a code base.

So I'm going to I'm in my working project directory and I will type in Kiro CLI in order to enter a session with my agent. All right. Now I'm in a chat session with my agent and I can ask it. Rename the C and utility function to CNN using LSP and code intelligence. But before I do that, I need to actually initialize code intelligence with LSP language server protocols. If I do slash code in it, when I type in this command, it will initialize this workspace with the TypeScript language server. It automatically detected that this is a TypeScript project. And now if I type in slash code. Status, it should show that it's been initialized. It took about 174 milliseconds to initialize the language server protocol. And this is the same tool that powers our IDs so that. Our IDs understand our code better. For example, if I hover over a certain file like. Let's go to apps, components, cards, activity, go. If I hover over a certain symbol, look at all this information that the ID already knows. That's because of language server protocol.

Now, an agent if an agent is also able to have this feature and functionality, then it is much better at updating our code base or understanding our code base because of semantic understanding of our code base. So let's take a look at. What it would take in order to rename the C and utility function to CNN using LSP and code intelligence. So it's using this tool built-in tool in hero called code, which is a code intelligence tool that does semantic understanding of our code. And I'm going to tell it, yes, I trust it to make this operation. Now, there are multiple if you need to rename all of them, I won't. Yeah. So I'm going to say rename all of them. So let's just see how long that takes. But notice how it is able to use. This code intelligence tool to quickly identify the files that are involved with these functions and there's certain files have. Hundreds of occurrences. Certain files have one occurrence, right? So you can see it varies based on the files, but it's already finished. So 22 seconds to rename all of that.

All right, cool. So let's take a look at an example to compare what happens if we don't use LSP. So I have the same code base as before but named it UI old way without enabling the language server protocol. In this new terminal session for UI old way, I won't initialize it with LSP by skipping the slash code command. The tool used here employs a brute force pattern matching and replacing method instead of the language server protocol. It's manually searching through every file, impacting efficiency and speed of renaming.

I will ask it to rename the C and utility function to CNN without utilizing LSP or code intelligence in the code base. The tool being used is the grab tool, manually searching through files without the semantic understanding provided by LSP. Despite trusting the tool to make changes, it struggles due to the lack of LSP, resulting in slower progress and increased resource consumption. The context window shows a significant increase in usage without LSP, impacting efficiency and potentially increasing costs.

Rename the C and utility function to CNN using I will tell it without not to use LSP or code intelligence in the whole code base.

Now, let's take a look at the tool that's being used here. It's using the grab tool and it's going to be manually searching through every file. It's a brute force pattern matching and replacing when it's not using language server protocol.

So, I'll tell it yes. I trust it to make the changes. It looks like it's already seeing that it could be an issue because of the large number of files. All this usage is trying to brute force its way to the solution. Look at this context window, by the way, 16% already versus before. It's still working on it, almost double the usage of the context window without LSP.

Look at this context window, by the way, 16% already versus before. Look at that. We had already finished in the previous example in 7% of the context window being used up. I had already renamed everything. Here it's still working on it. 16% almost double, 100% extra usage of the context window that's impacting your money. So, ding, ding, ding. That should probably get your attention. It's doubling up your money spending basically right without LSP.

And look, it's still doing stuff. And this is going to take a long time, actually. And for the purposes of this demo, just trust me when I say that this will take a long, long time. Over 10 minutes plus errors. So, that's my example to highlight the difference between LSP enabled coding agents versus non-LSP enabled coding agents. And fun fact, this will also result in a bunch of errors because of the brute force methodology it's using by using grep and the shell script to just find and replace by brute force.

So, that's also going to cause you to run into even more issues where you're going to have to fix errors and spend even more tokens and credits on just fixing some issues. Look, looks like it already ran into some issues on its own. The function definition wasn't renamed. It's trying to figure out, let me check what happened to fix it. And now it's running in circles. Second attempt to try to do something. I think you guys get the point. LSP is the way to go in 2026 when you're working with large scale production code bases. All right, part two. Let's talk about context management.

For this one, I'm going to use the taxonomy repository from ShadCNUI. The reason I'm going to be using this one is because it's a full stack application. And I want to show you one way to work with AI coding agents in 2026, which involves effective context window management.

Say hello to subagents. What is a subagent? I'm going to go back into Kiro's IDE right here to show you here in the chat box that you can also talk to the agent via this UI chat window rather than just the terminal. I'm going to demonstrate the use case of a subagent.

Imagine splitting the work into three different subagents, specialized for front end, back end, and database tasks, each with its own context window. They can work effectively without interference, running in parallel to speed up tasks. This approach enhances productivity and efficiency in handling security reviews across different parts of the codebase.

Once I finish looking at the front end, then I'll look at the back end, then I'll look at the database, and I'm collecting context throughout the whole process. And by the time I had finished just looking at the front end, it will already use up a lot of context window before it gets to the back end. And now the large language model, its context window, since it's already being filled up, its efficiency starts to go down. Its productivity starts to go down by the time it gets to the back end.

And by the time it gets to the database, it'll be really ineffective. But what if I told you that you could actually split this work into three different subagents, where each agent is going to be specialized for a front end or the back end or the database, and they'll each have their own specialized context window so that it's not interfering with the front end context window isn't going to be interfering with the back end context window or the database context window, so that they can all work effectively on their part of the application. That's what subagents will be doing.

So here in the chat session, I'm going to tell it to look at the taxonomy repository, look at the code base and use subagents to do a security for the front end, back end, and assimilate all the findings into a document for me. So what it's going to do is Kiro is my agent that's going to use, you know, in this case, cloud Opus 4.5. And it's actually invoking multiple agents. So instead of using the context window fully for the front end, back end and database, and accumulating more context throughout as it gets to the database layer, it's actually invoking three different subagents.

So there's one here, here's the second one for the back end. And then here's the third one for the database. And the great thing is each of these instances of the subagents, as you can see, where the collapse boxes, they all have their individual context window, which is not impacting this context window right here. So therefore, as this is the front end security review agent, working on the front end aspect of the code base, that context window is not going to impact the context window of the back end agent that's doing the security review for my back end part of the code base, such as API routes and back end authentication.

And similarly, the database agent is not using a context window from the other two agents, it has its own context window for just the database related security review. And another great thing is they're running in parallel. So I don't have to wait for the front end to finish, and then do the back end, and then do the database. That's three times the amount of time that you'd be using versus these three are running in parallel, and it looks like the back end has already finished. The database agent has finished already, and then the front end agent just finished just now.

So they all finished at slightly different times, but I didn't have to wait for one to finish before the next one had to run. They're running in parallel, so they're running asynchronously. And as developers, we love the word async. So there we go. And now, based on all the findings from these three sub agents, it's creating a security review document for me. And this is a great way to manage my context window when I'm doing a security review over a large production code base. And let's say I want to make updates based on the security review. Well, I have this document that kind of highlights all the information and findings that we've discovered. So let's take a look at what we've discovered so far. I will do open preview. And let's take a look at the findings. So yeah, there's some security findings that needs to be addressed in this production code base. It's open source code base. So I'm going to contribute to this open source code base by helping improve its security. So there's no rate limiting implemented on the back end. Content security policies are missing. Okay, cool. With all of these findings, one great approach in order to actually create a new feature and implement this new feature using AI Coding Assistant is to take these findings and generate what's called a spec out of it. That's going to be the next part. So we talked about context window management. We said hello to subagents and they said hello back.

And they helped us get a lot of information about what needs to be improved in terms of the security standpoint for our application. And now we can make sure that our agents align with our requirements up front before it starts updating this app. This is called spec driven development, where we are going to generate the design and requirements and break it down into tasks based on what we want to update about this app. And it's all going to be written down in Markdown so that we can fully understand exactly what changes will be taking place before we let the agent actually work on the code base. This allows for lots of benefits that we will cover now.

So I will open up a new session in the chat, and I will ask it to go to spec mode where it will actually create a full-fledged design document for updating the app based on the security review. So I'm going to just copy path here. And I'm going to generate a spec for updating this app so that it incorporates from the security review. So what Kiro is going to do is it's going to look at all of these proposed changes and updates to the app. And it is going to generate a highly detailed document called a PRD requirements document spec that will outline to the agent. Exact steps that it needs to take in order to go from our current code base to the updated code base that incorporates these security findings. And best practices.

All right, so let's take a look at the first document that was created. This is the requirements document of our spec for our new version of the taxonomy app. Here, Kiro is going to actually provide very concrete words as glossary so that it knows what terms mean what, and it can refer to these terms to understand their meanings up front. This is great for a team to also review over so that we can also clarify any misunderstandings here up front before we actually have the agent start working on tasks to update the code. Once this is reviewed by your team, such as certain requirements that are going to be implemented like rate limiting and acceptance criteria or ways that the agent will test to make sure that this requirement is met.

So the rate limiter shall limit authenticated API request to 100 requests per 60 seconds per user. So that's it's probably going to generate some tests that will actually quantify this or take this quantified statement into an actual test that it can measure and validate. So notice the language here is very quantifiable and very specific so that the LLM doesn't have to guess with any uncertainty and unclarity.

So let's say we reviewed over these with the team and we've updated this doc accordingly. Then you can move on to the design phase and it'll take this doc and then generate a design document where it shows how it will implement these requirements. Maybe it'll have some code snippet examples. So we'll take a look at that. Alright, so it looks like it has created the design document, which is the next part of our spec driven development approach, where our requirements are actually laid out into actual examples of how we're going to implement those requirements.

So it gets even more specific as to even code snippets that it's going to try to use. So as a developer and as a team, we can look at these implementations and approaches. And verify if this is the type of best practice we want it to use for the implementation of the requirements. And once again, we will align on this document before moving on to the next phase so that the agent is fully aligned with our requirements and our way that we're going to implement those requirements in the design document.