你不必阅读每一行

Source: Dev.to

每一天都是你的第一天。

请允许我占用你一下思维，进行一个思考实验。

如果你刚开始一份新工作，要为一个代码库做贡献，你会在提交更改之前阅读所有存在的代码行吗？还是只阅读你正在修改的模块的所有代码行？亦或是只阅读你需要更改的函数的所有代码行？

所需的精确程度当然会因任务而异，但我们大多数人并没有在开始改动之前阅读项目中所有代码行的奢侈。

现在，假设我告诉你这段代码是由世上最优秀的软件工程师编写的，你会放心吗？如果它全是实习生写的——或者是由 AI 生成的呢？

希望你现在已经明白我的意思……我们都见过糟糕的遗留代码库、实习生的代码，以及那些我们希望忘记的东西。但这并不是世界末日，因为……

遗留代码驱动世界

遗留代码是个好问题。它意味着公司已经存活足够长的时间，以至于积累了随着时间而变得破碎的代码，如果你被指派去迁移或修改这些代码，仍然可以从中提取价值。

我们都听说过许多银行和 Fortune 500 公司中运行在大型主机上的 COBOL 传说。虽然人们可以猜测它们最终的衰落，但它们的收入规模是不可否认的。

自动驾驶汽车问题

想象一下，你得到了一辆完全自动驾驶的汽车，而你知道它的安全性与自己的驾驶一样。你会让它载你四处行驶吗？如果它的安全性是原来的十倍，甚至一百倍呢？

作为对比，假设我们把道路上的所有其他车辆都换成已被证明比普通司机安全 25 % 的自动驾驶汽车。你会接受在这种环境下驾驶吗？

大多数人都有一种倾向，倾向于高估自己通过行为可以影响的风险的控制程度。因此，即使他们理性上确信自动驾驶车辆的安全性与自己或更好，仍会拒绝乘坐自动驾驶汽车。

所以……问题来了，你会让一个 LLM 为你编写代码吗？

LLM 代码只是你没写的代码

这把我们带到了第一个真正的提议。如果你对 LLM 持观望态度，自己动手试试：

1. 给一个最先进的编码模型一个你代码库中的自包含任务。
2. 与它一起规划并澄清需求。
3. 当它生成第一个版本后，解释你的编码规范和测试要求，并让它自行审查。
4. 让它打开一个 pull request，亲自看看。若是实习生、初级工程师或你的同事写了它，你会生气吗？

这可能会感觉很机械——你必须围绕需求进行对话并解释规范——但这以后也可以自动化。

我曾对代码生成持怀疑态度，直到一个紧迫的截止日期迫使我启动 Claude Sonnet 4.5 并熬了几个通宵。积压的工作消失了。审查输出后，我意识到如果是初级或中级工程师写出类似 Claude 代码的 PR，我也不会感到非常失望。与我晚上 9 点时能做到的相比，这并不是糟糕的努力，项目也重新回到了正轨。我成了信徒。

真正的问题

在那个实验之后，你可能会想：

• 输出能和你的或我的一样好么？可能可以，只要有无限的时间进行迭代和收集反馈。
• 我们能否使用这些新工具更快地工作而不失去太多质量？我认为可以——只是不需要阅读每一行代码。

你必须自问一些艰难的问题。例如，在处理遗留代码时，你会为每次迁移都重新编写整个解决方案吗？这往往是浪费时间。新工具要求我们在验证输出时更加有创意。

从根本上说，某个时刻代码的作者已经不重要，重要的是它能正常工作。我们怎么知道它能工作？这是另一个帖子的话题，我将在那里分享更多关于遗留代码的经验。

即将推出

我希望这段关于使用 LLM 编码挑战的介绍让您感到愉快。在接下来的几周里，您可以期待：

• 在阅读任何代码之前先发现问题
• 更快阅读代码并捕获更多问题
• 编写验证行为的测试
• 自动化反馈循环，使 LLM 自我审查
• 将自己从瓶颈中移除

下周再见，敬请期待更多。

~ Ben