LLM对程序员的冲击和影响

LLM| 2023-07-11

作者 | 茹炳晟，腾讯 Tech Lead

1 LLM 在软件开发过程中的单点提效

LLM 对软件研发的单点提效，我之前录制过一段视频，大家可以直接观看，里面有详细的演示，我在这里就不再赘述了。

除此以外，我这里罗列一些更多的可能用途：

智能代码提示
代码片段智能生成
SQL 语句的智能生成与调优
更高效更精准的静态代码检查与自动修复（非 rule-based）
智能辅助的代码评审与代码重构
单元测试和接口测试代码的自动生成
更高级的重复代码检查（语义重复检查）
失败用例的自动分析与归因
更精准的技术问答
…

看到这里，你有可能会得出一个结论：完蛋了，程序员要大面积失业了。真的是这样吗？要回答这个问题，我们需要从全局来看问题，首先我们要搞清楚，LLM 对于软件研发，什么变了？什么没有变？

2 LLM 对于软件研发，什么变了？

看了上面的案例，你应该已经能够体会到 LLM 对于软件研发单点效率提升的各种可能性，这些能力让我们看到了软件研发的变化，我把这些变化总结为：基础编码能力的知识平权，进而带来局部效率的提升。

图6: LLM LLM对程序员的冲击和影响

以前工程师个体学习掌握一门计算机语言以及相应的数据结构和算法，需要较长的学习周期，很多经验和模式还需要工程师个体在大量实践中进行总结，每个工程师个体都在重复着这个过程，现在 LLM 让一个没有接受过系统培训的个体也能拥有同样的能力，个体和个体之间的能力差异被 LLM 拉平了，这就是知识平权。

如果说 ChatGPT 实现了数字时代知识的平权，codex 类的代码语言大模型实现了基础编码能力的知识平权，进而带来软件研发的局部效率提升。

可以说，LLM 降低了软件开发的门槛，可以让更多对软件开发感兴趣的人更加轻松地参与到软件开发工作中，同时，LLM 提高了编程的效率和质量，使我们可以在更短的时间内完成更多的工作，因而能留出更多的时间让我们思考。

前段时间，前哈佛大学计算机科学教授，曾在 Google 和 Apple 担任高级工程职位的 Matt Welsh 发表了一个视频，其中的主要观点是“LLM 将会代表着编程的终结”，他认为程序员会被淘汰，未来只有产品经理和代码审查员。我不知道大家对这个怎么看？

我的观点是，在抱有敬畏之心的同时，我们不要轻易下结论。为什么，因为软件研发还有很多东西是没有变的，而这些没有变的才是软件工程中的核心问题和主要矛盾。

3 LLM 对于软件研发，什么没有变？

我们面对的是软件工程的问题，编程不等于软件工程，编程只是软件工程的一部分。软件工程的四大内在特性（复杂度、不一致性、可变性、不可见性）并没有因为 LLM 的出现而发生本质上的变化，这才是软件工程面临的主要矛盾。

图7: LLM LLM对程序员的冲击和影响

从复杂度的角度来看，问题域本身的复杂度并没有变，本质复杂度也没有变，变的可能只是一部分的随机复杂度。虽然说局部编码变简单，或者说更高效了，但是需求分析和软件设计并没有因为 LLM 而变得简单，这个稍后我们来详聊。

从一致性的角度来看，由于软件研发的本质依然是“知识手工业者的大规模协作”，所以我们非常需要一致性。如果系统是一致的，则意味着相似的事情以相似的方式完成，错并不可怕，怕的是错的千变万化。LLM 的出现并没有提升软件研发的一致性，甚至由于 LLM 本身的概率属性，使用 LLM 实现代码生成的不一致性问题反而是被放大了，这点我们后面展开讲。

从可变性的角度来看，软件会随着需求不断演进和变化，所以架构设计和模块抽象只能面向当下，它天然是短视的，或者说是有局限性的，这种局限性即使是最优秀的架构师也是不可逾越的。

在敏捷开发模式下这个问题更被凸显了出来，而且需求本身就是零散的，目标也是模糊的，在没有全局视图的情况下，架构自然就是有局限性，所以需要不断迭代变更。每个迭代，你能拿到的信息仅仅是宏大视图中的小小一角，根本没有全貌，LLM 对此也是无能为力的。

从不可见性的角度来看，软件的客观存在不具有空间的形体特征，不同的关注点，会有不同的图。综合叠加这些图是困难的，而且强行可视化的效果会造成图的异常复杂，反而失去了可视化的价值。设计无法可视化就限制了有效的沟通和交流。

如果以上四点再叠加上大型软件的规模效应，其中包含软件系统本身的规模和软件研发团队的规模，问题就更严重了，即会显著提升软件研发过程中的沟通成本、决策成本、认知成本和试错成本，而这些才是软件工程问题的本质，这些本质问题自始至终都没有变过，LLM 对此也基本无能为力。

