为什么 AI 不会取代软件工程师：'决定-执行-交付' 三明治模型

AI 不会取代软件工程师，因为虽然它可以自动化编写代码的行为，但它无法自动化“决定构建什么”以及“对交付负责”这些高阶功能。当前的“AI 驱动裁员”浪潮在很大程度上是高管们用来掩盖财务约束的叙事，而实际的就业趋势表明，由于软件的高价格弹性，软件工程的需求仍然具有韧性。

AI 驱动裁员的迷思

科技行业中许多备受瞩目的裁员在公开声明中被归因于 AI，但内部数据和报告往往揭示了不同的驱动因素。在一些案例中，CEO 们引用 AI 作为裁员的原因以满足利益相关者，这种做法被称为“AI 洗白 (AI washing)”。

Block: 宣布裁员 4,000 人，理由是利用 AI 实现“更小、更扁平的团队”，但随后的报告表明，该公司在疫情时期的过度招聘后面临巨大的财务压力。
Snap: 引用 AI 作为裁员 1,000 人的原因，声称 AI 生成了 65% 的新代码，但裁员紧随在激进投资者要求削减成本的需求之后。
Intuit: 虽然媒体将 3,000 人的裁员定性为 AI 驱动的重组，但 CEO 明确表示，裁员针对的是协调密集型角色和管理层，而非 AI 的实施。

来自纽约 WARN Act 备案文件的数据支持了这一点。在为大规模裁员添加 AI 披露复选框后的第一年里，几乎没有公司勾选该选项，这表明实际由 AI 驱动的岗位置换仅是公开叙事中的一小部分。

要理解为什么 AI 无法取代软件工程师，有必要区分 编码 (coding) 与 软件工程 (software engineering)。作者提出了一个开发的“三明治”模型：

AI 有效地压缩了执行层。对 100,000 名 GitHub 开发者进行的研究显示，AI agent 导致编写的代码行数增加了八倍，但实际发布的版本数量仅增加了 30%。这表明，人类的瓶颈——决定什么是正确的以及验证其是否有效——仍然是生产力的主要约束。

专业人士使用 AI 的方式与业余爱好者不同，这决定了工程师的职业安全性：

Vibe Coding: 用户告诉 agent 应该做什么，并在没有经过严格审查或具备评估能力的情况下直接接受输出。这种方法在生产环境中容易产生漏洞和失败。
Agentic Engineering: 工程师将 AI 作为工具，保持控制权并对输出负责。这个过程通常在精神上非常疲惫，因为监督 agent 需要深厚的系统理解力，以防止 AI 追求“死胡同路径”。

来自 SWE-chat 数据集的证据显示，只有 44% 的 agent 生成的代码能进入最终的用户提交 (commits)，且“vibe-coded”的提交引入漏洞的频率是仅由人类编写的代码的九倍。

AI 提高效率并不会摧毁这个职业，反而可能通过类似于杰文斯悖论 (Jevons' Paradox) 的现象增加对软件工程师的需求：随着软件生产成本的下降，对软件的需求量会随之增加。

从历史上看，世界对软件的需求是无穷无尽的的。随着编码变得更加廉价，组织会创建更多以前因成本过高而无法构建的一次性工具和复杂系统。这表明，虽然开发者与代码行数的比例可能会发生变化，但对于能够管理“决定”和“交付”层的熟练工程师的需求总量将会增长。

虽然软件工程的总体需求仍然强劲，但个人经验各异。社区讨论突出了以下风险和细微差别：

领域置换: 一些人认为，使用 AI 的通才可能会取代在狭窄领域（例如前端 Web 开发）工作的专家。
Greenfield Automation: 一些开发者报告称，“greenfield”项目（从零开始的项目）现在变得显著更快，减少了初始构建阶段所需的人员数量。
问责制缺口: 一个反复出现的问题是，组织需要一个“背锅侠”或持证专业人员来为关键任务代码签署确认，而 AI 无法承担这一角色。

"如果你的大脑可以理解它，你就可以在 1/100 的时间内将其推向世界……我觉得自己扮演着通用层，即业务目标与技术实现之间的翻译官角色。" — 社区贡献者

最终，软件工程师的角色正在从手动编码者转变为认知 agent 的监督者，强调判断力、架构设计和问责制，而非仅仅是语法。