LLM对程序员的冲击和影响 _LLM

作者 | 茹炳晟，腾讯 Tech Lead
1 LLM 在软件开发过程中的单点提效
LLM 对软件研发的单点提效，我之前录制过一段视频，大家可以直接观看，里面有详细的演示，我在这里就不再赘述了。
除此以外，我这里罗列一些更多的可能用途：智能代码提示
代码片段智能生成
SQL 语句的智能生成与调优
更高效更精准的静态代码检查与自动修复（非 rule-based）
智能辅助的代码评审与代码重构
单元测试和接口测试代码的自动生成
更高级的重复代码检查（语义重复检查）
失败用例的自动分析与归因
更精准的技术问答
…
看到这里，你有可能会得出一个结论：完蛋了，程序员要大面积失业了。真的是这样吗？要回答这个问题，我们需要从全局来看问题，首先我们要搞清楚，LLM 对于软件研发，什么变了？什么没有变？
2 LLM 对于软件研发，什么变了？
看了上面的案例，你应该已经能够体会到 LLM 对于软件研发单点效率提升的各种可能性，这些能力让我们看到了软件研发的变化，我把这些变化总结为：基础编码能力的知识平权，进而带来局部效率的提升。

文章插图
以前工程师个体学习掌握一门计算机语言以及相应的数据结构和算法，需要较长的学习周期，很多经验和模式还需要工程师个体在大量实践中进行总结，每个工程师个体都在重复着这个过程，现在 LLM 让一个没有接受过系统培训的个体也能拥有同样的能力，个体和个体之间的能力差异被 LLM 拉平了，这就是知识平权。
如果说 ChatGPT 实现了数字时代知识的平权，codex 类的代码语言大模型实现了基础编码能力的知识平权，进而带来软件研发的局部效率提升。
可以说，LLM 降低了软件开发的门槛，可以让更多对软件开发感兴趣的人更加轻松地参与到软件开发工作中，同时，LLM 提高了编程的效率和质量，使我们可以在更短的时间内完成更多的工作，因而能留出更多的时间让我们思考。
前段时间，前哈佛大学计算机科学教授，曾在 google 和 Apple 担任高级工程职位的 Matt Welsh 发表了一个视频，其中的主要观点是“LLM 将会代表着编程的终结”，他认为程序员会被淘汰，未来只有产品经理和代码审查员。我不知道大家对这个怎么看？
我的观点是，在抱有敬畏之心的同时，我们不要轻易下结论。为什么，因为软件研发还有很多东西是没有变的，而这些没有变的才是软件工程中的核心问题和主要矛盾。
3 LLM 对于软件研发，什么没有变？
我们面对的是软件工程的问题，编程不等于软件工程，编程只是软件工程的一部分。软件工程的四大内在特性（复杂度、不一致性、可变性、不可见性）并没有因为 LLM 的出现而发生本质上的变化，这才是软件工程面临的主要矛盾。

文章插图
从复杂度的角度来看，问题域本身的复杂度并没有变，本质复杂度也没有变，变的可能只是一部分的随机复杂度。虽然说局部编码变简单，或者说更高效了，但是需求分析和软件设计并没有因为 LLM 而变得简单，这个稍后我们来详聊。
从一致性的角度来看，由于软件研发的本质依然是“知识手工业者的大规模协作”，所以我们非常需要一致性。如果系统是一致的，则意味着相似的事情以相似的方式完成，错并不可怕，怕的是错的千变万化。LLM 的出现并没有提升软件研发的一致性，甚至由于 LLM 本身的概率属性，使用 LLM 实现代码生成的不一致性问题反而是被放大了，这点我们后面展开讲。
从可变性的角度来看，软件会随着需求不断演进和变化，所以架构设计和模块抽象只能面向当下，它天然是短视的，或者说是有局限性的，这种局限性即使是最优秀的架构师也是不可逾越的。
在敏捷开发模式下这个问题更被凸显了出来，而且需求本身就是零散的，目标也是模糊的，在没有全局视图的情况下，架构自然就是有局限性，所以需要不断迭代变更。每个迭代，你能拿到的信息仅仅是宏大视图中的小小一角，根本没有全貌，LLM 对此也是无能为力的。
从不可见性的角度来看，软件的客观存在不具有空间的形体特征，不同的关注点，会有不同的图。综合叠加这些图是困难的，而且强行可视化的效果会造成图的异常复杂，反而失去了可视化的价值。设计无法可视化就限制了有效的沟通和交流。