AI 编程都「解决」了，为什么软件反而越来越烂？
复杂度爆炸、重构无望、激励扭曲——一场无解的死局，和个体开发者最后的反抗
导语
Hacker News 上有个帖子火了。标题就带着一股反讽味儿：《If coding has been solved, why does software keep getting worse?》
作者列举了一堆亲身经历的「烂软件」案例——银行 App 要扫三次 FaceID 才能支付、Slack 抢焦点把 git 命令直接发到了群聊、车载系统更新后转向灯随机静音……
最讽刺的是，那款车载系统的 PM 还在 LinkedIn 上庆祝自己做得有多好。团队认为自己做出了优秀的产品，用户每天都在跟 bug 搏斗。
明明 AI 编程工具越来越强，团队产出越来越高，为什么我们日常使用的软件，体验反而在全面退化？
答案可能比你想的更悲观。
📌 事件速览 事件：Hacker News 热帖《If coding has been solved, why does software keep getting worse?》 来源：https://ptrchm.com/posts/nothing-works-and-everyone-is-euphoric/ 争议点：技术能力上升 vs 软件质量下降的反差 核心论点：激励结构扭曲，公司更在乎「能不能做新功能」，而不是「已有的东西好不好用」
01 / 复杂度爆炸：不是偶然，是必然
「复杂度爆炸」这个词，说起来轻飘飘，落在开发者头上就是一座山。
逻辑线错综复杂。 一开始每个系统各自独立、边界清晰。但随着快速迭代，大家为了省事，开始互相调用对方内部的数据或服务。边界被打破，最终变成了一个「牵一发动全身」的巨型耦合体。改一个模块，炸掉另一个看起来毫不相干的系统——这种事每天都在发生。
各系统升级迭代后互相依赖互相牵制。 你升级了 A 系统的数据库版本，发现 B 系统的旧版驱动不兼容；你重构了 C 服务的 API，D 系统直接躺平罢工。没有人能说清楚所有依赖的完整图景，所有人在上面打补丁，等待下一次崩塌。
盲目跟风开发新功能。 产品团队默认「不推新功能就等于没有产出」。老板要数据增长，PM 要季度汇报的亮点，开发者觉得不追新框架就不够现代。大家都在往系统上加东西，没人敢说「这季度我们只修 bug，不推新功能」——这在现在的公司文化里几乎不可想象。
结果就是：软件比以前复杂太多，新抽象层、新框架、新基础设施层层叠加，变得异常脆弱。 每次系统更新带来的不是期待，而是恐惧。
02 / 一场必输的战争：重构的精力和时间永远不存在
如果说复杂度爆炸还只是「情况很糟」，那下面这个判断才是真正让人沉默的：
任何一个系统，经过一到两年的更新和人员变动，重构都将变得几乎不可能。
这不是危言耸听。这是技术和组织两重困境的夹击。
技术上，没人有能力统筹全局。 代码已经烂到没人敢动——没有测试覆盖，没有文档，关键模块只有当年那个离职的老员工才懂。新来的人看着像迷宫一样的项目结构，连从哪里入手都不知道。真正的全局架构师？现实中很多时候只是个挂名头衔。
业务上，公司不允许停滞不前。 新业务迭代的需求一刻不停。季度 KPI 压着，竞品在抢市场，老板在盯着数据增长。谁敢说「这半年我们不做任何新功能，只用来还技术债」？说出来就是政治自杀。重构的精力和时间，永远被新功能的需求挤得干干净净。
💡 核心洞察： “技术上没人有能力统筹全局，业务上公司不允许停滞不前，新业务迭代需求导致根本没有重构的精力和时间。”
结果是：软件一旦走向混乱，就没有回头路了。只能不断在上面打补丁，直到彻底腐烂。
03 / 无解的死局
所以，这个困境有办法破局吗？
坦率说，很难。
需要在组织层面设置一个真正的「架构师」角色来统筹全局？现实中，架构师很多时候只是挂名，真正决定系统走向的是业务压力和产品路线图。
需要管理层理解技术债务的严重性，愿意停下来还债？在季度考核的激励机制下，这几乎是一个不可想象的奢求。
这个问题的本质是：公司 KPI 鼓励「做新功能、搞 redesign」，而不是花时间修 bug、打磨稳定性。 这不是某个人的问题，是整个组织机制决定了软件必然会走向腐化。
就像用户最终给出的判断一样：无解的死局。
这个判断虽然悲观，但有它清醒的力量。
个体开发者还能做点什么吗？
回到那篇文章，作者最后的态度倒不是完全悲观——他觉得个体开发者反而有机会，在这场「AI 狂欢」中做出真正高质量的软件，作为对现状的「反抗」。
是不是理想主义的自我安慰？我不知道。
但在无解的死局里，试图让自己手头的代码不要那么烂——这可能是每个还在挣扎的开发者，最后能做的反抗。
附：原帖链接：If coding has been solved, why does software keep getting worse?
来源：
