写代码从来不是瓶颈

多年来，我一直认为软件开发的瓶颈根本不在于写代码本身。

真正的瓶颈从来都是代码审查、通过指导与结对编程传递知识、测试、调试，还有人与人之间沟通协调所产生的“人类开销”。所有这些都被嵌套在纷繁复杂的任务票据、计划会议和敏捷开发流程之中。

这些旨在提升质量的流程，往往比实际写代码的速度慢得多，因为它们需要思考、共同理解，以及理性判断。

现在，大语言模型（LLM）的兴起使得生成可运行的代码变得前所未有的简单快捷，一种新的论调便随之出现：过去写代码才是瓶颈，现在我们终于打破了它。

但事实并非如此。

尽管借助LLM，新增代码的边际成本正在无限趋近于零，但理解、测试、信任这些代码的成本却比以往更高了。

LLM只是转移了工作，而非移除了工作

像Claude这样的工具能加快初步的代码实现，但结果通常是产生更多代码，进而给审查、集成和维护代码的人带来更大的压力。

这种现象尤其明显，当：

于是，我们陷入了这样一种状况：代码生产变得容易了，但验证代码却更加复杂，这并不会真正提高团队整体的速度。

这其实并不新鲜。开发者早就自嘲自己进行的是“复制粘贴工程”，而LLM所带来的速度和规模则进一步放大了这种复制粘贴的现象。

“代码最大的成本是理解，而不是写出来。”

LLM确实减少了产生代码所需的时间，但它们并未降低理解代码行为、发现细微的Bug或确保长期可维护性的努力。甚至，在面对由LLM生成的代码时，这些任务可能变得更难，因为审查者要区分生成代码与手写代码之间的差异，以及弄清为何要选择某个特定的方案。

软件开发本来就是一个协作过程，它依赖于共同的理解、目标一致和互相指导。然而，当代码的生成速度远超沟通和审查的速度时，团队可能会陷入一种“默认质量”而非“确保质量”的模式。这无形中给审查者和指导者带来巨大压力，可能进一步以微妙的方式拖慢团队的整体节奏。

LLM在快速原型开发、脚手架搭建和自动化方面确实带来了真正的价值。然而，它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反，随着生成代码越来越多，这些基础工作变得更为关键。

是的，写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。

这才是真正的瓶颈。我们不应假装它不存在。