为什么 AI 难以取代软件工程师？
自从 AI 大模型爆火以来，每天的工作中已经有大量的真实代码是通过 AI 辅助完成的。人工智能辅助下的编程，确实大幅减轻了工作负担，大大提高了生产力。然而，大语言模型的成功也在开发者社区中引起了各种猜测，其中最让人关心的莫过于：人工智能是否能够彻底改变我们的行业？程序员的工作是否会彻底被人工智能所代替？
我的观点是：我们的行业将被大模型彻底改变，这毋庸置疑。但是，它只会让真正的软件工程师更加高效，而不是会取代工程师的工作。这不是盲目自信，这个观点来自于一个更为本质的原则。这就是本文我们想讨论的真正的主题：软件工程师的工作不是写代码，而是探索与发现。
01 软件工程师的工作不是写代码
很多软件工程师都戏称自己是'码农'，这不难理解，毕竟代码才是我们真正的工作制品，可以工作的功能通过代码得以表达和体现，脱离了代码，文档等等都并不能真正的表达软件的价值。但是，需要注意的是：软件开发绝不仅仅是编码，编码其实是软件开发中的次要部分。它不过是'开发'活动的最终表达。软件开发的核心，就如同它的名字所表达那样，是'开发'，是从无到有的过程，是持续地探索和发现。
我们的开发工作中，有一半以上的时间，是用来探索我们原本不知道的东西，只有不到一半的时间，是去完成实际的'建造'——无论这个建造指的是文档还是代码。探索和发现包含哪些事情呢？随便列举一些：
- 理解真实的业务目标：需求往往模糊不清，需要工程师主动挖掘背后的商业逻辑。
- 思考能满足业务目标的产品方案：在技术可行性与用户体验之间寻找平衡点。
- 理解用户需求中模糊的细节：将口语化的描述转化为精确的技术规格。
- 思考架构设计的方案：决定系统的扩展性、可维护性和安全性边界。
- 理解既有代码中已经实现了哪些功能：分析遗留系统（Legacy Code）中的约束和陷阱。
- 学习不熟悉的技术框架以及它们的特性：快速掌握新技术栈并评估其适用性。
上面的这些事情，都是探索起来非常费力，但是一旦弄明白就很容易做的事情。这也很类似于缺陷修复中常见的场景：定位问题 3 小时，修复代码 10 分钟。
软件开发有 3 个核心问题：
- 弄清楚解决什么问题
- 设计出合理的解决方案
- 把它构建出来并交付使用
在上述 3 点中，前两点都是'探索与发现'，只有第 3 点，是'建造'。这也是当前的人工智能模型最擅长的地方，也是很可能成为工作主体的地方。前两点，大语言模型能够很有帮助，但是它更多还是辅助角色，成不了主体。AI 无法替代人类对业务上下文的理解和对复杂权衡的判断。
02 最大化探索和发现的效率
大家都在讲研发的提效。真正的提效，不是'建造'的速度有多快，而是在探索与发现上，节省了多少时间。如果项目早期就快速定位了各种问题，从而降低了项目的开发周期，提升了开发质量，这是理想状态。反之，如果在项目早期风平浪静，一切看起来都很正常，直到开始进入集成测试甚至是临近上线阶段，问题大量爆发，项目延期，开发团队和客户都叫苦不迭，这是典型的第二类组织。
最大化探索和发现的效率，是研发效能提升的关键。这意味着我们需要在需求阶段投入更多精力进行验证，利用技术手段提前暴露风险，而不是等到最后才去修补。
03 大模型能帮我们做什么？
我们已经看到了很多通过大模型支持软件编码的工作。这属于软件工程中的'建造'部分。但是，没有好的设计能力，'建造'并不靠谱。在软件工程的历史上，'设计'和'建造'的关系，我们是走过弯路的。在敏捷运动之前，软件工程专家们根据建筑业中的'设计'和'建造'是分离的，就认为软件中的'设计'和'建造'也是可以分离的。这个认知是完全错误的。
为什么建筑行业更多的时候可以区分'设计'和'建造'，而软件几乎完全不可能？这里有两个根本原因：
- 软件的复杂性远远超出一般的人类制品。建筑有物理定律约束，软件有逻辑状态空间约束，后者呈指数级增长。
- 软件价值本质上来自创新，而不是生产。你买了一套房子，所购买的是物质的房子，而不是作为信息的设计师图纸。但是软件不同。软件本身就是信息，本质上软件的生产过程，是信息生产过程。
如果收走了'编码'，就好比一个作曲家没有乐器，一个烹饪专家没有烹调过程来检验菜品设计的效果一样——它减缓的是学习过程和迭代速度。敏捷运动更加强调了代码的价值，这是非常正确的。但是，不可否认，编码还是一个非常琐碎的活动。
编码对于设计师的价值不在于编码活动本身，而是编码带来的学习过程。
那么，究竟有没有办法，在享有编码带来的反馈和学习的同时，可以降低在编码活动上的投入呢？人工智能辅助编程之前，我认为没有这个可能性，但是，今天，这件事已经是完全可能的了：让人工智能完成大多数的编码工作，提升学习和反馈速度，让软件工程师成为真正的软件工程师，而不是软件建造师。
