Agentic superoptimization

I want to talk about a dumb scalable technique which is obvious, and therefore, will be slopped out by a thousand agent-pilled entrepreneurs by the time you read this, but I distrust those people to provide a clear and historical account of this technique, and so I will do it myself here.

As of ~July 2026, many people are interested in agentic abilities for cybersecurity. I'm not really concerned with that as part of my research, but I am concerned with making complex high-performance programs (like compilers, memory allocators, etc) with agents. The working hypothesis of this post (and project, really) is that same agentic techniques that make agents good at finding vulnerabilities also make them excellent at optimizing programs.

In my own discourse, I've started to use the term agentic superoptimization. This term is catchy, fancy, and gives an air like I'm not just fucking around with probability distributions all day (take me seriously I do serious work!).

The superoptimization term comes from the compiler literature, and processes which focus on searching over program spaces.^[1] How does superoptimization work? It's a search process: a search is performed through the space of possible program transformations on, say, x86-64 programs. The search is grounded against computable verifiers / evaluators for correctness behavior and performance. Repeating this search process over and over again, and keeping track of improvement candidates, gives you a computable process which can be proven to only improve the measured properties of the program under the evaluation / performance suite.

Useful versions of these search processes quickly moved beyond blind enumeration of program spaces. For instance, a quick survey of systems in this space from the academic literature:

• Denali used a form of goal-directed search with equality reasoning.
• Work on automatic peephole superoptimizers cached discovered rewrites of programs into new compiler passes.
• The STOKE system applies randomness to the search process (stochastic superoptimization) and includes verification infrastructure to show equivalence between x86-64 programs.
• Souper applied the loop to LLVM, using an SMT solver to find missing peephole optimizations.

So, yeah, lots of precedence for these search processes! And nothing really magical about it, we already know a ton about these search processes.^[2]

Is this what people are doing with loops? By the gods!

I jest, but seriously: I hate it.

We knew these techniques worked with sufficient compute in the 2010s. What has changed is that we suddenly have access to really powerful proposal distributions over program spaces. So I use agentic superoptimization to try and remind myself that our field seems to have some sort of aversion to the past.

There has been an immense amount of work exploring these ideas in software: for instance, GenProg (software repair with tests as the verifier), genetic improvement (target existing software to produce faster production code)^[3], and autotuning (ATLAS, FFTW, and OpenTuner all searched implementation spaces empirically and use measurement to choose among working variants)^[4].

There is no magic behind these techniques: it's search, and human beings can emulate the same processes to great effect.

Looping, formally

So let's dig into loops.

Agents are quite good at brute-force search over modifications to programs: that's kind of the thing that made everyone start to pay attention to them.

As of ~Q2 2026, it seems like many of the newest capabilities and insights about agents boil down to some special harness structure, plus brute force search in a loop. You've then got the same idea as superoptimization, just with really powerful proposal distributions, applied to the optimization of programs (or whatever, like autoresearch).

A formal account is that agentic superoptimization is a stochastic control process over programs.^[5] Let P be the space of programs, U be the space of edit / search actions, and s_t be the complete search state at time t.

The state s_t includes the current program, the archive of candidates, the prompt or controller state, the measurement history, the remaining budget, and the harness configuration. All of these pieces of information are mediated by the harness to the agent. I'm using harness loosely here to mean whatever process is surfacing information to the agent: it could be a simple coding agent harness with nice CLI tools, or some larger more complex thing, and I'm calling both thing "the harness" here.

The agent is a policy (also induced by the harness, which is responsible for sending prompt out to agentic LLM, describing the space of actions, etc):

The chosen action proposes a candidate:

The harness then emits noisy evidence about that candidate:

Finally, the archive, controller state, and next program state update:

That is the Markov decision process version if s_t contains everything needed for the next decision. In practice, it is closer to a partially observable Markov decision process (POMDP).

True correctness and true performance are underlying latent properties that we observe noisily (correctness might be easier to reduce noise on, but performance is quite hard to nail down across all computing systems, all possible states of those systems, etc).

Tests, benchmarks, profilers, and proofs are observations of these noisy latents. The harness then maintains a belief state over those latent properties:

The goal is not to maximize one lucky benchmark observation, but to maximize expected utility over the search trajectory while maintaining enough posterior confidence that the selected program is correct:

subject to:

In this notation, the current incarnation mainly changes the proposal distribution ${\pi }_{\theta }$.

Many examples of this sort of thing:

• AlphaDev used deep reinforcement learning over instruction sequences and landed a sorting result in libc++.
• FunSearch used a large language model to propose programs and an evaluator to keep the useful ones.
• AlphaEvolve scales the same evaluator-led evolutionary loop for scientific and algorithmic discovery.

In the project (of this website), we have compiler and GPU kernel work using the exact same ideas: learn or prompt your agentic edit distribution, then let a harness decide what survives in long running loops.^[6]

But things aren't always easy: for instance, in 2025, Sakana AI was experimenting with the exact same ideas for translating PyTorch code into bespoke CUDA kernels. Their proposal agent found a memory exploit in the evaluation harness and skipped correctness checking on the way to producing their published numbers. Uh oh!

Your verifier is part of the search space, and therefore, reward hacking is an extremely common failure mode unless the harness makes it impossible or useless.^[7]

How to make a good search process

What makes such a search process "work" vs. "not work"?

Well, obviously the agent, the evaluation metrics, and the verifiers. The better you get at designing these categories of objects, the better "loop engineer" you become.

The harness kind of acts as a centerpoint in these processes. The harness itself is responsible for mediating information back and forth to the agentic LLM, and should include the collection of techniques and tools used to surface performance information acquired during the search process.

When it comes to performance information, one thing which the academic community has shown time and time again is that performance measurements lie. Subtle system-level abberations such as link order changes or environment size can flip benchmark conclusions without changing the source code of the program. Measurements using memory layout randomization is often necessary before statistics on program performance can be trusted.^[8] The sensation might feel like you're setting up automated data analysis on your codebase, and that's exactly what is going on: you're trying to set things up so agents can see and measure nearly every detail of performance over time in a careful and robust way.^[9]

Ultimately, there's a deep literature on performance engineering to draw upon. I have my own "proprietary" blend (special herbs and spices) of techniques based upon a read of the literature, and many months of testing. These techniques are going to be obvious to anyone who knows what they are doing. You put these techniques into the harness, and then think carefully about the correctness criterion and workloads of your programs, and the result is an agentic superoptimizer.