There's no reason for software to be slow anymore
Claims that AI agents can now optimize software so effectively that “there’s no reason for it to be slow anymore” prompt strong pushback. Commenters argue that real-world performance is governed less by technical possibility and more by incentives: businesses prioritize features, speed of delivery, cloud/SaaS lock-in and visual flair over efficiency, while LLMs often amplify existing bad architecture rather than fix it. Some share successes using AI for targeted optimization and see promise in agentic workflows, but most expect everyday software to keep feeling slower and heavier unless economic and product priorities change.
Economic incentives & “enshittification”
- Many argue software is slow mainly because incentives favor features, lock‑in, and monetization over performance or craftsmanship.
- Venture/PE dynamics: build something good, then raise prices and cut quality; AI makes it cheaper to churn out “80% done” products at scale.
- Even with AI, organizations will still prioritize visible features over invisible speed, unless performance obviously impacts revenue or user churn.
AI/LLMs as performance tools
- Several commenters report real wins: order‑of‑magnitude speedups in hot paths, regex engines, search/indexing, hydrology code, and web frontends by combining profiling, benchmarks, and iterative AI rewrites.
- Agentic “autoresearch” loops plus good test/benchmark suites are seen as a strong fit for micro‑optimization and SIMD/GPU-heavy kernels.
- AI can quickly learn profilers and ecosystem tooling (JMH, async-profiler, etc.) and try many variants humans wouldn’t have time to explore.
Limits, risks, and tradeoffs
- Others find LLMs produce slow, insecure, and architecture‑blind code by default; optimization attempts often crash or overfit to benchmarks.
- Hard problems: memory layout, cache use, data/hardware‑oriented design, distributed architecture, and long‑lived, complex codebases.
- Concern that aggressively optimized AI code becomes too clever to maintain, and that juniors with AI become “dangerous multipliers” of bad designs.
- Several note that performance is only one axis among correctness, security, stability, simplicity, and maintainability; “optimize only for speed” is risky.
Architecture, networks, and real sources of slowness
- Many say the main bottleneck is architecture, not raw code: chatty microservices, ORMs, unnecessary network round‑trips, and cloud‑only designs.
- Network latency, especially for non‑US users, and slow backends dominate perceived slowness; spinners and animations are often papering over this.
- Local‑first / offline‑first approaches, CRDTs, and careful data placement are proposed as better fixes than UI band‑aids.
Languages, frameworks, and bloat
- Strong criticism of Electron, heavy JS frameworks, and SPA stacks for basic apps; calls to use Rust/Go/C++/C or “plain JS”/minimal libraries.
- Counterpoint: frameworks and Electron give cross‑platform velocity; AI might eventually lower the cost of native per‑platform implementations.
- Some hope RAM scarcity from AI hardware pressures will force efficiency; others are pessimistic given longstanding perverse incentives.
UX, perception & article presentation
- Several note that “fast enough for average users” drives most decisions; power users are far more sensitive to delays and “fake” animations.
- Separate thread on the article site itself: some complain about tiny fonts and full‑width text; others like the bare‑bones, no‑fluff style and rely on reader mode or custom CSS.