AI Agents for Performance: Ship Faster, Pay Less

Hi there. Welcome to AI Engineer World's Fair 2026 event. I am Rajat Shah. I am a staff software engineer at Netflix, where I work in the AI platform organization, building large-scale distributed systems for machine learning model hosting.

In this talk, I'm here to, um, share how we did, uh, improve our performance engineering, uh, throughput by introducing AI agents into the mix. And this is more of a, uh, playbook or a practitioner's guide, uh, to help you also replicate similar learnings in your own organizations, uh, to improve, uh, the infrastructure cost and, uh, ship

faster. Let's first talk about the problem. Why does performance engineering doesn't scale, and, uh, what does it cost to actually do it right?

The problem is arising, arising from the fact is that you are authoring code now at a 10X faster speed. The, uh, coding agents are getting better and better, uh, at, uh, solving problems.

And, um, as more and more, uh, engineers, uh, adopt it, it, it gets very easy to produce code, uh, in your system. And this is slight exaggeration, but the compute cost also, uh, is increasing at a similar pace, uh, because, uh, it doesn't always sh- uh, write the fastest code.

Uh, so this is where the problem arises because of that new wild coding era. Uh, the AI agent ships code, uh, it is pretty much tuned to ship code fast.

Um, and of course, you could say that, uh, as the, uh, the coding agents are evolving, newer models are coming into play, uh, they get better and better at, uh, simply writing performant code.

But that's not always true. Your, um, agent doesn't know specific details about your platform and your frameworks, uh, and your internal code base patterns. So it, it tends to just produce code based on what it might have already, uh, seen, uh, other, uh, code bases using or inventing new, uh, patterns in your code bases that you did

not anticipate, uh, uh, an engineer to use, uh, as a pattern to use your framework.

So let's, uh, look at what, uh, a performance engineer typically does. Uh, I'm calling this as a human performance engineer, which is responsible for identifying bottlenecks in a service and fixing them.

Typically, a, a human would trigger profiling on a, a single production instance of a fleet of, uh, production instances. Uh, you would go and download it, uh, potentially open it in a visualizer.

The raw data that you download typically is not great to look at. It, it could be, for example, a JSON structured data of, uh, the call stack and, uh, where the CPU is spent.

So using a visualizer, uh, helps you at least see and visualize the call stack and CPU, uh, time of various, um, method in your services better. Once you have that visualizer opened, you pretty much end up spending a lot of time in, uh, like just looking at and, and finding in this, in this treasure, uh, hunt on,

uh, on the path-- o-on the potential places where you could, uh, improve, uh, the code to, uh, to make it more performant. This takes a lot of time, uh, in order to even learn how to look at it.

Um, and there's a learning curve to c-c-curve to it. And this is where the real bottleneck ends up being. You end up, you end up having to spend straight many, many minutes to, uh, to identify the bottlenecks.

Uh, once you have identified some code paths and some, uh, packages that, uh, that are spending significant CPU cycles, you, you would end up searching it in your code bases, in your code repos, uh, and see if it, uh, has a potential to improvement.

Uh, hopefully you, you hit, uh, you, you have luck here and, uh, you find a, uh, root cause and you produce a code review out, you merge it, and, uh, you get some performance wins.

And then you repeat all of this, uh, again. You see the problem, right? This is a very manual effort and very tedious effort to get right, and this ends up being a bottleneck if you were to do it across many of your code bases and code paths, and that's why this is done very rarely.

People typically end up looking at profiling data only when something is going wrong at 2:00 a.m. and, uh, somebody needs to, uh, fix a problem because your CPU is unbearable.

So we asked this question internally, can we, uh, can an L- LLM read this profiling data? The twenty minutes that I mentioned an engineer, uh, spends in identifying, uh, hot paths, can an LLM agent w-which is fed that, uh, data also, uh, do it much faster?

And we tried to answer this, uh, uh, question through some live services. So the next couple of slides will be about this experiment and how we do it right.

Uh, before we get to it, the, the foundation of, uh, of our assumption, uh, is that every profiler essentially speaks the same language. Uh, even though you would profile and you could have your services written in Java, Python, uh, Go, et cetera, uh, the profilers, uh, example that I mentioned here, uh, do the same, same thing.

