为什么AI不会夺去软件工程师的工作？

▼

自从AI大模型爆火以来，我每天的工作中，已经有大量的真实代码是通过AI完成的。人工智能辅助下的编程，确实大幅减轻了我的工作负担，大大提高了生产力。

大语言模型是如此成功，以至于无可避免地在开发者社区中引起了各种猜测，其中特别让人关心的莫过于：

人工智能是否能够彻底改变我们的行业？程序员的工作是否会彻底被人工智能所代替？

我的观点是：

我们的行业将被大模型彻底改变，这毋庸置疑。但是，它只会让真正的软件工程师更加高效，而不是会取代工程师的工作。

这不是盲目自信。这个观点来自于一个更为本质的原则。这就是本文我们想讨论的真正的主题：

软件工程师的工作不是写代码，而是探索与发现。

01 软件工程师的工作不是写代码

很多软件工程师都戏称自己是“码农”，这不难理解，毕竟代码才是我们真正的工作制品，可以工作的功能通过代码得以表达和体现，脱离了代码，文档等等都并不能真正的表达软件的价值。但是，需要注意的是：软件开发绝不仅仅是编码，编码其实是软件开发中的次要部分。它不过是“开发”活动的最终表达。软件开发的核心，就如同它的名字所表达那样，是“开发”，是从无到有的过程，是持续地探索和发现。

我们的开发工作中，有一半以上的时间，是用来探索我们原本不知道的东西，只有不到一半的时间，是去完成实际的“建造”——无论这个建造指的是文档还是代码。

探索和发现包含哪些事情呢？随便列举一些：

理解真实的业务目标
思考能满足业务目标的产品方案
理解用户需求中模糊的细节
思考架构设计的方案
理解既有代码中已经实现了哪些功能，有哪些可复用的资产，有哪些约束和陷阱
学习不熟悉的技术框架以及它们的特性
…

上面的这些事情，都是探索起来非常费力，但是一旦弄明白就很容易做的事情。这也很类似于缺陷修复中常见的场景：定位3小时，修复10分钟。

下面的图表达了软件开发中的核心内容：

软件开发有3个核心问题：

弄清楚解决什么问题
设计出合理的解决方案
把它构建出来并交付使用

上图的横轴代表时间，纵轴代表知识，我们在整个的开发过程中，关键问题是知识的增长，也就是“探索和发现”。在上述3点中，前两点都是“探索与发现”，只有第3点，是“建造”。这也是当前的人工智能模型最擅长的地方，也是很可能成为工作主体的地方。前两点，大语言模型能够很有帮助，但是它更多还是辅助角色，成不了主体。

02 最大化探索和发现的效率

大家都在讲研发的提效。真正的提效，不是“建造”的速度有多快，而是在探索与发现上，节省了多少时间。用下图来表示：

上方的曲线和下方的曲线代表来完全不同的两类组织。第一类组织，在项目早期就快速定位了各种问题，从而降低了项目的开发周期，提升了开发质量。第二类组织，往往在项目早期风平浪静，一切看起来都很正常，直到开始进入集成测试甚至是临近上线阶段，问题大量爆发，项目延期，开发团队和客户都叫苦不迭。

我们肯定都希望能形成第一类组织，而不是第二类组织。但是现实的情况恰恰相反，第二类组织仍然是当前的主流。只要看一下下面的漫画在现实中的普及程度，就知道现状究竟如何了：

最大化探索和发现的效率，是研发效能提升的关键。

03 大模型能帮我们做什么？

我们已经看到了很多通过大模型支持软件编码的工作。这属于软件工程中的“建造”部分。但是，没有好的设计能力，“建造”并不靠谱。

在软件工程的历史上， “设计”和“建造”的关系，我们是走过弯路的。在敏捷运动之前，软件工程专家们根据建筑业中的“设计”和“建造”是分离的，就认为软件中的“设计”和“建造”也是可以分离的。这个认知是完全错误的。

为什么建筑行业更多的时候可以区分“设计”和“建造”，而软件几乎完全不可能？这里有两个根本原因：

软件的复杂性远远超出一般的人类制品。
软件价值本质上来自创新，而不是生产。

这个话题很宏大，我们不在这里展开，仅仅简单描述。建筑也很复杂，但是大多数情况下的建筑，都有较为成熟的样本，但是它必须被一次次的生产，才能带来价值。你买了一套房子，所购买的是物质的房子，而不是作为信息的设计师图纸。但是软件不同。软件本身就是信息，本质上软件的生产过程，是信息生产过程。如果收走了“编码”，就好比一个作曲家没有乐器，一个烹饪专家没有烹调过程来检验菜品设计的效果一样——它减缓的是学习过程和迭代速度。

敏捷运动更加强调了代码的价值，这是非常正确的。但是，不可否认，编码还是一个非常琐碎的活动。