There continue to be reasons for software to be slow
Summary
The post challenges the idea that post-LLM tooling will automatically eliminate performance tradeoffs. It argues that cost, prioritization, and maintenance complexities still drive performance decisions, and offers real-world examples (git performance, LLM-based autocompletion, pgrust and FRE) to illustrate why faster software isn’t guaranteed. It emphasizes careful benchmarking, realistic ROI, and the risk of over-optimizing for benchmarks.