They would, uh, run it, uh, in your-- uh, they would run against your production service, uh, on a single instance, and they would essentially try to capture the call stack, uh, the self CPU and inclusive CPU that is spent on, uh, on each of the, uh, methods in your call stack, uh, sampled at a very high frequency.

So irrespective of which language, which runtime you are using in production, the output of a profiling data is actually, uh, very similar and very well-structured for an LLM agent to use.

This is one assumption that we had going into the experiment The second assumption we had going into the experiment is that, uh, there are many common patterns that the coding agents have learned through their training sets across all the publicly available code sources that they might have had.

So things like, uh, O(N²) loops, uh, loop invariants, things that you are computing every time in your lee- loop, which could be computed just once outside it. Uh, if you have certain places where you are doing the object allocation, uh, very repeatedly and, uh, if you could move it out as well.

Uh, or there are times when you would be, uh, like having some contention and, uh, places where you could optimize, uh, through better batching. All of these are very common patterns that an agent already knows.

Uh, it, uh, I mean, assuming it is trained on very good quality, uh, software code, uh, the better the quality, the better agent knows, uh, which, uh, patterns are, uh, not great.

Uh, and this is a very good, uh, point for an LLM agent because it essentially means that it can technically, uh, look at the, uh, the code base, and it can identify those patterns very easily.

So this is more about like pattern recognition, like finding out these, uh, code patterns to find some code smells that, uh, that are worth fixing.

So when you have that profiling output that I mentioned, and you have a coding agent that could understand it, you feed it into it, um, the profiling data that it needs to read is actually very well-structured in a way that it could see that the, in this case, uh, the, um, the profiling data is, uh, in, in

the case of row one and row three, they are the same call path, and the immutable map copy of that I have in my row three is actually [chuckles] used inside, uh, a tensor merge method that we have.

Uh, so, uh, don't think too much about the method names here, but the key point that I wanted to call out is that it was able to use these functions.

Uh, it, it knows the meaning of these functions, and when it sees it is being used in a, a poor way, it can actually identify that this is a quadratic, uh, um, algorithm and not a linear algorithm.

So this is where, uh, our first aha moment was that, okay, if you feed a profiling data, it-- if it knows the pattern, it, uh, assuming the coding agent was trained on a very good quality data, it can actually identify and up-- and find out that, uh, find in your code base where that bad, uh, patterns are

actually, uh, running. And this is not by looking at the code base, this is purely by looking at the call stack that the profiling, uh, uh, data produced.

And once, uh, a prof... uh, an AI agent gets this, what, what are the steps that it needs to do in order to get to the potential fix? So we, we, we have mentioned that it can identify, uh, a pattern and say that, okay, this is a potential problem to be fixed.

What, what happens next? Um, it could, knowing where that method lives, it could do a code search and first of all, before, uh, I mean, yeah, it could do a code search and find out the code repo where this m-method is defined, uh, or this code is defined.

And it, it needs to extract out the exact commit that is currently running in production, which is typically easy to get. You know which build is running in your production, and you could point that to the LLM to, uh, check out the Git repo at that same commit.

And then, um, once it has, uh, find- found out, uh, and has the Git repo cloned, uh, it can look for, uh, that exact code path, uh, skip any internal library details, and find out, uh, the code patterns.

And now the te-- it, now once it has the, uh, full, uh, uh, code repo cloned out, the, um, the methods, uh, definition and implementation identified, it can trace the entire ca-call path of that method.

And this, uh, structured data, uh, once it, uh, has this information, becomes, uh, like very powerful. And we'll, we are going to talk about how, uh, it leverages this.

So these were our understanding going into the experiment. We, uh, we knew it could find, uh, the patterns. We tested it with, with a couple of, uh, of our services to see if it can actually not just find the pattern, but also take it one step further and, uh, produce a real fix and provide a real fix

that, uh, w- an engineer could approve and merge.

So first finding, uh, the, the O(N²) um, uh, example that I just mentioned. It, uh, once it knew, uh, that this is a problem and looking at the profil- uh, profiling data, it knows that this is consuming eight point eight percent of the CPU time during that, uh, uh, period of profiling.

