AI Agents for Performance: Ship Faster, Pay Less — Rajat Shah, Netflix

Hi there, welcome to AI Engineer Worlds Fair 2026 event. I'm Rajat Shah, I'm 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 share how we did improve our performance engineering throughput by introducing AI agents into the mix, and this is more of a playbook or a practitioner's guide to help you also replicate similar learnings in your own organizations to improve the infrastructure cost and ship faster.

Let's first talk about the problem: why does performance engineering doesn't scale, and what does it cost to actually do itright? The problem is arising from the fact that you are authoring code now at a 10x faster speed. The coding agents are getting better and better at solving problems, and as more and more engineers adopt it, it gets very easy to produce code in your system.

And this is slight exaggeration, but the compute cost also is increasing at a similar pace because it doesn't always write the fastest code. So this is where the problem arises because of that new wide coding era. The AI agent ships code; it is pretty much tuned to ship code fast.

And of course, you could say that as the

coding agents are evolving, newer models are coming into play, they get better and better at simply writing performant code. But that's not always true. Your agent doesn't know specific details about your platform and your frameworks and your internal code base patterns.

So it tends to just produce code based on what it might have already seen other code bases using, or inventing new patterns in your code bases that you did not anticipate an engineer to use as a pattern to use your framework.

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

Typically, a human would trigger profiling on a single production instance of a fleet of production instances. You would go and download it, potentially open it in a visualizer. The raw data that you download typically is not great to look at.

It could be, for example, a JSON structure data of the call stack and where the CPU is spent. So using a visualizer helps you at least see and visualize the call stack and CPU time of various methods in your services better.

Once you have that visualizer open, you pretty much end up spending a lot of time in just looking at and finding in this treasure hunt on the path, on the potential places where you could improve the code to make it more performant.

This takes a lot of time in order to even learn how to look at it, and there's a learning curve to curve to it. And this is where the real bottleneck ends up being. You end up having to spend straight many, many minutes to identify the bottlenecks.

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

you hit you have luck here and you find a root cause and you produce a code review out, you merge it, and you get some performance wins. And then you repeat all of this again. You see the problem,right?

This is a very manual effort and very tedious effort to getright, 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 AM and somebody needs to fix a problem because your CPU is unbearable. So we ask this question internally: can an LLM read this profiling data?

The 20 minutes that I mentioned an engineer spends in identifying hot paths, can an LLM agent which is fed that data also do it much faster? And we try to answer this question through some live services. So the next couple of slides will be about this experiment and how we do itright.

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

They would run it in your they would run against your production service on a single instance, and they would essentially try to capture the call stack, the self CPU and inclusive CPU that is spent on each of the methods in your call stack, 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 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 there are many common patterns that the coding agents have learned through their training sites across all the publicly available code sources that they might have had. So things like O(N) square loops, loop invariants, things that you are computing every time in your loop, which could be computed just once outside it.

If you have certain places where you are doing the object allocation very repeatedly and you could move it out as well. Or there are times when you would be having some contention and places where you could optimize through better batching.

All of these are very common patterns that an agent already knows. I mean, assuming it is trained on very good quality software code, the better the quality, the better agent knows which patterns are not great. And this is a very good point for an LLM agent because it essentially means that it can technically look at

the code base and it can identify those patterns very easily. So this is more about pattern recognition, like finding out these code patterns to find some code smells 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, the profiling data that it needs to read is actually very well structured in a way that it could see that in this case,

the profiling data is in the case of row 1 and row 3, they are the same call path and the immutable map copy of that I have in my row 3 is actually used inside a tensor merge method that we have.

So 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. It knows the meaning of these functions, and when it sees it is being used in a poor way, it can actually identify that this is a quadratic algorithm and not a linear algorithm.

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

And this is not by looking at the code base. This is purely by looking at the call stack that the profiling data produced.

And once

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

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

And 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 check out the Git repo at that same commit.

And then once it has found out and has the Git repo cloned, it can look for that exact code path, skip any internal library details, and find out the code patterns. And now once it has the full code repo cloned out, the methods definition and implementation identified, it can trace the entire call path of that method.

And this structured data, once it has this information, becomes very powerful. And we are going to talk about how it leverages this. So these were our understanding going into the experiment. We knew it could find the patterns. We tested it with a couple of our services to see if it can actually not just find the pattern, but also take it one step further and produce a real fix and provide a real fix that an engineer could approve and merge.