基于上述的分析，我们可以看到，软件工程的核心矛盾并没有改变，现代软件工程应对的是规模化场景下的各种问题，基于 LLM 实现的编程提效只是其中的一小部分，而其中最重要的需求和代码演进模式都没有发生本质变化，我们接下里分别展开讨论一下。

图3: LLM LLM对程序员的冲击和影响

4 需求的重要性没有变，在 LLM 时代还被放大了

只有我们的需求足够的清楚，那么生成的代码才会准确。如何准确全面描述需求成为了关键。面向自然语言编程，首先你要有能力把话讲清楚。但是问题是：你能讲清楚吗？

我们通过一些实践发现，要把需求描述到让它能正确写出来代码，需要的工作量似乎已经接近甚至超过编码了。为什么会这样，有两个方面的原因。

一是因为大多数的代码实现是 imperative 的，而需求描述是 declarative 的，这两者对人的要求完全不一样。我们程序员群体接受的教育是编程，而不是需求描述，也就是说程序员本来更擅长写代码，而不是描述需求。

二是因为在当前的开发模式下，程序员直接用代码默认帮需求（产品经理）做了很多代偿。很多在需求中没有明确提及的内容被程序员用代码直接实现了（代偿）。而现在要倒过来先把需求的细节完全理清楚这个可能不是程序员当前的工作习惯。而且代码的信息熵其实要大于自然语言，程序员更善于用代码而非自然语言来描述事务。

举个例子：如何清楚地描述一个排序函数 sort 的需求？sort 输出的数字必须是从小到大排列的，这样描述需求就够了吗？其实远远不够，重复数字怎么处理？排序数据的数量有没有上限？有的话如何提示？排序时长需要有超时设计吗？是预先判定还是中途判断？算法复杂度有明确的要求吗？算法需要应对并发吗？并发的规模怎么样？等等。

一个软件的需求，不仅仅是功能性的，还有很多非功能的需求，这些都是需要描述清楚的。另外代码实现的时候，还要考虑为可测试而设计，为可扩展而设计，为可运维而设计，为可观测而设计等等。原本这些很多是开发代偿了，现在要从需求生成代码，你必须要提前讲清楚。

所以，我们的总结是：“软件从业者高估了编程的复杂度，但是却低估了功能和设计的深刻度”。

5 代码是持续“生长”出来的，需要持续更新

对于现行的软件开发范式，当需求发生变动后，一般是会在原有代码基础上改动，而不是直接从头全量生成全部代码，这个时候，LLM 本质上做的是局部编程的辅助（pair programming）。局部编程辅助过程中，经常需要对代码做局部修改，而这个往往并不容易。

我们知道，代码的信息熵大于自然语言，用信息熵更低的自然语言去描述代码，尤其是准确描述大段代码中的若干个位置往往是困难的。想象一下，如果只用在线聊天的方式跟别人讲在代码的什么地方做修改的效率是何其低下，相比指着屏幕，或者使用专门的 CR 工具，效率的差距是巨大的。

如果需要进一步描述如何修改就会更困难，因为大概率需要用到很多代码上下文的相关描述，所以对于 prompt 的表述要求以及长度要求都很高。

另外，LLM 接纳修改意见（prompt）后的输出本身也是不稳定和不收敛的，同时也具有不可解释性，LLM 本质上不是基于修改意见（prompt）进行改写，而是基于修改意见（prompt）重新写了一份。输出的代码需要人重复的阅读和理解，使得认知成本变高了。

同时，LLM 的原理决定了其会“一本正经的胡说八道”的本质，会混合捏造一些不存在的东西，可以说人工智能的混合捏造是人工智能在无知情况下的“自信”反应，而这个点在代码生成上是灾难性的，比如会将不同类型的 SQL 语句混在一起使用，会分不清 Go 语言的 os.Kill 和 Python 语言的 os.kill()。这个问题可能需要使用 AI 审计 AI 的方式来缓解了。

刚才提到，要在原有代码基础上修改，就需要利用已有的代码上下文，而不是从 0 开始。要实现这一点，一个最朴素的做法就是把整个项目的代码都贴到 prompt 里，但这样并不现实。因为 GPT-3.5 限制最多只能 4096 个 tokens，GPT-4 最多 8192 个，除非项目非常小，否则根本放不下。这个问题可能需要用 langchain 来解决了。

LangChain 是一个链接面向用户程序和 LLM 之间的一个中间层，通过输入自己的知识库来“定制化”自己的 LLM。langchain 使用 embedding 建立基于项目特定的向量知识库，实现“基于特定文档的问答”。

6 LLM 时代，对软件研发更多的思考

思考 1：替代的是码农，共生的是工程师

图2: LLM LLM对程序员的冲击和影响

在软件开发过程中，当伪代码级别的设计完成后，最后一公里的编码实现会被 LLM 替代，因为基于记忆的简单重复编码不是人的优势，而是机器的优势。