So for us, uh, the coding agent not just ended up finding the problem, given enough instructions as a form of, let's say, skill or prompt, uh, you could actually have it, uh, do those four steps that I just mentioned, which is checking out the Git repo, uh, finding where that code is implemented, and actually, uh, sending a

code review out. All of it could be done, uh, in a very large code base with powerful enough code agents in less than five minutes. Um, and in this case, uh, we also, which I'll talk about a little bit in the later slides, uh, were able to identify what is the savings, uh, if you were to im-

re-implement it with a, uh, with an optimized implementation in terms of both CPU as well as latency savings. Uh, I, I've shown the numbers here of our real production, uh, savings that we were able to observe, uh, through this, uh, exercise So this was like a first, uh, proof for us that you could actually indeed introduce an,

a- an AI agent into the mix and get, uh, your productivity wins of not just identifying, but also going all the way to a code review. Uh, the second, uh, great benefit is that once you have this well set up, um, the, uh, other example that we are able to take it forward to it is, let's say

it identifies the, uh, pattern in one of the services that we profiled. Um, and the learning that we had is that it could actually, uh,

look at all your potential places where that same bad pattern, uh, is being reused. So in the previous example, it, it just identified one bad implementation. You fix it, you get all the benefits.

In this case, it identified not just a bad code, but because that pattern, in this case, which is a counter object, uh, for our, uh, spectator metrics, uh, that are, uh, being created on every single, uh, uh, iteration of a hot path in our service stack, um, it could essentially see that this is, uh, a real problem

and it could double down and search multiple services where that same pattern is being repeated and, uh, scale up the effort to fix it in multiple services. In this case, we found that same bad pattern were actually implemented in seven different services, uh, through cross-repo code searches.

And if fixed, it could actually, uh, if fixed across all of those different code repos, it could have savings between point five to four point six percent of CPU cycles.

Um, so we have discussed the problem, our hypothesis, and the experiment which proved out that a, a LLM coding agent could actually help improve, uh, the, uh, the finding and fixing of your, um, suboptimal code.

Let's see how we can actually build this into the development cycle. Uh, it doesn't have to be a very retrospective, uh, problem where once a production service is, uh, having issues, you end up doing all of those exercises.

I'll talk about how you can actually leverage in your end-to-end software development cycle so that you get the benefits, uh, much early and potentially avoid having that suboptimal code reach production altogether.

Uh, the first [chuckles] uh, real problem is that LLMs, if you invoke them, they do have some memory these days, but it's very compact memory, and it will, uh, it, it won't have all the, uh, information that, uh, you are, uh, uh, that, that you potentially as a performance engineer know when you are trying to debug.

So y- you... when you-- if you think of a coding agent and if you want to build it at par, uh, uh, as sufficient as, as efficient as a human engineer would typically be, you want to introduce a long-term memory that it could reuse.

Um, so that's our first, uh, real problem to solve for, and I'll talk about how you solve that. The simplest way is to first think of, uh, you want to build a catalog.

Patterns, anti-patterns. Once you have identified enough of them, you could put it in a catalog that, uh, that users, uh, that is used by an LLM agent, which can be stateless of its own.

Uh, and together, a stateful catalog and a state of stateless LLM can become a full fleet-wide memory, um, for, uh, for a coding agent to use. Um, the foundation for this and, and to foundation for incorporating in this development cycle is practically just this.

Uh, you want to keep this very central so that it's not very team specific, not very product specific, but rather a central ever-growing, uh, catalog. Uh, as the catalog patterns get written, if there are certain things that could be generalized, uh, in that example, the first example that I-- the first finding that I provided around O(N²)

implementation is actually very generalizable. All coding languages will potentially have the same problem if it, if the code is written and implemented in that way. So you, uh, you can take it a step further that your catalog can become even more, uh, ubiquitous and usable across languages and frameworks as well.

Um, and you think of it as a blueprint now. As, uh, as those, as that catalog starts growing, it becomes your building block for future coding agents to actually use for identifying the problem in your development cycle.

