代码审查变得昂贵，重写变得廉价

# 审查变得昂贵，重写变得廉价 来源：http://ishmeetbindra.com/posts/reviews-have-become-expensive-rewrites-have-become-cheap/ LLM 并不懒惰。它们不会因为一个更简单的解决方案似乎足够好就走捷径。如果它们知道如何彻底解决问题，它们就会这么做。 LLM 默认选择自己构建，而不是直接去采购。不是因为它不知道现有的库——它常常会提到它们——而是因为对 LLM 来说，写两百行实现代码和写两行 import 语句，认知成本是一样的。它没有习惯去走最短路径。对模型而言，最短路径就是完整地实现一遍。 因此，审查 AI 生成的代码变得更昂贵了。你正在阅读一段技术上正确但过度设计的代码，而且你必须决定是接受这种复杂性还是提出反对。这个决定需要时间。在审查评论中说明理由也需要时间。而且因为同样的问题反复出现，你总得一次又一次地重复讨论。 另一方面，重写现在变得廉价了。如果我在自己的工作或别人的 PR 中识别出过于复杂的代码，我会让 AI 简化它、改用某个库、或者砍掉一个当前不需要的功能。重写通常能更快搞定。制造了问题的模型，也是解决问题最快的方式。 经济账变了。现在审查是昂贵的步骤。重写反而不是。 我的工作方式因此重新组织了。我把更多时间花在前期的规划上——决定什么东西应该存在、我们使用哪些库、实际范围是什么——因为这是我在代码被写出来之前就能遏制复杂性的地方。然后我实现、部署到测试环境、看看实际有什么、识别出哪些东西不必要存在或者本可以用十行代码而非一百行来实现。然后我重写那个部分。 如果审查时觉得某段代码太复杂，之后再重写它不再像以前那样是沉没成本了。这改变了我提出反对的力度。标记一个问题并反复迭代的成本降低了。而放任其通过的代价，依然如故。