AI 生成代码的真实成本——维护困境与解决思路

生产力由维护成本决定

我直接切入正题：你用来写代码的 AI coding agent 需要降低你的维护成本。而且不是小幅度降低。你现在代码快了两倍？最好你已经把维护成本减半了。生产力提高三倍？维护成本要降到三分之一。否则，你就糟了。你拿临时的速度提升换来了永久的奴役。

哦，你想知道为什么？当然。让我们来一次长途驾驶。在黑暗的沙漠公路上...

每一行你写的代码都需要维护：bug 修复、代码清理、依赖升级等等。我不是在说新功能或增强特性，只是维护本身。对于你花在写代码上的每一个月，你将在接下来的一年里花一些时间维护那些代码，在之后的每一年也要花时间，永远如此，只要那些代码还在。

假设你问了一群大约 50 个开发者，他们的维护成本是多少。用一种叫做众智（Wisdom of the Crowd）的技术，你能得到一个相当准确的答案。¹

¹你欢迎自己进行众智调查！但实际上，具体的数字对我这里要说的总体观点无关紧要。

你的人群可能会告诉你，对于你花在写代码上的每一个月，你将花...

• 第一年花 10 天进行维护；以及
• 之后每年花 5 天进行维护。

如果你特别执着，可以花几小时制作一个电子表格，模拟这些估计如何影响随时间的生产力。就像这样的一个电子表格。

一个新项目的第一个月是光荣的。你把所有时间都花在构建闪亮的新功能上。

下一个月略微不那么光荣。一部分时间——不多，只是一点点——用于修复第一个月的 bug 和清理设计错误。第三个月，又多了一点。第四、五、六个月...

最终，它一点都不光荣。根据我们人群的维护成本估计，2 年半后，你将花超过一半的时间进行维护。10 年后，你几乎无法完成任何工作。

把人群的维护成本估计减半，可以让你再多坚持三年才达到 50% 的分界点。翻倍的话，你不到一年就会跌破 50%。

教训很清楚。如果你想要一个高效的团队，你必须关注他们的维护成本。

这些数字对你来说有意义吗？对我来说是有的。在我作为咨询师的职业生涯中，我专门与晚期初创公司合作，他们都有上图所示的确切问题。大约 5-9 年后，他们会意识到他们的团队不再能完成工作，然后他们就会叫我。

他们的团队不如图表所示的那么糟糕。也许他们的维护成本更低。或者也许——这对我来说似乎更可能——他们的维护成本正好那么糟，只是他们掩盖了问题。也许他们：

• 决定不修复所有 bug，或升级所有依赖
• 当团队变慢时添加人员...然后不断增加更多，因为永远不够
• 抛弃一切，用完全重写来重新开始

关于具体维护数字有讨论的余地，但总的来说，这个模型感觉是对的。如果你在这个行业待过一段时间，你就知道这个图表是真实的。你见过生产力如何随着时间消退。你有伤疤。

这与 AI 有什么关系？

假设你的团队刚开始使用 Rock Lobster，最新最伟大的 agentic 编码框架，它将你的代码产出翻倍！！万岁！但代码有点难理解，你的团队被 pull request 淹没了，你也许有点点点点点点没有真正读过代码就砸下了批准按钮。我是说，你在无聊的会议中有时候匆匆瞄过，那肯定足够了，对吧？LGTM，让我们完成这个工作！

现在你在一个月内完成了两个月的工作，假设每"月"的产出维护成本翻倍了。下个月的维护成本就翻四倍。

使用 Rock Lobster 大约五个月后，你的生产力回到了起始水平，再过几个月，它比你从未接触过 Rock Lobster 的情况还要糟糕。

我不是说你的 AI 将维护成本翻倍。或生产力。这是一个极端例子。但即使你的 AI 生成的代码与人工写的代码一样容易维护，生产力的收益也不会持久。

你可以随时办理退房²

²但你永远无法离开。

Agent 很贵，而且成本只会越来越高。一旦你的 agent 不值得用了，你可能会决定省钱，回到旧的编码方式。像个原始人一样。用你的手指。

哈！笑话在你身上！当你停止使用 agent 时，所有的生产力收益都消失了...但增加的维护成本没有！只要那些代码还在，你就被困在比从未接触过 agent 更低的生产力中。

数学只有在 LLM 降低你的维护成本，且降幅与代码产出增幅完全相反时，才能成立。如果你将产出翻倍，维护成本也翻倍，二乘以二等于四，你的维护成本翻了四倍。如果你将产出翻倍，维护成本保持不变，二乘以一等于二，你的维护成本仍然翻倍了。

相反，你必须反转你的生产力。如果你的代码产出翻倍，你需要维护成本为原来一半的代码。产出翻三倍，维护成本要降到三分之一。

这是成功的秘诀。所有好处，没有锁定。

我们能杀死这只野兽吗？

我不知道。我读过的所有最好的新闻来源都说编码 agent 增加了维护成本。有些人确实说它们帮助他们更好地理解大型系统。但成本大幅下降，达到我们需要的规模？没有。恰恰相反。

那是个问题。这个模型不是现实的完美映射，但总体信息是对的。你需要能降低维护成本的 AI，而且降幅要与新代码带来的速度提升成反比。没有它，你就糟了。你拿临时的速度提升换来了永久的奴役。

所以，是的，继续追求代码速度的改进。但也要花同样多的时间追求维护成本的改进。否则，你也会被困在加州旅馆。

尽管看起来如此，这并不是反 AI 的咆哮。还有其他杠杆可以拉，比如让维护本身更有生产力的 AI，即使它不能让代码更易维护。我鼓励你复制那个电子表格，处理模型中的所有杠杆。看看当你改变假设以匹配你的真实世界情况时会发生什么。

我所有的内容都用我 100% 的人脑制作。如果你喜欢这篇文章，请查看我最好的写作和演讲，并考虑通过电子邮件或 RSS 订阅更新。