And that's the next thing I'm going to talk about. Um, the solution, uh, that I mentioned so far of a memory is not very fancy vector search or, or a, a vector database that needs to store all the, uh, catalog of, uh, patterns and anti-patterns.

Rather, you can start with just a markdown, uh, files in a, in a centralized Git repo.

Um, as the production findings appear, have the, uh, coding agent put more and more, uh, uh, patterns and anti-patterns into this. And the benefit is that even if one service finds this, even if one, uh, uh, profiling, even if one, uh, service did the profiling to find this pattern, multiple services that in the future are going to

run profiling, the agent that is doing the profiling of that other service can use the pattern catalog from the first service to find the patterns more optimally and not having to redo all the exercise that the first, uh, agent did in order to identify that anti-pattern.

Uh, you might think of like, how, how do I get started with this? Uh, well, y- you don't always have to start fresh, but you could start fresh. There is no harm in having a catalog that is just empty in the beginning, and as more and more pro-profiling happens, uh, more, uh, uh, powerful the, uh, coding agents

that are referring it could become. But there are few, many, in fact, uh, uh, sources of, uh, how you could, uh, public sources of how you could improve your, uh, coding agents.

If you're, uh, into C++ optimizations, Jeff Dean had this wonderful, uh, blog post, uh, around how to, uh, look for, uh, certain, uh, optimization opportunities in your C++ code.

PyTorch has a TorchFix code repo where it catalogs several anti-patterns that could help optimize kernels and, uh, the, uh, model graph of your PyTorch, uh, model. And then you might have your own pl-- uh, performance playbooks as well.

Typically, as your organization grows and your enterprise, uh, software evolves, you end up noting down certain patterns and anti-patterns. Those all could become the bootstrapping point for that, uh, catalog Git repo that I mentioned that can act as a centralized, um, place for all, uh, catalog or all patterns and anti-patterns to be noted.

And what would an entry in that catalog look like? Uh, the example is right here. Uh, as the left-hand side, it mentions the small hints that an LLM, uh, coding agent in the future could use to easily query that, uh, catalog.

It can mention a list of symbols, uh, the services where it was confirmed. Some confidence level is great here as well because as more and more services confirm this, you want to keep updating this so that, uh, the future agents get more and more confident that, okay, this is worth a human, uh, uh, human review, and I

would want to more confidently send out a code review to a human. Uh, I'm still keeping the confidence, uh, bar to just send a code review and not directly, uh, push it to production.

That's by intent. I, uh, I'll talk a little bit on why, but I do feel like there is still need for a human approval because you are modifying an existing code that is running just fine in, in production in order to optimize it, which is, which is very risky.

If you don't know the business context, if you don't have enough test coverage, uh, you might end up breaking. So there is a need for human, uh, to actually be the one responsible for approving that code review.

Uh, and on the right here, I mentioned what the entry in that pattern, anti-pattern catalog could look like. Uh, a anti-pattern and a good pattern so that both the things are well noted here.

Um, so I mentioned a code review and a human, uh, involvement in order to approve and merge that code review is still needed. So how do you optimize for noise there?

There could be enough signals that the, uh, AI agent, uh, could c-- think of, uh, improving, and it could, like, arbitrarily send code reviews for them without knowing enough about, uh, your system.

There are a few tips that I mentioned here could be very powerful in, uh, in making sure that the agent first has enough verifications done before, uh, uh, looking for an human's attention.

The integration tests, unit tests, the most basic functional tests that your, uh, system needs to have should be run ahead of time, uh, by the coding agent itself so that it knows that as it is making code changes to optimize it, it is also not, uh, causing any production, uh, business logic to, uh, fail.

So as, as you have good coverage and unit tests, it gets more confidence that, uh, it gets more confidence that your, um, cha-- that the change it is going to propose is actually right.

Once it has made that, uh, functional correctness check, you still...

Our code coverage isn't typically ideal. There are still surprises in production, uh, and canary deployments could be very powerful in this case. Uh, if you provide enough, uh, automation around this, the canary deployment could be a prerequisite before the code review, uh, uh, requires human attention.

What is a canary? Uh, you typically have as, um, you typically have two machines, one containing your old code, another containing your new code, which could be the performance, uh, fixed, uh, code.

