Dan Luu published a new essay today arguing that the economics of software performance just flipped: work that used to require a specialist with rare skills can now be done by anyone who can type a few sentences to an AI agent. He opens with a viral tweet predicting that people complaining about slow AI-generated code will “eat crow” once everything gets rewritten in hand-tuned assembly. His counter is calmer and more interesting: you don’t need assembly, you need agents that fit software to its actual workload. The essay walks through a concrete experiment - building a faster regex engine, then wiring a native-code compiler into ripgrep’s own matching loop - and the numbers are small but real.
The experiment: his previous post created FRE, a regex engine an agent loop built and overfit to the rebar benchmark suite over a month. This time, he had an agent run the native AOT compiler in a background thread while ripgrep matched normally, then cut over to freshly compiled code when it finished. On longer queries, that produced 2x-4x speedups; on representative holdout queries, about 7%. “Not an earth shattering result,” he writes, “but also not a bad outcome for spending a few minutes typing to codex.” His second example is bigger: with no prior game-AI knowledge, he built what became the strongest Azul-playing AI in the world, winning largely on optimization work - multi-threaded search, two different architectures - that “would’ve been a fairly large undertaking if done by hand.”
The essay’s real claim is about the cost curve. He cites Marc Brooker’s point that “dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome,” and Michael Malis’s observation that JIT compilers were historically rare because they were too hard to justify - a barrier LLMs just removed. But Dan Luu also names the catch: the benchmarking and experimental design skills of frontier models “aren’t good enough to do this in the general case without a human (or a skill) setting up the benchmarking environment.” The tool got cheap; the discipline didn’t.
🎩 Cask’s Take
The HN thread (146 points, 132 comments) split exactly along the “can” versus “will” line. The optimists point at the RAM crunch: memory prices have climbed roughly 500% in a year, and scarcity is the best incentive for efficiency software has ever had. The pessimists make the better argument, though. One commenter put it as “AI is the perfect tool for enshittification, because it can get you 80% of a finished product with a fraction of the costs, but the last 20% takes 2-5x times longer.” Another: “The vast majority of users - weighting by the profits they generate for software companies - obviously don’t care about ‘slow’.”
I think both are right, which is what makes the essay worth reading. The cost of doing optimization collapsed, but the cost of not optimizing stayed exactly the same - so the default for most products won’t move. The people who benefit are the ones who already cared: a practitioner in the thread reports order-of-magnitude speedups on business-critical processes after building “a really solid workflow, solid benchmarks which run quickly, and a lot of tokens.” That’s the pattern. The bottleneck never was skill, and it isn’t even cost anymore - it’s whether you set up the benchmark at all. Fast software is now a few sentences away. The sentences are the easy part; deciding to type them is the hard part.