为什么 AI 还没有替代软件工程师：真正难的是交付责任

“AI 会不会替代软件工程师”这个问题，很容易被讨论成两个极端。

一种说法是：模型已经会写代码了，程序员很快会被大规模替代。另一种说法是：AI 写的代码不可靠，所以不用在意。

这两个说法都太粗。

Arvind Narayanan 和 Sayash Kapoor 在 AI as Normal Technology 上发布的《Why AI hasn’t replaced software engineers, and won’t》提供了一个更有解释力的框架。他们认为，软件工程不是单纯写代码，而是一个 decide-execute-deliver 的结构：决定做什么，执行实现，交付并对结果负责。

AI 的确正在压缩中间的 execute 层，也就是写代码、改代码、跑命令、生成候选方案这些工作。但两端的 decide 和 deliver 仍然很厚，而且不会因为模型能力提升就自动消失。

先把“AI 裁员”叙事拆开

文章首先提醒：很多所谓“AI 导致软件岗位裁员”的故事，并不一定能经得起细看。

公司裁员可能来自成本压力、疫情后扩张回调、投资人要求、组织层级过厚、业务线调整，也可能来自某个产品被 AI 改变需求结构。把所有裁员都归因于 AI 替代工程师，是一种过度简化。

NormalTech 文章列举了多组信号。比如纽约州在 2025 年 3 月开始让 WARN Act 申报增加 AI 披露项，但第一年里几乎没有公司勾选 AI。文章还引用研究指出，AI 对就业的影响更可能表现为招聘速度放缓，而不是直接大规模解雇现有员工。

这里的关键不是说“AI 没有影响”。恰恰相反，AI 已经在影响软件行业。关键是影响方式不是一句“AI 替代程序员”能概括的。

它更像是：代码生产成本下降，某些纯执行工作贬值，团队更重视能够定义问题、理解系统、验证结果和承担责任的人。

软件工程不是把代码打进电脑

很多人误判 AI 对程序员的影响，是因为他们把软件工程等同于写代码。

但真实工作里，写代码只是其中一部分。一个需求从出现到上线，中间有大量工作不只是“生成代码”：

• 用户真正的问题是什么；
• 这个问题是否值得现在解决；
• 需求边界在哪里；
• 旧系统里哪些路径会被影响；
• 数据、权限、性能、安全有什么约束；
• 怎么验证结果真的可用；
• 上线失败怎么回滚；
• 谁对最终行为负责。

AI 能帮忙写实现，也能帮忙查资料、读日志、补测试、整理方案。但它不能自动承担组织里的责任，也不能替团队决定什么才是正确取舍。

更现实的情况是：AI 让人更快拿到候选实现，然后人要更快、更严肃地判断这些实现能不能交付。

decide-execute-deliver：为什么中间变薄，两端仍然很厚

NormalTech 的 decide-execute-deliver 模型很好用。

第一层是 decide：决定做什么。

这包括需求澄清、问题定义、优先级判断、方案选择、和利益相关方对齐。AI 可以给建议，但最终判断依赖业务背景、用户理解、组织约束和风险偏好。

第二层是 execute：执行实现。

这是 AI 最擅长压缩的部分。写函数、改组件、生成 SQL、补单测、跑脚本、整理文档，这些任务会越来越多地交给 agent。

第三层是 deliver：交付结果。

这包括测试、验证、集成、上线、监控、修复、维护和责任承担。AI 可以参与每一步，但团队不能把最终责任外包给模型。

一个最直接的例子是：AI 可以写出一大段看起来合理的代码，但如果没有测试、没有人理解业务规则、没有回滚方案，它就不能算“已交付”。它只是“已生成”。

软件工程的核心不是生成，而是交付。

为什么 AI 代码越多，工程师越不能缺席

如果 AI 让代码产量提高，工程师是不是就少一些？

短期看，一些只做重复实现的人确实会被挤压。但从工程系统角度看，代码产量提高还会带来新的工作：