And you send the same traffic to both of them over a period of, let's say, 10 minutes and try to compare, uh, the CPU, uh, usage across, uh, between them.

The comparison report typically is, is what you would want the AI agent to make decision on and judgment on whether, uh, it should open a code review for it.

In this case, the observability report could contain, uh, standard infra, uh, things like how, how much CPU reduction, how much latency reduced, uh, is there an increase in error rate?

If, if that's the case, it should see that as a red signal to not proceed because it might have gotten the business logic incorrect in an attempt to optimize the code.

And what I mentioned here is that this is not an AI problem. The observability, canary, verify logic, these are all standard checks that you need to have in your system.

And then final guardrail, uh, that you want to have is an engineer decision, like I mentioned. Still very important, critical, uh,

in the mix. Um, here's a mental model. Profiler gives the estimate, canary gives ground truth. Uh, canary is the way you verify and evaluate that your, uh, suggested fix is actually, uh, going to improve and have some, uh, positive impact and no negative impact.

An engineer makes the eventual decision. So the, uh, path so far has been about how do you, uh, improve the efficiency of getting from a profiled, uh, profiling data to producing a code review fix.

Uh, that's the re-reactive part that I just covered so far. Uh, which means you have the code already running in production, and now you're trying to improve it. That's a very-- that's typically too late in the game.

Now, anytime you try to change a thing that is running in production in order to improve the performance at it, you have to be very, very careful. So you want that to shift left.

You want that reactive path to be your initial guide to build that initial catalog. And as your pattern catalog grows, you want to move closer and closer to the proactive path, where, uh, as a human or a coding agent authors new code, uh, the s- the reviewer agent could actually look up that catalog and provide an inline,

uh, comment, uh, by understanding the code change and ensure-- and providing a suggestion that, "Hey, based on the pattern catalog and the observed, uh, profiling data that I have, I feel confident that this, uh, is an anti-pattern to introduce.

Can you, uh, rewrite this code?" That could be a, a review comment that a reviewer agent could be, uh, providing.

And if you shift left all the way, like why even wait until a code review? Uh, that, that's where you get the most power. Because you know the anti-patterns are already in a catalog, and if you are using a coding agent to write your code, you could actually ask the coding agent and hook that catalog in it

so that when it is, uh, producing newer tokens and producing newer code, it could actually, before writing out the inefficient code, directly reference the catalog upfront and, uh, and write your, um, code in an optimal way to start with.

Uh, this could sometimes slow down the, uh, speed of, uh, newer code, uh, being written and might end up consuming more tokens. And that's why the pattern catalog needs to be very well, uh, structured and indexed so that the, the way it parses and reads the catalog doesn't fill up the agent context too much, but rather it

can navigate it in a very hierarchical format and only, uh-- and be able to find out the exact, uh, places it needs to look for a, uh, a given pattern or an anti-pattern.

This means that if you can catch this in the code authoring phase itself, you skip all of the unnecessary, uh, overhead of, uh, somebody reviewing your code and providing a, a suggestion or even having that code change reach production.

So the sooner you catch it or even sooner you, uh, uh, introduce that pattern catalog into your software development end-to-end lifecycle, the easier it gets for you to keep the, uh, code and service running optimally.

And, uh, I do want to highlight this, that, uh, it's easier to imagine putting AI agent into every single step of your software development lifecycle for performance improvements, but that's not the intent of this, uh, discussion or the, uh, the thing, uh, or, or the playbook that I'm mentioning.

You still want these foundations very, very right. Your test coverage needs to be rock solid. Uh, business logic all needs to be very well encoded in your test. Your Canary automation needs to be amazing.

Uh, and this is where you don't need AI. You pretty much just want the AI agent to know how to invoke a Canary, where to get the downloaded report from a Canori- Canary, so that it can directly read the numbers from the report and, uh, make a judgment call.

And that pattern catalog that I mentioned is also a foundational piece which needs to be getten-- uh, which, which you need to get right. It, it is by design a Git repo so that it's both a human and a coding agent readable and, uh, authorable, and you could actually have humans also authoring patterns and anti-patterns as they're,

