If you continue to add floors and rooms to a building forever, it will collapse. Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance.
— Zach Kehs, There's No Limit to How Bad Code Can Get
Tags: technical-debt
本站解读
以上引文与署名均来自原作者，本站不作增改。这一节是我们自己的转述：建筑往下塌是物理约束，软件变坏没有天然的刹车——每多一层包装、多一次妥协，都只会让下一次妥协更容易发生。引语的力量在于它指出腐化没有上限，因此对抗腐化只能靠人为设定的机制，而不能指望系统自己触底。
我们的观察：AI 拆掉了最后一个刹车
本站的看法是，这段引语在 AI 辅助研发时代多了一层现实含义。过去"再烂下去"是有隐性成本的：写更多套层代码要消耗工程师的时间，而时间会逼团队停下来。当代码生成几乎不花人力时，这个隐性刹车消失了——添加一层间接包装变得比理解并复用现有实现更便宜，于是软件可以朝着更坏的方向以更快的速度滑行。这是我们观察到的趋势，不是引语作者的原意陈述。
由此本站推出一条实践判断：团队越大量使用 AI 生成代码，越需要引入人工的"负向度量"——比如每个迭代强制统计并削减一定比例的死代码与冗余抽象，让变坏的通道上至少存在一道会疼的闸门。这类做法与 AST 引导的自主代码重构架构：消除大模型代码生成的随机破坏性 讨论的问题同源。
常见故障速查
下表是本站整理的相关工程信号，与引语本身无关。
| 现象 | 原因 | 处理 |
|---|---|---|
| 同类逻辑在仓库里出现三四份实现 | 生成新代码比检索复用现有代码更省事 | 在团队规则中要求生成前先查已有工具函数 |
| 包装层数逐月增长、无人删除 | 重构只有新增没有清理 | 设立定期削减死代码与冗余抽象的固定动作 |
| 每次修复都引入新接口适配 | 修补式改动回避根因 | 允许做净删除行数的重构并纳入评审标准 |
| 审查意见越堆越多但无人处理 | 告警只增不理，债务可视化失效 | 定期把存量意见清零，优先处理重复出现的项 |
小结
本站给读者的可执行判断标准：翻出最近一个月的提交，统计新增代码行与删除代码行的比例。如果长期只进不出、且没人能说清哪些层还可以删，那么这段引语描述的状态就已经发生在你自己的仓库里——此时该做的不是引入更强的模型，而是先建立删除机制。