引用 Zach Kehs 的话

判断

技术负责人不能再把「等崩了再还债」当默认策略：软件没有建筑那样的坍塌阈值，新增一层间接或性能下降不会触发任何终止信号，止损线只能由团队自己先划，账单由之后的维护者付。

依据

Zach Kehs 在 Simon Willison 的网志摘录里说：建筑不停加楼层和房间终会倒塌，软件没有这个约束，代码可以一直变差——总能再加一层间接（indirection，指调用链上多插一层转发）。Willison 在 2026年9月6日收录这条引文，归入 technical-debt（技术债）标签。机制是：建筑的成本由重力即时兑付，软件的多一层间接和性能下降由未来的修改者分期兑付，且没有兑付期限。Kehs 给出的两个变差方向——加一层间接、性能下降——都不会打断编译和测试，所以任何依赖「出故障再修」的流程都收不到提醒。材料里出现过的量化项只有赞助方 Teleport 的实验：13 名工程师用 LLM 清洗代码库 90 天，那是广告位内容，不能拿来给 Kehs 的论断做证据。