let's say, building new frameworks and new platform components that, uh, they have enough context on at the time of building.

The takeaways, uh, that I do want to mention. First, build your code foundations. Uh, think of, uh, all of the, uh, automation that you could do. Uh, but before introducing an LLM, try to see if there are good, uh, uh, integration points that an agent could, uh, use, such as, uh, can it automatically trigger profiling on an

instance on a, uh, CPU cluster that you have? Can it download the profiling data effectively, uh, then feed it into, uh, an LLM, um, uh, model? And can it, once it has identified the fixes by cloning the Git repo, et cetera, can it actually validate that through a real production canary through shadow traffic or real traffic?

All of those integration and foundation pieces needs to be really good in order for this entire life to life and, uh, this entire, uh, uh, lifecycle improvement that I'm mentioning.

Otherwise, it will just cause more friction and more bugs in the production. So you have to make these, uh, foundation pieces investment a lot, uh, more important. And start from here.

Don't think of, uh, the reactive path as a bad approach. Uh, reactive path is where you want to start with, and then gradually move towards, uh, towards the left and, uh, into the proactive path.

And the other takeaway, like I mentioned, uh, is important, is that as you build this, uh, memory of or essentially a catalog, the, um, the sooner you catch it, the better it gets for your, uh, end-to-end software development lifecycle to have optimus-- uh, optimal code running in production.

Um, this is a, I'll, uh, this is a great mental model for how you step-by-step proceed in automating, um, or improving your, uh, efficiency of software development lifecycle. The current state, uh, which is typically the norm, uh, you spend hours finding the problems.

It's all very manual, no LLM in the mix. Start with introducing an LLM into the mix just for the, um, the identification of, um,

uh, of a potential fix. It might be okay if you are still having to trigger a profiler, uh, and produce, uh, output and feed it into an AI agent and then having to manually run Canary, but it still gives you a lot of, uh, leeway to spend time on the other parts of the workflow as opposed to

just staring at those flame graphs to get the, um hot paths identified.

And then this talk mainly covered the, uh, level two orchestr-uh, tion, which is, um, or level two automation in an agentic spectrum, which is more about the tools, the integrations, the, the key harnesses, and the hooks that a AI agent needs to have in order to, uh, have full power-- uh, in order to have like good, uh,

uh, capability to identify a problem and give you in various development lifecycle areas of, uh, opportunities to, uh, improve your code base. And, uh, once you have this in place, once you have this standard step-by-step workflow, which could be very static, right?

In this case, the workflow that I mentioned is, is very, uh, well-defined, predefined. There is no, uh, uh, LLM to reason and plan and, uh, do the further level of automations.

All it has to do is, uh, you provide a tex-- uh, fixed workflow, which is download the profile, uh, from certain place, um, or rather trigger the profile, download the profile, uh, and then, uh, analyze it, uh, run the canary and provide a suggested fix.

Uh, you could-- Once you have that in place, you could essentially have a scheduled run on your services every week so that it can keep continuously identifying newer problems, uh, that might have not been, uh, uh, uh, or that might have been introduced in the last one week, for example, and keep, uh, the, the identification of the

problem closer to when you wrote that code. And if you were to think of, uh, more automation, uh, in this place, you could, uh,

imagine a, a, a level where the workflow is not very fixed and rather the AI agent has capabilities to even, uh, plan, reason, act, uh, you-- but you have to invest a lot more in evaluation, sandboxing.

Uh, you can't simply run AI agents, um, without the right level of security guardrails so that prompt injection and other security, uh, attacks that a typical, uh, agent infrastructure currently, um, cannot always, uh, solve for.

Uh, those, uh, things need to be heavily invested in if you were to go with level three autonomy. So start with level one, try to move to level two, and you get maximum benefits.

If you need more automation, uh, you could think of the next step, uh, as needed.

Thank you so much. Uh, I hope you got some learnings out of, uh, this small talk that I had. Uh, if, if you want to connect more and connect further, uh, I might end up putting a more detailed blog post on this on my shahrajat.com, uh, personal website.

I'll be happy to connect with you and, uh, provide more information. Take care. Thank you.