AI coding agents cut performance optimization costs by orders of magnitude, blogger argues
In a follow-up post on his blog, the author argues that coding agents have made performance optimization work, which used to require rare and expensive expertise, cheap enough that anyone who can type a few sentences can now do it. He builds the case on his own experiments rather than on a single product. Responding to his earlier post, engineer Marc Brooker agreed that this points toward 'dynamic custom software, fitted to a particular workload rather than a class of workloads,' comparing it to old demoscene tricks for squeezing performance out of specific hardware. Michael Malis of pgrust added that AI has not removed the difficulty of writing code everywhere, but where writing the code was genuinely the hard part, such as JIT compilers, LLMs have lowered the barrier enough that 'we can be more ambitious about the type of software we build.'
The author's first example is his own regex engine, FRE, and the ripgrep tool that uses it. He had a coding agent add a native ahead-of-time (AOT) compiler that runs in a background thread while ripgrep's normal matcher is already searching, then cuts over to the compiled version once it finishes. On a handful of simple, longer queries this gave a 2x to 4x speedup; across representative holdout queries where AOT should be enabled, the gain was about 7%. He notes the approach trades away speed on short queries, since a thread is lost to compilation while it runs, and that the earlier FRE engine had to be re-tuned once he warned the agent about a holdout benchmark, because it had overfit to the original benchmark suite. He frames the whole exercise, describing and then testing an optimization, as itself now a task of a few minutes' human time.
His second example is an AI he built to play the board game Azul, with no prior background in game AI. He estimates it is the strongest known Azul-playing AI by a fair margin, built with an agent's help in roughly two orders of magnitude less time than the academic thesis behind the second-strongest AI, and mostly on his own laptop rather than a cluster. Differences from the rival AI include multithreading, which the rival lacks, and reproducible-replay debug logging that would have taken him days to a week to build by hand. He estimates the AI gains about 100 Elo per doubling of search speed, and says stacking in ten to twenty optimizations that are 'too annoying for most people to do by hand' produces a strength gap he calls unreasonable to chase with a hand-written AI. He adds a caveat specific to this domain: many of the optimizations change the AI's actual move choices, not just its speed, and current publicly available frontier models are, in his assessment, still weak at experimental design, so he had to build the evaluation framework himself before he could judge whether a given change actually helped.
His third example is secondhand. Jamie Brandon, preparing for performance-engineering interviews, attempted Anthropic's public performance takehome exercise on his own, then had Claude continue from where he stopped. Claude reached a noticeably better result. Looking at what Claude had done that he had not, Brandon said some of it matched ideas he had already considered but not gotten to, while, in his words, '[o]thers were just crazy shit that I would never try unless I was working on this for weeks.' Brandon went on to get the performance-engineering job he was after. The author's reading of the episode is blunt: on a well-defined optimization problem like that one, a reasonable human performance engineer does not stand a chance against a capable model, adding that he suspects he would not either, given comparable time.
The author dates the broader shift, sharply falling costs for this kind of work, to roughly November 2025 for publicly available models, and says the reduction is variable but often on the order of a thousand to a million times less human time than before, and roughly a thousand times less in dollar cost when metered token spend is weighed against what it would have cost to pay a specialist, such as the Bing engineer who wrote the JIT compilers behind the BitFunnel search index the author once worked on. He closes the piece by starting to discuss further optimization ideas raised by Michael Malis of pgrust, but the retrieved text cuts off mid-sentence at that point.
Key facts
- Adding a native AOT compiler that runs in a background thread and cuts over once ready gave the author's ripgrep setup a 2x to 4x speedup on simple longer queries, and about a 7% speedup on representative holdout queries where AOT should apply.
- The author's Azul-playing game AI, built mostly on his own laptop with agent help, took an estimated two orders of magnitude less time than the thesis project behind the second-strongest known Azul AI, and gains about 100 Elo per doubling of search speed.
- Jamie Brandon tried Anthropic's public performance takehome himself, then let Claude continue from where he stopped; Claude reached a better result, including ideas Brandon said he would never have tried unless he had spent weeks on the problem.
- Commenters Marc Brooker and Michael Malis of pgrust, responding to the author's earlier post, agree that AI has made workload-specific custom software, including previously rare projects like JIT compilers, practical to build.
- The author dates the sharp drop in the human time and dollar cost of performance-optimization work to roughly November 2025, and estimates the reduction at up to a million times in human time and roughly a thousand times in dollar cost for some cases.
Why it matters
The piece argues that coding agents have collapsed the cost of a specific, previously expensive skill: performance optimization. Work that used to need a rare specialist or a dedicated team, and that only the largest or most lucrative projects could justify, can now reportedly be described to an agent in a few sentences and implemented in minutes to hours. That reopens a category of custom, workload-specific software optimization, echoing Marc Brooker's comment that 'dynamic custom software, fitted to a particular workload rather than a class of workloads' looks like a likely outcome, and Michael Malis's point that projects like JIT compilers, historically too hard to be worth building, are now within reach.
Who it affects
Performance and systems engineers, whose specialized skill the piece says is being commoditized: Jamie Brandon still landed the performance job he wanted, but the author argues a human does not stand a chance against a capable model on a well-defined optimization problem. It also affects solo developers and small teams who can now attempt ambitious infrastructure work, such as custom JIT compilers, database engines or search indexes, that previously required a specialist team; and heavy users of agentic coding tools such as Codex and Claude who are already applying them to this kind of work.
How to use it
The author's own pattern is to describe an optimization in a few sentences, for example running a native AOT compiler in a background thread and cutting over once it finishes, and let a coding agent implement what would otherwise be substantial hand-written engineering. He stresses testing against representative holdout benchmarks rather than only the target benchmark, since his own regex engine had overfit to its original benchmark suite until a holdout was introduced. He also flags a limit: in domains where an optimization can change a program's actual output, not just its speed, he says current models are still weak at experimental design, so a human still needs to build the framework used to judge whether a given change actually helped.
How solid is it
This is a personal blog post built on the author's own, self-reported experiments (the FRE regex engine and ripgrep, the Azul game AI) plus quoted reactions from two named commenters, Marc Brooker and Michael Malis, responding to an earlier post, and a secondhand account of Jamie Brandon's experience with Claude. The headline figures, such as the 'two orders of magnitude' time saving on the Azul project or the roughly thousandfold drop in dollar cost, are the author's own estimates rather than results from a controlled study or independent benchmark.
Risks and caveats
The comparisons rest on one author's self-reported numbers and estimates, including a time-saving estimate for the Azul AI project drawn from reading a rival's thesis rather than a direct head-to-head test. The author's own AOT-compiler approach for ripgrep trades away performance on short queries, since a thread is lost to compilation while it runs. He explicitly cautions that current publicly available frontier models are still weak at experimental design, which limits how far this generalizes without human oversight. The retrieved text also cuts off mid-discussion of further optimizations raised by Michael Malis, so any additional detail or caveats past that point are not captured here.
“[o]thers were just crazy shit that I would never try unless I was working on this for weeks”
— Jamie Brandon, on ideas Claude tried in Anthropic's performance takehome that he had not gotten to himself