AINEWS
An AI coding agent built a text pattern matching engine in a month of compute, and the work that once demanded a rare specialist is now a few sentences of prompting.
When an LLM agent loop built a working regex engine in about a month of compute on a public benchmark, the economics of performance work shifted. The engine, called FRE, is the load-bearing example in Dan Luu's argument that slow software is no longer a budget reality but increasingly a deliberate choice.
FRE matches regular expressions, the patterns developers use to search text. It was produced by Claude Code running on the rebar benchmark suite, a collection of real-world regex workloads used to measure engine performance. Luu uses it to show that performance work, once gated on rare specialist labor, now sits inside a prompting budget. The work that used to require someone who had spent a decade learning how a CPU cache hierarchy actually behaves is now a few sentences of natural-language instructions and a month of compute time.
The historical precedent is FFTW, the Fastest Fourier Transform in the West, a library so tightly fitted to its workload that parts of it were written by re-using code as textures for cache locality, a trick borrowed from the demoscene subculture, where programmers compete to squeeze the most out of constrained hardware by running data through the CPU's memory hierarchy as if it were a graphics pipeline. Those optimizations were economic only when the workload was stable enough to amortize the build cost over years of use. LLMs have collapsed that amortization curve, and the build cost now amortizes over weeks.
JIT compilers translate code at runtime to extract more performance from a program, and they have historically been too hard to be worth writing for most projects. The build cost has only been justifiable for software with very long lifetimes and very large user bases. That threshold has fallen, and databases represent the next category where formerly-rare specialist work is now tractable on a small team.
Lawsons has long argued in the testing literature that "you can choose how many bugs you want now," meaning the trade is never between perfect and imperfect but between which defects the project is willing to ship. Luu ports the adage to performance: the cost of optimization has fallen, so the question is no longer whether the work is affordable but which slow paths, untested edge cases, and unmaintained engines the project is willing to leave in place.
The post's origin is a viral tweet claiming that LLMs will let ordinary developers rewrite bloated codebases in "super-optimized assembly." Luu engages with that claim and reframes it. The interesting work is not assembly-level micro-optimization of existing code. It is workload-fitted engines, custom JITs, and the demoscene-style trick of treating memory as a stage. The cost collapse Luu describes is general. The viral framing is narrow.
The thesis is "code was never the hard part" in some domains. The hard parts are the problem definition, the workload characterization, the validation against real input distributions, and the long-term maintenance. LLM agent loops reduce the writing cost; they do not reduce the cost of knowing which engine is worth building. The bottleneck moved from the keyboard to the design judgment.
What fills the gap is the work Luu names as "fun risks and opportunities." Custom engines become worth building in markets where off-the-shelf libraries are good enough that nobody bothers to write one. JIT compilers become reachable for projects that would never have funded a JIT author. Workload-fitted code becomes affordable wherever the input distribution is stable and the build cost is now measured in prompting rather than headcount. The question for builders is which previously-uneconomic optimizations are now worth the (now-cheap) build cost. The question for everyone else is which slow software is still slow by choice, and which is still slow because the build cost, even at the new price, is still not worth paying.