Agents Write Rust That Outperforms State-of-the-Art Libraries by 20x

Writing Rust code that's fast by asking agents to make the code faster

Agents Write Rust That Outperforms State-of-the-Art Libraries by 20x

Max Woolf shows that agentic LLMs can iteratively optimize Rust code to be 2x–20x faster than established libraries like umap-learn and xgboost. With prompts demanding a 1.2x speedup per pass and forbidding unsafe code, agents autonomously apply SIMD, loop unrolling, and caching. The approach, dubbed 'benchmaxxing,' raises concerns about overfitting, but diverse benchmarks and quality gates keep results honest.

After months of testing and experimenting since the release of Opus 4.5 made agentic coding more viable, I can confidently confirm that modern agentic LLMs can indeed write Rust code that is significantly faster than current state-of-the-art approaches if given appropriate guardrails and constraints.
  1. metalspot

    I have done a fair amount of low level performance optimization with Opus 5 and its reasoning is still very poor. Like why is CRC so slow and going through loops until I ask it if is using hardware instructions and it tells me it is using its own hand coded implementation poor. Reasoning about l1/l2/l3 cache hit ratios and their implications basically throwing darts at the wall, in the wrong room. If you give it a benchmark feedback loop then it might get there eventually but still massive alpha for low level systems engineers who instinctively know how this stuff works and can now automate 99% of the grind.

  2. lordnacho

    I've been having great results with this kind of thing. I find that really just need a sensible framework within which the optimization can take place. Essentially just providing the measurement harness, and some sort of motivation for what I'm doing.

    The great thing about LLM is that it seems to have the checklist for everything. If I rattle off a few things like "don't allocate on the hot path" and "remember to pin the cores" it will come up with a few items of its own that I might have forgotten.

    Eventually, it will have gone through the whole list with me, while having documented all the measurements along the way.

    But it's still guided by experience. If I see unusual numbers, I might say "hey did you forget to compile it in release mode?" and it will apologize and fix that. If I don't, it may just continue exploring without realising everything is wrong.

  3. hombre_fatal

    If it can be measured, then LLMs can optimize it.

    Once I had repo commands that could dump `sample` results and a cpu profiler/trace and then a benchmark tool that let me A/A + ABBA/BAAB-test the current modified git workspace against HEAD or any commit, the LLMs could just do their thing.

    And that's how my homemade terminal uses much less memory than ghostty/kitty/iterm yet has more throughput.

    AI is going to increasingly unmask people and companies who don't care about correct and performant software now that it's become so trivial to guarantee both. It used to at least be expensive and time-consuming and expertise-demanding to do those things.

  4. espeed

    can LLMs write better code if you keep asking them to “write better code”?

    One of the keys for me was the use of types. Typestate when functions mint witnesses that can only come from it and are required to proceed and newtypes where you use custom types instead of strings so the agent can't forget. You can also use it to force the agent to use the implementation rather than reinvent the wheel by simulating linear types. Types are a much smaller target to optimize and provide constraints that fail loudly at compile time.

  5. jpadkins

    I have found that having a separate agent (session / instance) do the benchmarking and reporting the results back to looping optimizing agent is a clean way to prevent cheating. The benchmarking agent has no reason to cheat, its goal is to just to run benchmarks when tickled.

    I also found this is really nice for quality evals. Have one agent with no context on how something is made do a quality review, with lots of detailed feedback. Then pass back the review notes to the implementor for feedback. It works a lot better than having an agent self-evaluate its own quality.

More from this day

2026-09-22