• 更多代码需要审查；
• 更多变更需要测试；
• 更多设计需要统一；
• 更多边界条件需要覆盖；
• 更多线上行为需要监控；
• 更多技术债需要管理。

如果团队只是让 AI 多写代码，而没有同步提高验证和维护能力，结果可能不是效率提升，而是维护成本膨胀。

这也是很多团队在使用 coding agent 后很快遇到的问题：一开始感觉很快，过一段时间发现 review 更累、上下文更乱、修复更难、团队更难解释为什么这样改。

所以，真正成熟的 AI 编程不是“让 AI 写得更多”，而是“让 AI 进入受控的工程闭环”。

vibe coding 和 agentic engineering 不是一回事

文章还区分了两个经常被混在一起的概念。

vibe coding 更像是：告诉 AI 大概想要什么，然后不认真监督、不读代码、不验证结果，看到页面差不多能跑就算完成。

agentic engineering 则不同：人仍然保持控制，明确目标、约束、验收标准和风险边界；AI 负责执行大量具体任务；最后由人审查、验证和负责。

这一区分很重要。

如果把两者混为一谈，就会得出错误结论：要么觉得 AI 编程全是玩具，要么觉得工程师不再需要存在。

更准确的判断是：vibe coding 适合低风险原型、个人探索和一次性工具；agentic engineering 才可能进入长期项目、团队协作和生产系统。

普通开发者的应对方向

如果你是开发者，这篇文章的结论不是“躺平”，而是“换重心”。

第一，继续用 AI，但不要只练提示词。

真正有价值的是把 AI 接进你的开发闭环：需求拆解、代码生成、测试补齐、失败分析、日志解释、文档更新、review 清单。

第二，提高系统理解能力。

AI 可以读代码，但你要知道哪些模块关键、哪些路径不能乱动、哪些历史坑不能踩。一个只会让 AI 改代码但不理解系统的人，会越来越危险。

第三，训练验证能力。

未来的好工程师不是“从不使用 AI 的人”，而是“能证明 AI 产出可靠的人”。你要会写测试、跑构建、设计手测路径、看日志、确认线上指标。

第四，保留责任意识。

AI 给出的结果不能替你承担责任。上线的是你的系统，出问题的是你的用户，review 的是你的团队。

小团队的采用建议

对小团队来说，AI 编程工具仍然非常值得用，但要建立几条硬规则。

每个 agent 任务都要有清晰边界。不要把“优化一下系统”交给 agent，而要改成“给这个接口增加参数校验，并补一个失败用例”。

每个 agent 结果都要有验证证据。构建是否通过，测试是否通过，页面是否手测，日志是否正常，要留下明确记录。

每个大改动都要有人类 owner。谁定义目标，谁批准上线，谁负责回滚，都要清楚。

每次失败都要沉淀成规则。AI 犯错不可怕，可怕的是同样的错误每天重复。

鲲鹏 AI 观察

这篇 NormalTech 文章最值得带走的一句话不是“AI 不会替代工程师”，而是：AI 改变的是软件工程的分工结构。

会写代码仍然重要，但它不再是唯一护城河。更重要的是：

• 你能不能决定该做什么；
• 你能不能把问题讲清楚；
• 你能不能判断 AI 的方案是否靠谱；
• 你能不能验证结果；
• 你能不能把系统长期维护住。

AI 会让单纯执行型技能变便宜，也会让真正懂交付的人更重要。

所以，普通开发者不需要假装 AI 没有威胁，也不需要相信“程序员马上消失”。更务实的做法是：把 AI 当作执行层杠杆，同时把自己训练成更强的判断者、验证者和系统负责人。

参考来源

• AI as Normal Technology: Why AI hasn’t replaced software engineers, and won’t
• Simon Willison: June 14, 2026 archive note on the essay
• Artificial Analysis: Cursor’s Composer 2.5: third on the Coding Agent Index and ~10-60x lower cost than rivals