这部分工作现在属于码农，也就是我们俗称的 CRUD 仔和 API Boy，所以很多不涉及设计的码农可能会被大模型替代。

而工程师需要关注业务理解、需求拆分、架构设计、设计取舍，并在此基础上通过 prompt 学会与 AI 合作，从而实现“工程师 + LLM”形成 1+1 >2 的效果。这就是共生。

需要注意的是，这种共生必须始终保持人的主观能动性，机器必须是 Copilot，也就是智能副驾驶，主驾驶位置必须是人，这样的人 – 机关系才能长期健康发展。这也就是为什么说微软现任 CEO 萨提亚强调 Copilot（智能副驾驶）是比 Autopilot（自动驾驶）还先进的根本原因。

另外，特别要提的是：短期内率先学会使用 LLM 的工程师必将获益，但是很快大家都会掌握，这个时候能力水平就再次被拉平了，这个很像之前“外卖骑手困在系统里”那篇文章中的观点，所以作为共生的工程师，我们更需要从以下三个方面来强化自己的能力：

需求理解、需求分析、需求拆解的能力
架构设计、架构分析、设计取舍的能力，并推动设计的文档化和规范化
理解问题本质，而不是单纯学习应用（授人以鱼不如授人以渔）

思考 2：有利于控制研发团队规模，保持小团队的优势

图8: LLM LLM对程序员的冲击和影响

随着一个软件规模的扩展，软件项目参与的人越来越多，分工越来越细，人和人之间需要的沟通量，也指数增长。很快你会发现，沟通花费的时间，渐渐地就比分工省下来的时间还要多。说白了，过了一个临界点，人越多不是越帮忙，而是人越多越添乱。一个人 12 个月能完成的事，不见得上 12 个人 1 个月就能完成，甚至 12 个月也未必能完成。

《人月神话》里建议了一种组织方式，叫“外科手术式的队伍”。就像一台外科手术一样，有一个主刀大夫，软件项目也应该有一个首席程序员，其他人都是给他提供支持的。这样，就既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

但是软件规模大了之后，需要的程序员数量必然会更多，团队规模一定会加速扩展。但是 LLM 的出现，让基础编程工作一定程度上实现了自动化，这样非常有利于控制研发团队规模，保持小团队的效率优势。

思考 3：暗知识

图1: LLM LLM对程序员的冲击和影响

大模型的成功很大程度上来自于对已有的互联网文本语料和专业书籍等资料的学习。相对应，在软件工程领域，需要学习的不仅仅是代码，还应该包括需求，设计。

但是，很多需求和设计并不以文档的形式存在，往往会存在于程序员和架构师的脑子里，或者在讨论的过程中。就算有文档，文档和代码大概率不同步。就算文档同步，文档（需求和设计）背后经常有大量的方案对比和推敲，甚至有很多要在原有债务基础上的设计妥协，这些决策过程一般都不会明确地被记录下来。这些没有被文档化下来的知识，我们称其为“暗知识”。

虽然我们说只要有足够的数据，大模型就可以学到需求和设计知识。但这些“暗知识”本身就很难被捕捉到，“足够的数据”这一前提在需求分析和软件设计可能难以满足。

另外，在实际软件开发中，需求可能一次不能表达得很清楚，需要一边开发一边逐步写清楚需求。尤其是敏捷开发更是如此。所以一些通用的，不需要特定领域知识的问题，LLM 的表现会比较好，但是那些专用的，需要特定领域知识（私域知识）的问题，LLM 就可能不是很擅长。

总结来看：“你能想到的多过你能说出来的，你能说出来的多过你能写下来的。”所以这就天然限制了 LLM 能力的上限。

思考 4：Prompt 即代码，代码不再是代码

图5: LLM LLM对程序员的冲击和影响

让我们做个大胆的设想，如果当软件需求发生变化的时候，我们不再是去改代码，而是直接修改需求对应的 prompt，然后基于 prompt 直接生成完整的代码，这个将是软件开发范式的改变。

在这种范式下，我们需要确保代码不能有人为修改，必须都是由 prompt 直接生成，此时我们还需要对 prompt 做版本管理，或许会出现类似今天 git 的 prompt 版本管理的新物种。

此时，从本质上来看 prompt 即是代码，而原本的代码不再是代码了，这就真正实现了基于自然语言（prompt）的编程，此时的编程范式将从 prompt to code 转变为 prompt as code。

更进一步思考，当实现了 prompt as code，我们是否还需要 code，关于代码的很多工程化实践还重要吗？现在我们之所以认为代码工程化很重要，因为代码是人来编写，代码是人来维护的。而当代码由 LLM 来编写，由 LLM 来维护的话，那么现有的软件架构体系还适用吗？这个时候或许才真正实现了软件研发范式的进化。

思考 5：直接可运行，prompt to executable 软件开发范式的可能性

图0: LLM LLM对程序员的冲击和影响