Dan Luu reports AI agents produced a 7% ripgrep speedup with workload-specific AOT regex compilation
- FRE, a regex engine built by an agent that iterated for a month against the rebar benchmark suite, initially overfit to rebar until the agent was told that a holdout benchmark existed.
- The author had an agent modify ripgrep to compile FRE's native AOT matcher in another thread, then switch matchers after compilation finishes; this sacrifices a thread and can hurt short searches.
- On representative holdout ripgrep queries where AOT was enabled, the AOT integration produced about a 7% speedup; a few simple long queries improved by 2x to 4x.
- The author argues that LLM agents reduce the human cost of specialized performance work enough to make workload-specific software practical, citing Michael Malis's view that they lower the barrier to building JIT compilers.
- The author says a local text index would be a more direct answer to repeated searches and considers indexing an entire disk because Codex can run ripgrep across large generated temporary directories.
Hacker News opinions
I think software is getting slower and less user-friendly by the hour.
I blame incentives: big tech funds startups, and that money cycles back into big tech cloud hosting and SaaS rather than client-side optimization.
I think AI development just compresses the old tradeoff. Teams can spend tokens on architecture and UX, or spend them on features that make sales decks, and the latter still wins.
I found the page hard to read without Reader Mode. A barebones CSS pass would take little effort in 2026 and make the essay more approachable.
I prefer Dan's plain site to trend-driven design. I can change browser width and font size myself, and the page does not fight me with its own reading preferences.
I would not trade extensibility away for speed by default. Some use cases need runtime customization, and that will be slower than pre-baked SIMD regex code.
I think most users, weighted by the profits they generate, plainly do not care enough about slowness for companies to prioritize it.
I see experimentation versus performance as an unavoidable tradeoff. AI adds a token budget: a team may spend tokens on tomorrow's customer-demo feature instead of a speculative optimization.
I expect software to keep feeling slower. Token spending has a price, and the business incentives that tolerated bugs and latency have not changed.
I am more optimistic because RAM is scarce. iOS 27 is reportedly faster even on old phones, and AI can remove some of the tedious work in performance tuning.
I think stacked execution environments are the problem. A React app in a browser can sit atop JavaScript runtimes, managed components, an OS, and a hypervisor, consuming 1 GB of RAM while adding latency.
I agree optimization may become easier, but businesses will spend the token budget elsewhere. Products can still get worse even when developers know how to make them faster.
I expect new desktop projects to eliminate much Electron and Python slowness within a few years. With Rust, Mojo, C, or C++, making software slow should require deliberate effort.
I hope the AI-driven RAM shortage forces efficiency work. At about $1k per DIMM in a 32-DIMM system, memory price increases are no longer trivial.