There's no reason for software to be slow anymore
TL;DR
Dan Luu argues that coding agents have cut the cost of performance work by orders of magnitude. Work that once needed a specialist now takes a few typed sentences. Anyone who uses agents competently can now ship software with decent performance. Tuning code to one user's own workload also becomes practical.
The article
- Luu had an agent make ripgrep run FRE, his agent-built regex engine, as native code. The code compiles in a background thread, and ripgrep switches over when it is ready. It took minutes of his time. It gave 2x to 4x on a few simple long queries, but about 7% on representative holdout queries.
- With no background in game AI, Luu built what he says is the strongest Azul AI in the world. It wins mostly on optimization, such as multi-threading the search. Each doubling of speed was worth about 100 Elo. Work like replaying nondeterministic bugs from logs once took days of manual effort, and an agent now does it in a loop.
- From his CPU and search-index background, Luu describes performance work as weighing a 2% gain against N person-days of verification. Agents shrink N by something like 1000x in human time. Many more of those optimizations, including speculative ones, are now worth trying.
- Jamie Brandon tried Anthropic's performance take-home, then let Claude continue from his work. Claude scored much better. Luu concludes that on a bounded optimization problem, a coding agent beats a good performance engineer. The agent still has worse judgment on open-ended problems.
- Following Marc Brooker and Michael Malis of pgrust, Luu expects software fitted to one workload rather than a class of workloads. Two minutes of setup got an FRE build tuned on his own codex ripgrep queries. It ran 2% faster than stock ripgrep on holdout queries.
- An appendix profiles how codex calls ripgrep on his laptop. Median pattern length is 55 characters, and about 94% of patterns occur only once. p99 query time is almost a minute, and the slowest query approached two hours.
Why it matters
Read the original for the concrete experiment notes, which the summary compresses. They include the ripgrep query statistics and the caveats about overfitting and agents' weak experimental design. Luu calls the post quick and non-rigorous, so treat the numbers as anecdotes from one laptop.
The discussion
The thread doubted the headline and blamed slow software on priorities, network round trips and architecture more than on the cost of optimizing. Practitioners did report real agent-driven speedups, usually when they had a benchmark and knew what to ask for. A side argument about Luu's full-width, unstyled blog took a surprising share of comments.
Slowness comes from incentives, not missing skill
The most common reply was that software was never slow because optimization was too hard. Bosses and markets reward features, and cheaper optimization doesn't change what companies value. Some pushed back with data that latency costs engagement and revenue, and the answer was that the market may care but managers rarely do. Several predicted token budgets will face the same tradeoff developer hours did, and a traffic-lane analogy framed the headline as misreading the bottleneck.
The investment that was previously measured in months of developer time may now be measured in token spend across days, but the underlying dynamics shaping where it’s directed haven’t changed.
The market cares. In my experience it’s harder to make your boss care.
Network round trips and cloud-first design
The top thread put most felt slowness on waiting for web requests, worse for anyone far from US servers. Replies split on where the time goes: some blamed backends taking hundreds of milliseconds, ORMs and microservice fan-out, not ping time. Others blamed apps that block the UI or wait on timeouts even for local data, with Sonos's cloud-routed speaker commands as the example of choice. One commenter defended cloud routing, arguing that customer networks are too broken for LAN-only control to work.
SSR or SPA doesn't really matter if the server still takes a minimum of 300ms to compose any kind of response due to how its database or other infrastructure is set up. Information theory doesn't care how clever your loading indicator is.
Just about the only thing which is used enough to be reasonably trustable on any random customer network is HTTPS to the big CDNs and Cloud providers.
Agents optimize well against a benchmark, less well on novel work
Firsthand reports backed the article: a Java hot path fell from 350ms to 60ms, and a Rust UI toolkit nearly halved its memory use. A Python-to-Rust port ran at least 5x faster, and everyone who succeeded stressed strong tests and a fast benchmark. Skeptics said agents reuse known tricks like loop unrolling and SIMD when the gains are in memory access. A ChatGPT-optimized CRDT still lost to diamond-types, and one commenter's autoresearch-tuned site drew a list of misses, like 229 uncompressed HTTP/1.1 requests.
The agent is really, really good at using tools like a profiler and disassembler, better than I am (and I've been doing this for 20 years).
This is good news for the 95% of slow software out there. But bad news for the 5% of us who write fast code already, but want our code to go even faster.
Finding the problem and the architecture are the hard parts
Several argued that the article covers only implementation, the cheapest part of performance work. Locating the cause and reworking an architecture take judgment, and a regex engine with a fixed API and a benchmark suite is the exception. Others noted that agents default to poor allocation and data layout, so getting fast code from an agent means knowing how to write it yourself. Some worried that aggressive agent optimizations and per-user bespoke software will be hard to maintain or support.
Most performance bugs are not difficult to fix [1, 2], but can sometimes be hard to identify. Implementation effort is not the driving limitation in those cases.
The reality is to get performant code (quickly) out of an agent, you need to know how to write performant code
Should agents write lower-level code and skip Electron?
One camp said that if agents write the code, Python, TypeScript, Electron and heavy frameworks lose their main benefit, convenience for humans. One commenter had an agent replace three.js with plain WebGL and cut load time by about 90%. Others answered that humans still read and fix the code, high-level languages use fewer output tokens, and agent-written C++ and Rust is often merely okay.
Eventually, we might be able to do away with the tradeoff between development velocity and runtime performance.
It writes ok code, it does not write good code. I see it leaving a lot of performance on the table, doing silly things like wrapping everything in a global mutex.
Consensus
Agents can speed up code when there is a clear benchmark and a strong test suite. Most slow software has easy wins nobody bothered to take. Most commenters agreed the binding constraint is whether anyone with authority cares about performance.
Dissent
A minority took the headline at face value and said agents now beat most humans at optimization. To them, the remaining slowness is a skill issue or a choice of language. Others went the opposite way and said agent-written code is making software slower and buggier.