写代码从来不是瓶颈
多年来,我一直认为软件开发的瓶颈根本不在于写代码本身。
真正的瓶颈从来都是代码审查、通过指导与结对编程传递知识、测试、调试,还有人与人之间沟通协调所产生的“人类开销”。所有这些都被嵌套在纷繁复杂的任务票据、计划会议和敏捷开发流程之中。
这些旨在提升质量的流程,往往比实际写代码的速度慢得多,因为它们需要思考、共同理解,以及理性判断。
现在,大语言模型(LLM)的兴起使得生成可运行的代码变得前所未有的简单快捷,一种新的论调便随之出现:过去写代码才是瓶颈,现在我们终于打破了它。
但事实并非如此。
尽管借助LLM,新增代码的边际成本正在无限趋近于零,但理解、测试、信任这些代码的成本却比以往更高了。
LLM只是转移了工作,而非移除了工作
像Claude这样的工具能加快初步的代码实现,但结果通常是产生更多代码,进而给审查、集成和维护代码的人带来更大的压力。
这种现象尤其明显,当:
提交代码的人可能自己都没完全理解代码的逻辑。
生成的代码引入了团队不熟悉的模式或违反了已有的惯例。
一些边缘情况或潜在的副作用并不明显。
于是,我们陷入了这样一种状况:代码生产变得容易了,但验证代码却更加复杂,这并不会真正提高团队整体的速度。
这其实并不新鲜。开发者早就自嘲自己进行的是“复制粘贴工程”,而LLM所带来的速度和规模则进一步放大了这种复制粘贴的现象。
理解代码才是真正的困难所在
“代码最大的成本是理解,而不是写出来。”
LLM确实减少了产生代码所需的时间,但它们并未降低理解代码行为、发现细微的Bug或确保长期可维护性的努力。甚至,在面对由LLM生成的代码时,这些任务可能变得更难,因为审查者要区分生成代码与手写代码之间的差异,以及弄清为何要选择某个特定的方案。
团队仍然依赖信任和共同背景
软件开发本来就是一个协作过程,它依赖于共同的理解、目标一致和互相指导。然而,当代码的生成速度远超沟通和审查的速度时,团队可能会陷入一种“默认质量”而非“确保质量”的模式。这无形中给审查者和指导者带来巨大压力,可能进一步以微妙的方式拖慢团队的整体节奏。
LLM很强大,但并未解决根本问题
LLM在快速原型开发、脚手架搭建和自动化方面确实带来了真正的价值。然而,它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反,随着生成代码越来越多,这些基础工作变得更为关键。
是的,写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。
这才是真正的瓶颈。我们不应假装它不存在。