So first finding, the O(N) square example that I just mentioned, once it knew that this is a problem and looking at the profiling data, it knows that this is consuming 8.8% of the CPU time during that period of profiling.

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

All of it could be done in a very large code base with powerful enough code agents in less than five minutes. And in this case, we also, which I'll talk about a little bit in the later slides, were able to identify what is the savings if you were to re-implement it with an optimized implementation in terms of both CPU as well as latency savings.

I've shown the numbers here of our real production savings that we were able to observe through this exercise. So this was like a first proof for us that you could actually indeed introduce an AI agent into the mix and get your productivity wins of not just identifying, but also going all the way to a code review.

The second great benefit is that once you have this well set up, the other example that we are able to take it forward to it is, let's say it identifies the pattern in one of the services that we profiled.

And the learning that we had is that it could actually

look at all your potential places where that same bad pattern is being reused. So in the previous example, 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 for our spectator metrics that are being created on every single

iteration of a hot path in our service stack, it could essentially see that this is a real problem and it could double down and search multiple services where that same pattern is being repeated and 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 through cross repo code searches. And if fixed, it could actually if fixed across all of those different code repos, it could have savings between 0.5% to 4.6% of CPU cycles.

So we have discussed the problem, our hypothesis, and the experiment which proved out that LLM coding agent could actually help improve

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

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

The first 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 it won't have all the information that you are that you potentially as a performance engineer know when you are trying to debug.

So

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

So that's our first real problem to solve for. And I'll talk about how you solve that. The simplest way is to first think of you want to build a catalog. Patterns, anti-patterns, once you have identified enough of them, you could put it in a catalog that uses that is used by an LLM agent, which can be stateless of its own.

And together, a stateful catalog and a stateless LLM can become a full fleet-wide memory for a coding agent to use. The foundation for this and to foundation for incorporating in this development cycle is practically just this. 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 catalog.

As the catalog patterns get written, if there are certain things that could be generalized. In that example, the first example that I the first finding that I provided around O(N) square implementation is actually very generalizable. All coding languages will potentially have the same problem if the code is written and implemented in that way.

So you can take it a step further that your catalog can become even more ubiquitous and usable across languages and frameworks as well. And you think of it as a blueprint. 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. The solution that I mentioned so far of a memory is not very fancy vector search or a vector database that needs to store all the catalog of patterns and anti-patterns.

Rather, you can start with just a markdown files in a centralized Git repo. As the production findings appear, have the coding agent put more and more patterns and anti-patterns into this. And the benefit is that even if one service finds this, even if one profiling even if one 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 agent did in order to identify that anti-pattern.

You might think of like, how do I get started with this? Well, 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 profiling happens, more

powerful the coding agents that are referring it could become. But there are few many, in fact, sources of how you could public sources of how you could improve your coding agents. If you're into C++ optimizations, Jeff Dean had this wonderful blog post around how to look for certain optimization opportunities in your C++ code.

PyTorch has a torch fix code repo where it catalogs several anti-patterns that could help optimize kernels and the model graph of your PyTorch model. And then you might have your own performance playbooks as well. Typically, as your organization grows and your enterprise software evolves, you end up noting down certain patterns and anti-patterns.

Those all could become the bootstrapping point for that catalog Git repo that I mentioned that can act as a centralized

place for all catalog all patterns and anti-patterns to be noted. And what would an entry in that catalog look like? The example isright here. As the left-hand side, it mentions the small hints that an LLM coding agent in the future could use to easily query that catalog.

It can mention a list of symbols, 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 the future agents get more and more confident that, okay, this is worth a human

review and I would want to more confidently send out a code review to a human. I'm still keeping the confidence bar to just send a code review and not directly push it to production. That's by intent. 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 production in order to optimize it, which is very risky.

If you don't know the business context, if you don't have enough test coverage, you might end up breaking. So there is a need for human to actually be the one responsible for approving that code review. And on theright here, I mentioned what the entry in the pattern anti-pattern catalog could look like.

Anti-pattern and a good pattern so that both the things are well noted here.

So I mentioned a code review and a human 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 AI agent could think of improving and it could arbitrarily send code reviews for them without knowing enough about your system.

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

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

So as you have good coverage and unit tests, it gets more confidence that it gets more confidence that your that the change it is going to propose is actuallyright. Once it has made that functional correctness check, you still our code coverage isn't typically ideal.

