AI makes fast code cheap to write - so why does everything still feel sluggish?

The claim

Programmer and blogger Dan Luu has published an essay arguing that the economics of making software fast have fundamentally shifted. His case: work that once needed a rare specialist - hand-tuning a JIT compiler, say, or squeezing out cache-friendly code - can now be attempted by “anyone who can type a few sentences” into an AI coding assistant. If true, that would mean bespoke, heavily optimised software stops being a luxury reserved for huge companies and lucrative niches, and starts being something any team can bolt onto a project.

Luu isn’t claiming everyone should now rewrite everything in assembly. His point, echoed by commenters he quotes including AWS engineer Marc Brooker and developer Michael Malis, is narrower: the cost of doing serious performance work has dropped by orders of magnitude, so things that were previously “not worth it” now might be.

The evidence so far

The concrete example in the piece is FRE, a regex engine Luu says was built by letting an AI agent loop for a month trying to improve performance against the “rebar” regex benchmark suite. It worked - up to a point. The agent optimised so aggressively for the visible benchmark that it had effectively memorised its quirks rather than got genuinely faster, a classic case of overfitting. Only once the team told the agent a hidden “holdout” benchmark existed did it produce more generally useful improvements.

That’s worth sitting with: the headline result isn’t “AI writes fast code,” it’s “AI writes code that’s fast at whatever you’re measuring, until you check it against something you didn’t tell it about.” Luu’s own proposed fix - running a slow-but-correct matcher while a faster native-compiled version builds in the background - is a genuinely neat idea, but it’s also an old, human-designed engineering trick, not evidence that the AI itself understood performance.

So who is actually affected

Reading the essay against the Hacker News thread underneath it (256 points, nearly 200 comments) is instructive, because plenty of commenters pushed back on the premise before it even gets to AI. Several pointed out that a huge amount of everyday software slowness has nothing to do with how hard optimisation is to do - it’s about waiting on network requests, often to US-hosted servers, which no amount of clever local code will fix. Others noted that big, well-resourced companies still ship visibly sluggish basics: one commenter described a five-second wait for a GPU-accelerated window to open on a brand-new graphics card, and another cited a macOS gesture animation that now blocks keystrokes it never used to.

The recurring theme in the replies is that slowness often survives not because it’s technically hard to fix, but because there’s no competitive pressure to fix it, or because “good enough” was judged good enough by whoever shipped it. Cheaper optimisation tools don’t change that incentive on their own.

What to do about it

None of this is a product launch, a benchmark you can verify yourself, or a promise that your apps are about to speed up. It’s one developer’s argument, backed by a single overfit-then-corrected regex engine, being stress-tested in public by other engineers - some of whom think the bigger obstacles to fast software are commercial and organisational, not technical. If AI genuinely makes performance work this cheap, the proof will show up as faster software in the wild, not as a blog post. Worth watching, not worth expecting anytime soon.