The post argues that software should no longer be slow by default because LLMs can now do a lot of the expensive, fiddly optimization work that used to require rare specialists. Dan Luu’s concrete example is regex performance. Give an agent a clear objective, a benchmark harness, and tests, and it can grind through candidate changes much more cheaply than a human team would. The core claim is not that models magically invent brilliant new algorithms on demand. It is that they make “good enough to be worth trying” optimization much cheaper, so many code paths that were never worth tuning before now are.
Most of the useful pushback landed on a different point: raw implementation effort was never the main reason mainstream software feels slow. People kept coming back to needless network dependence, round trips to distant servers, bloated web stacks, microservice sprawl, heavy ORMs, and UI designs that block on the network even when they do not need to. Several commenters said that what users experience as slowness is often a self-inflicted architecture problem, not a CPU problem. A local action waits on a backend. A backend fans out across services. A cloud-controlled device sends commands over the
WAN instead of the
LAN. An app that already has data cached locally still waits for a timeout before showing it. In that framing, LLMs may help polish hotspots, but they do not fix a bad systems design or a product decision to centralize control.
Where the discussion was strongest was in separating easy wins from hard ones. For hot, well-bounded loops with a solid benchmark and correctness checks, a lot of people reported real gains. Java and Rust users described agents building
JMH benches, using
async-profiler or
Java Flight Recorder, rewriting data layouts, packing values more tightly, and finding big improvements fast. Others said the same pattern works for search indexes, regex engines, scientific code ports, and desktop app memory usage. But the consensus was that these wins come when the task is narrow, measurable, and testable. Once the problem becomes architectural, cross-cutting, or novel, models still need a human who understands performance deeply enough to define the target, judge tradeoffs, and catch wrong turns.
That fed into the broader conclusion: fast software is still mostly a question of incentives and taste. Teams that care can ship sub-second experiences today. Teams that prioritize feature throughput, cloud control, cross-platform convenience, analytics, and org-chart-friendly architecture will keep shipping slow software, now with AI in the loop. LLMs lower the cost of optimization. They do not create the will to simplify. Several people put it more bluntly: the biggest gains still come from doing less, avoiding unnecessary requests, and refusing obvious waste before any fancy optimization pass begins.
danluu.com