There are still surprises in production. And canary deployments could be very powerful in this case. If you provide enough automation around this, the canary deployment could be a prerequisite before the code review

requires human attention. What is a canary? You typically have as you typically have two machines, one containing your old code, another containing your new code, which could be the performance fixed code. And you send the same traffic to both of them over a period of, let's say, 10 minutes and try to compare the CPU usage across between them.

The comparison report typically is what you would want the AI agent to make decision on and judgment on whether it should open a code review for it. In this case, the observability report could contain standard infra things like how much CPU reduction, how much latency reduced, is there an increase in error rate.

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 that you want to have is an engineer decision, like I mentioned, still very important, critical

in the mix.

Here's a mental model. Profiler gives the estimate, canary gives ground truth. Canary is the way you verify and evaluate that your suggested fix is actually going to improve and have some positive impact and no negative impact. And engineer makes the eventual decision.

So the path so far has been about how do you

improve the efficiency of getting from a profiled profiling data to producing a code review fix. That's the reactive path that I just covered so far, 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 as a human or a coding agent authors new code, the reviewer agent could actually look up that catalog and provide an inline comment by understanding the code change and providing a suggestion that, hey, based on the pattern catalog and the observed profiling data that I have, I feel confident that this is an anti-pattern to introduce.

Can you rewrite this code? That could be a review comment that a reviewer agent could be providing. And if you shift left all the way, like why even wait until a code review? 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 producing newer tokens and producing newer code, it could actually before writing out the inefficient code, directly reference the catalog upfront and write your code in an optimal way to start with.

This could sometimes slow down the speed of newer code being written and might end up consuming more tokens. And that's why the pattern catalog needs to be very well structured and indexed so that 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 and be able to find out the exact places it needs to look for 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 overhead of somebody reviewing your code and providing a suggestion or even having that code change reach production. So the sooner you catch it or even sooner you introduce that pattern catalog into your software development end-to-end lifecycle, the easier it gets for you to keep the code and service running optimally.

And I do want to highlight this that 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 discussion or the thing or the playbook that I'm mentioning.

You still want these foundations very, veryright. Your test coverage needs to be rock solid. Business logic all needs to be very well encoded in your test. Your canary automation needs to be amazing. 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 canary so that it can directly read the numbers from the report and make a judgment call.

And that pattern catalog that I mentioned is also a foundational piece which needs to be which you need to getright. It is by design a Git repo so that it's both a human and a coding agent readable and 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 they have enough context on at the time of building.

The takeaways that I do want to mention first, build your code foundations. Think of all of the automation that you could do. But before introducing an LLM, try to see if there are good

integration points that an agent could use, such as can it automatically trigger profiling on an instance on a CPU cluster that you have? Can it download the profiling data effectively, then feed it into an LLM

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 need to be really good in order for this entire life-to-life and this entire 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 foundation pieces investment a lot more important. And start from here. Don't think of the reactive path as a bad approach.

Reactive path is where you want to start with and then gradually move towards the left and into the proactive path. And the other takeaway, like I mentioned, is important is that as you build this memory of essentially a catalog, the sooner you catch it, the better it gets for your end-to-end software development lifecycle to have optimal code running in production.

This is a great mental model for how you step-by-step proceed in automating or improving your efficiency of software development lifecycle. The current state, which is typically the norm, 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 identification of

a potential fix. It might be okay if you are still having to trigger a profiler and produce output and feed it into an AI agent and then having to manually run canary. But it still gives you a lot of leeway to spend time on the other parts of the workflow as opposed to just staring at those flamegraphs to get the hot parts identified.

And then this talk mainly covered the level two orchestration, which is or level two automation in an agentic spectrum, which is more about the tools, the integrations, the key hardnesses, and the hooks that an AI agent needs to have in order to have full power in order to have good capability to identify a problem and give you in various development lifecycle areas of opportunities to improve your code base.

And 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 very well defined, predefined. There is no LLM to reason and plan and do the further level of automations.

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

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 that might have not been

or that might have been introduced in the last one week, for example, and keep the identification of the problem closer to when you wrote that code. And if you were to think of more automation in this place, you could

imagine a level where the workflow is not very fixed and rather the AI agent has capabilities to even plan, reason, act. But you have to invest a lot more in evaluation, sandboxing. You can't simply run AI agents without theright level of security guardrails so that prompt injection and other security attacks that a typical agent infrastructure currently cannot always solve for.

Those 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, you could think of the next step as needed.

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

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