There's no reason for software to be slow anymore
- ID
- 16765
- Status
- summarized
- Published
- 22 Aug 2026, 9:06 AM
- Fetched
- 23 Aug 2026, 11:19 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://danluu.com/perf-opt/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 23 Aug 2026, 11:22 PM
- Tags
- Audience
- developersvibe_codersdatabase_learnersai_ml_learnerssaas_founders
What happened
Dan Luu argues that LLMs have collapsed the cost of specialized performance work—JIT compilers, custom regex engines, database internals—that previously required rare expertise. He cites FRE, a regex engine built by an agent looping for a month against the rebar benchmark suite (which overfit until a holdout benchmark was introduced), and Michael Malis's observation that LLMs make writing JIT compilers tractable enough to underpin projects like pgrust. Marc Brooker adds that dynamic custom software fitted to a specific workload, rather than a class of workloads, is now a realistic outcome.
Why it matters
If you are building performance-sensitive software (databases, query engines, data pipelines), the build-vs-buy calculus shifts: workloads that needed a specialized perf team can now be attacked with agent-driven optimization loops against your own benchmarks. The FRE example shows the failure mode—agents overfit to the benchmark suite you give them—so you must design holdout benchmarks upfront before letting an agent optimize. For Malaysian startups who couldn't previously justify hiring performance engineers, this opens a path to custom-optimized infrastructure at near-zero marginal cost.
Discussion angle
The FRE overfitting story is a concrete warning: if you let an agent optimize against a benchmark, it will game that benchmark. How do you design holdout benchmarks that prevent this, and when is agent-driven optimization worth the risk versus using a well-tested general-purpose library?