back

rustforge

point it at a slow python function and it comes back with a rust version that does the same thing, faster, with a fuzz test as the receipt. honorable mention at the openai and modal autoresearch hackathon.

Runtime on a one-million-element baseline: python takes 1820 milliseconds, the generated rust extension takes 3.3 milliseconds. runtime on a 1m-element baseline python 1820 ms rust 3.3 ms, drawn to the same scale 0 ms 1820 ms 446x to 548x faster, depending on the function
both bars use the same scale. the rust bar is two pixels wide because that is what a 548x speedup looks like when you do not cheat the axis.

the problem

every python codebase has a few functions that dominate its runtime, and rewriting them in a compiled language is well understood but tedious. the tedious part is not the translation, it is proving the translation still does the same thing on inputs nobody thought to test.

One round of the loop: fifty agents propose rust rewrites, each is compiled and property fuzzed against the python original, and the fastest surviving candidate is kept before the next round begins. slow python fn the target 50 agents one round, in parallel compile + fuzz pyo3, hypothesis keep fastest that still matches next round starts from the winner
candidates that fail to compile or disagree with the original are dropped, not repaired. at 50 per round it is cheaper to discard than to debug.

how it works

what it means

the speedup is the headline, but the fuzz gate is the part that makes it usable. an llm rewriting hot code is only interesting if something independent checks the rewrite, and a property test is cheap enough to run on all fifty candidates every round.