软件不再有理由变慢了
有人声称，AI 代理如今已能如此有效地优化软件，以至于“软件不再有理由变慢了”，但这一说法引发了强烈反驳。评论者认为，现实中的性能问题与其说受技术能力限制，不如说受激励机制支配：企业更重视功能、交付速度、云/SaaS 锁定和视觉效果，而不是效率；同时，LLMs 往往是在放大既有糟糕架构，而不是修复它。也有人分享了用 AI 做定向优化的成功经验，并看好代理式工作流，但多数人预计，只要经济和产品优先级不变，日常软件仍会继续显得更慢、更臃肿。
经济激励与“enshittification”
- 许多人认为，软件之所以慢，主要是因为激励机制更偏向功能、锁定效应和变现，而不是性能或工艺质量。
- 风投/PE 动态：先做出一个好产品，然后涨价并降低质量；AI 让以规模化方式批量产出“80% 完成”产品变得更便宜。
- 即使有 AI，组织仍会优先考虑看得见的功能，而不是看不见的速度，除非性能明显影响收入或用户流失。
把 AI/LLMs 当作性能工具
- 一些评论者报告了真实收益：通过分析性能、做基准测试并反复用 AI 改写，在热点路径、正则引擎、搜索/索引、水文代码和 Web 前端上获得了数量级的加速。
- 结合良好的测试/基准套件，带有代理能力的“自动研究”循环被认为非常适合微优化以及 SIMD/GPU 密集型内核。
- AI 可以很快学会 profiler 和生态工具（JMH、async-profiler 等），并尝试大量人类没有时间探索的变体。
局限、风险与权衡
- 也有人发现，LLMs 默认会生成缓慢、不安全且对架构缺乏感知的代码；优化尝试常常崩溃或对基准测试过拟合。
- 难题包括：内存布局、缓存利用、面向数据/硬件的设计、分布式架构，以及长期存在、复杂的代码库。
- 有人担心，经过激进优化的 AI 代码会过于“聪明”而难以维护，而带着 AI 的初级开发者会成为坏设计的“危险放大器”。
- 多位评论指出，性能只是正确性、安全性、稳定性、简洁性和可维护性中的一个维度；“只优化速度”是有风险的。
架构、网络与真正的变慢来源
- 许多人表示，主要瓶颈是架构而不是原始代码：过于频繁通信的微服务、ORM、不必要的网络往返，以及只面向云的设计。
- 网络延迟，尤其对非美国用户而言，以及缓慢的后端，主导了人们对“慢”的感受；加载动画和转圈往往只是在掩盖这些问题。
- 更好的修复方案被认为是本地优先/离线优先、CRDT，以及谨慎的数据放置，而不是 UI 层面的修补。
语言、框架与臃肿
- 对 Electron、沉重的 JS 框架和 SPA 技术栈用于基础应用的批评很强烈；有人呼吁使用 Rust/Go/C++/C，或“纯 JS”/最少库。
- 反方观点是：框架和 Electron 提供了跨平台开发速度；AI 最终可能会降低为每个平台实现原生版本的成本。
- 有人希望 AI 硬件带来的 RAM 紧张会迫使效率提升；也有人因长期存在的错误激励而持悲观态度。
UX、感知与文章呈现
- 一些人指出，“对普通用户来说足够快”主导了大多数决策；而重度用户对延迟和“假”动画要敏感得多。
- 关于文章站点本身还有另一条讨论：有人抱怨字体太小、文本全宽；也有人喜欢这种朴素、无废话的风格，并依赖阅读模式或自定义 CSS。