AI 为什么还没取代软件工程师

正文

关于 AI 替代工作，焦虑和不确定性都很强。我们怎样才能越过那些模糊警告和夸张预测，用数据来讨论这个问题？一个好办法，是观察 AI 能力推进最远、采用速度也异常快的职业：软件工程。

本文中，我们认为已经有足够证据可以反驳这样一种叙事：一旦 AI 能力达到某个阈值，就会造成大规模裁员。既然这在一个监管壁垒很少的行业里都成立，那么大多数其他职业很可能会受到更多缓冲。

我们也大致理解为什么会这样。很多知识工作，包括软件开发，都可以看成一个“决策-执行-交付三明治”（decide-execute-deliver sandwich）。AI 压缩的是“执行”层，也就是三明治中间那层；但另外两层会抵抗自动化，而且这种抵抗不会单靠能力提升就消失。

我们的结论，是对软件工程需求未来走势保持谨慎乐观。本文是一个系列的第一篇，下一篇会讨论为什么即便整体需求健康，单个软件工程师的职业道路仍然可能变得颠簸。这个系列基于经济学和软件工程领域的已发表文献、我们自己对 AI agent 的评估和观察，以及许多软件工程师对 AI 影响其职业当下与未来的反思。这些反思既来自公开文章，也来自我们与社区的互动。

软件行业里那些 AI 驱动大裁员的故事，看起来像经典的 “AI washing”

先看三个上过头条的故事，以及它们和现实之间的落差：

• 2 月，金融科技公司 Block，也就是 Cash App、Square、Afterpay 等应用的开发商，因为创始人 Jack Dorsey 所说 AI 正在“带来一种新的工作方式”，让团队变得“更小、更扁平”，宣布裁员 4000 人。他还特别提到 2025 年末模型能力的改进。但后续报道揭示的是完全不同的画面：公司在疫情期间员工数增长超过三倍，此后承受巨大财务压力。Cash App 团队的一位数据科学家 Naoko Takeda 发帖说，Block “把 AI 硬塞进每个人喉咙里”，但她看到的“生产力提升非常有限”。她拒绝了 75% 的留任加薪并选择离职。其他受访员工对 AI 在 Block 能做什么也有很不一样的理解，他们认为，当时 AI 还达不到替代被裁员工的水平。Dorsey 的一位朋友兼科技行业 CEO Aaron Levie 评论说，Block “可能比其他任何公司都更容易利用 AI 来替代人工”，因为它“有非常强的工程师文化”。我们更愿意把这看成 AI 驱动裁员叙事里一个暴露漏洞的点，而不是支撑它的证据。

• 4 月，Snap 裁掉约 1000 人，CEO Evan Spiegel 在裁员备忘录中主要把原因归给 AI。他还说，AI 生成了65% 的新代码。现实里，这次裁员发生在一位激进投资者要求削减成本的行动之后。（Snap 自 2017 年 IPO 以来每个完整财年都在净亏损，2026 年股价也下跌超过 30%。）很能说明问题的是，裁员的性质，比如增强现实部门多个岗位共 150 个职位被裁，并不符合如果裁员真由 AI 驱动我们会预期看到的模式，也就是不会集中在某个部门，而会横跨编程和其他“AI 暴露度”高的岗位。

• 5 月，Intuit 宣布裁员 3000 人，同时和 Anthropic、OpenAI 达成合作。媒体把两件事连在一起，将裁员包装成 AI 驱动的重组。这一次，CEO 反而反驳了这个省事的叙事，说这些裁员“和 AI 没有任何关系”，裁掉的是“协调负担重的岗位”和过多的管理层级。

我们不是专挑这些例子。在我们检查过的每一个 AI 驱动软件工程裁员故事里，同样的叙事违例都会出现。事实证明，拿 AI 来包装裁员是一种全经济范围的现象，许多调查都能证明这一点：

• 59% 的美国招聘经理承认，在解释招聘冻结或裁员时，他们会强调 AI，因为相比承认财务约束，这套说法更容易被利益相关方接受。

• Forrester 首席分析师 J. P. Gownder 在谈到那些准备进行所谓 AI 驱动裁员的公司时说：“当我们问他们是否已经有成熟、经过验证的 AI 应用可以接手这些工作时，十次里有九次，答案都是否，而且他们甚至还没开始。”

• 在一项覆盖 1000 多名全球高管的 HBR 调查中，21% 的人表示已经“出于对 AI 的预期”进行了大规模裁员，另有 39% 表示已经进行过低到中等程度的预期性裁员。相比之下，只有 2% 的人已经因为实际 AI 落地进行了大规模裁员。这个 10 倍差距说明，高管和其他人一样，很容易被 AI 替代工作的误导性叙事带着跑。

另一个有意思的数据点来自 WARN Act（《工人调整和再培训通知法案》），它要求某些工厂关闭和影响超过 100 名员工的大规模裁员必须披露。2025 年 3 月，纽约成为美国第一个在 WARN Act 申报中加入 AI 披露勾选框的州。在完整的第一年里，超过 160 家公司提交了 WARN 通知。没有一家勾选 AI 框。我们联系了纽约州劳工部，对方确认截至 5 月下旬，只有一家公司 Nespresso 勾选了这个框。如果这些申报准确，那么在相关期间纽约州约 25000 名被裁员工中，只有 46 人，也就是大约 0.2%，受到了 AI 影响。

对 AI 驱动大裁员叙事来说，更致命的是：裁员本来就是衡量 AI 潜在生产率收益的错误信号！研究很清楚地表明，这种影响是通过“招聘放缓，而不是离职增加”发生的。解雇现有员工，恰恰会损失那些能让员工有效使用 AI 的默会知识和组织资本。更不用说，裁员还会带来遣散费、士气受损和重新招聘风险等成本。考虑到这些成本，既然自然流失在几年内也能达到同样效果，大规模裁员通常没有必要。

那么，如果我们不只看裁员，而是看整体就业趋势，数据会告诉我们什么？美联储经济学家的一篇重要论文汇总了美国情境下的证据。软件工程师就业仍在增长，但他们发现，与没有 AI 的反事实情境相比，ChatGPT 之后增长速度变慢了，每年大约慢 3 个百分点。这项研究的一个重要限制是，方法无法捕捉自雇就业，所以也可能有一部分增长放缓被创业吸收了。我们确实有其他研究表明 AI 会让创业更容易。所以真实图景可能比美联储研究显示的还要健康。

最后，也应该承认软件工程领域确实存在两类间接由 AI 驱动的工作损失，但它们不同于 AI 替代软件工程师。第一类是，AI 有时会摧毁某个产品的需求，比如 Chegg（作业帮助）或 Stack Overflow（技术帮助），这两家公司都裁过员。AI 并没有直接做这些员工原来做的工作，而是让那种需求本身消失。历史上的类比很强：1950 年美国人口普查中的 270 种职业里，只有一种工作被自动化直接消灭了，那就是电梯操作员。但还有许多职业是被新技术淘汰的，比如电报员。

另一个可信的 AI 驱动裁员故事，出现在卖 AI 的公司，而不是买 AI 的公司。所以当 IBM 或 SAP 这样的公司宣布因为 AI 裁员时，更准确的说法是：“我们把员工编制从传统职能重新分配到增长最快的产品线上。”这是围绕收入机会展开的普通企业重组，不是技术替代员工。

为什么 coding agent 还没有导致劳动力替代：决策-执行-交付三明治

很多科技领导者，比如上面提到的 Snap CEO，会一边报告由 AI 写出的代码比例，一边谈裁员或预测未来工作岗位损失。这会喂养一种过于简单的心智模型：一旦 AI 能写所有代码，就不再需要程序员了。好在，这个模型是错的。所谓 AI 写代码比例这个指标，几乎完全脱离了劳动力替代真正关心的问题。原因在这里。

写代码不是瓶颈，而且从来都不是。比如，一篇 2019 年论文总结已有研究后得出结论：“开发者花在编码上的时间少得惊人，根据不同研究，比例在 9% 到 61% 之间”。这和论文自己从 6000 名微软开发者那里得到的数据一致。随着 coding agent 开始被采用，2025 年末出现了一大批博客文章，开发者们意识到，让 agent 写大部分代码，对整体生产力影响很小，于是纷纷指出写代码不是瓶颈。

如果写代码不是瓶颈，那什么才是？任务拆分调查会指向会议或调试之类的东西。但这只会带来更多问题：开发者在那些会议里到底做什么，为什么 AI 不能做？随着能力提升，调试难道不会被自动化吗？要理解真正的瓶颈，我们必须进入定性层面，挖一挖软件工程师自己对哪些工作抵抗自动化的理解。

当我们做这项分析时，浮现出三个真正瓶颈：（1）决定并明确要构建什么；（2）验证并为交付物负责；（3）执行前两项都需要的深层人类理解，也就是对代码库、业务和环境的理解。

也就是说，软件工程师的工作由一个“决策-执行-交付”三明治组成，而理解是这三层的前提。AI 已经压缩了三明治中间那层，但两端基本没变。只要软件开发团队仍然负责决策，并且要对交付物负责，工程师就仍然需要花时间建立对系统的深层理解。这就是三个瓶颈。

图：软件开发由三层组成：（1）决策，问题定义、规格说明、规划；（2）执行，设计与实现；（3）交付，测试、验证、集成、维护等。注意，这些是概念层，不是时间阶段。在一个项目过程中来回切换非常常见。

三明治模型解释 AI 生产率影响的证据，来自最近一篇论文《Writing Code vs. Shipping Code》。研究者分析了 GitHub 上 10 万名开发者，发现 AI agent 让代码行数增加了 8 倍，这和 AI 几乎完全压缩三明治中执行层的想法一致。但发布数量只增加了 30%，这强烈暗示人的瓶颈，也就是决策层和交付层，依然存在。

这个三明治还能继续被压缩吗？我们不这么认为。在流水线的一端，开发团队需要决定构建什么。初级软件工程师学到的最重要经验之一，是需求规格说明，这个行业黑话对应的就是这一层，耗时长得惊人；如果强行压缩，后面会痛苦得多。这一层很难自动化，因为它需要思考用户需求、市场信号、组织优先级，有时还要考虑监管约束。

随着 AI 能力提升，可以委托给 AI 的决策类型会随时间增加。但这不会让“决策”层变薄。一旦某个决策可以委托给 AI，它就不再是竞争优势的来源，人类决策的价值会继续向上迁移。软件复杂性会随时间增加，所以这个过程没有天花板。

在三明治的另一端，人类团队需要为交付物负责。也许未来某一天，团队会在没有充分测试和理解的情况下交付任务关键型代码，但今天的 AI 仍然非常不可靠，这样草率的做法会对软件团队及其客户构成生存级威胁。

即便未来技术障碍消失，我们也不必把控制权交给 AI。AI as Normal Technology 的一个核心洞见是，我们可以通过共同规范、法律和政策，集体选择让人类继续承担责任。相比试图减缓技术能力发展，这是一种更有韧性的方式，既能控制 AI 影响扩散的速度，也能提升安全性。这些速度屏障已经很大程度上存在于责任法和行业监管中，但还可以进一步加强。

在这个图景里，随着越来越多执行层工作被委托给 AI，未来软件工程师的角色会变得有点像吊车操作员。AI agent 会完成大部分认知重活；监督 agent 并让它保持可控，会成为人类工作的大部分。

有评论者认为，一个让人类保持控制的未来不太可能，因为付钱请人这么做成本太高。已经有一些关于缺乏监督的 coding agent 删除生产数据库或造成其他类型损害的病毒式故事。但我们认为，这些更像“人咬狗”故事，而不是正在形成的新常态。它们之所以会病毒式传播，正是因为这种行为不负责任又不寻常，带有冲击力，同时也会反复提醒和教育社区，帮助大家警惕过度依赖 AI。就像那句格言说的，“如果它上了新闻，就不用太担心”。不过，如果想检测高风险任务中缺乏监督地使用 AI 的情况是否在增加，这本身也很有价值，而且应该放到整个经济范围内观察，不只看软件工程。

顺便说一句，三明治被压扁并不是一个新趋势，也不是 AI 独有的结果。20 多年前，美国劳工统计局开始把编程和软件工程分开统计。粗略地说，程序员只负责执行，而软件工程师管理的是三明治里更大的一部分。编程岗位不只一直在萎缩，薪资也低得多，因为它被视为苦力活。AI 只是加速了这个早已存在的趋势，进一步降低纯技术技能的价值。

软件工程与程序员就业对比。图表来源：The Washington Post。

这种模式，也就是即便 AI 越来越多地自动化中间层，人类仍然深度参与决策-执行-交付三明治两端，似乎广泛适用于大多数知识工作，只是在软件领域推进得最远。毕竟，复杂决策和责任承担在大多数领域都很常见。人们没有认识到这个现象，导致了许多关于工作岗位即将消失的过度自信预测，比如 AI 替代放射科医生的预测。

Vibe coding 不是 agentic engineering

围绕软件工程到底正在发生多大变化，人们之所以困惑，其中一个原因是“vibe coding”这个词被草率地用来指代一大堆实践。这个光谱的两端在概念上完全不同，而且相似之处远少于差异。

真正的 vibe coding 里，用户只是告诉 agent 要做什么，agent 运行时不监督，不审查代码，甚至可能没有审查代码的技能，也不评估输出，最多只是看到东西明显坏掉时注意一下。

这和大多数软件工程师实际使用 agent 的方式形成对照。后者把 agent 当工具使用，人类仍然保持控制，并为输出负责。好在，agentic engineering 这个词正在变得流行，用来描述这种实践。

随着 agentic engineering 成为常态，工程师正在发现，监督 coding agent 出乎意料地耗时间。比如，知名开发者、AI 转型记录者 Simon Willison 曾提到，他因为监督 agent，到上午 11 点就已经精神疲惫。这也符合我们的经验。

更多定量证据来自 SWE-chat，这是一个由开源开发者自愿接入日志工具而形成的 coding agent 交互数据集。研究发现，agent 生成的代码只有 44% 会进入用户提交；vibe-coded commit 引入漏洞的比例是纯人工 commit 的 9 倍；最常见的用户意图是理解已有代码，而不是生成新代码（19% 对 13%）。这个数据集存在自选择问题，所以我们不能只凭这项研究得出强结论，但它确实强化了许多其他证据：vibe coding 和 agentic engineering 的模式非常不同。

Agentic engineering 不是 vibe coding。

再强调一次，它们不是两个截然不同的类别，而是一条光谱的两端，中间地带很模糊。不是每个项目都要么是一次性小玩具，要么是任务关键型系统。不是每个工作流都能精确落在表格左列或右列。但对就业问题来说，关键含义仍然很稳：公司不能用不合格的 vibe coder 替代软件工程师来交付生产软件。

未来会怎样？

AI 乐观派可能会说，大规模裁员正在路上；它们还没发生，只是因为人类水平的软件工程能力刚刚出现，或者还没真正实现。但如果三明治模型是对的，这些预测就不会成真。AI 已经大幅压缩了三明治中间层，而且这种压缩实际上几十年前就开始了。所以，即便执行层变得即时且完美，相比现状也只是一个小变化。另外两层抵抗 AI 的原因，并不是能力不足。

事实上，软件工程岗位不但不会因为 AI 消失，软件工程师需求甚至可能增加。当软件，或者任何东西，因为技术生产率提升而变得更便宜时，人们会购买更多软件。用经济学黑话说，软件具有很高的“价格弹性”。而正如我们已经论证的，AI 不会替代软件工程师，也就是“替代弹性”很低，所以对更多软件的需求会转化为对更多软件工程师的派生需求。一个相关性没那么强但更抓眼球的经济学术语“杰文斯悖论”（Jevons’ paradox），在 AI 讨论里经常被拿来描述这个概念。

从历史上看，模式就是这样：美国程序员就业从 1950 年前后的接近零，增长到今天的数百万人。这和农业等职业形成鲜明对比，后者的劳动力需求因为机械化和自动化而被大幅摧毁。区别在于，人们摄入的热量大体是固定的，即便增加 25% 也会导致肥胖流行；而软件产量已经增长了一百万倍。现代汽车的各类车载计算机里，大概跑着上亿行代码。

如果代码需求存在天花板，我们离它还远得很。几乎所有认知工作都会从软件中受益。随着 AI 让编码变便宜，人们正在创造各种以前没必要做的一次性工具，不管是工作用途还是个人用途。

说清楚一点，虽然我们认为未来会有多得多的软件，也很可能有更多软件工程师，但这不代表大型科技公司会变得更大。如今，大多数软件工程师已经在非软件公司的内部团队工作，未来这个比例还可能继续增加。然后还有“AI rollups”这个想法，指的是风投或私募股权公司收购“主街”生意，比如牙科诊所、会计事务所之类，然后通过把软件工程师或 AI 工程师嵌入这些业务，从头开始把它们重建成“AI-native”。当然，最后它也可能只是炒作。现在判断还太早。

有些人预测，软件工程技能需求会因为民主化而下降。他们承认，未来软件产出会比以往任何时候都多，花在生产软件上的人类时间也会比以往任何时候都多，但这项工作会由不是软件工程师的人来做。这个想法是，AI 会把软件工程民主化到这样的程度：比如法律软件，可以由受过法律训练的人，而不是受过软件工程训练的人，更轻松地创造出来。

也许吧。但我们会押注反方向。在我们看来，这和把 vibe coding 混同于 agentic engineering、把执行层混同于整个决策-执行-交付三明治，是同一个陷阱。事实上，当我们回看编程史时，这类“我们正站在民主化门槛上”的说法一直存在。FORTRAN、COBOL、SQL 这些老语言在推出时，都伴随着非常突出的类似希望。但它没有发生。真正的门槛并不是学习语法，而是拥有足够熟练的判断力，能做出好决策，同时维持责任能力。

到头来，这个区别也许只是语义问题。看起来很清楚的是，人们花在让计算机做新事情上的时间会持续增加。这可能表现为构建软件，或者用 agent 管理复杂工作流，或者其他什么形式。它会要求软件技能、AI 技能和领域专业知识的混合。今天的软件工程师能否最好地适应并填补这些新角色，还有待观察。

关于适应的最后这一点，为本系列下一篇文章做了铺垫。软件领域的总劳动需求可能保持强劲，并不意味着大多数个体劳动者不会受到影响。我们会论证，AI 将给软件生产方式带来巨大的结构性变化，而这种变化会严重影响哪些软件工程师会受益、哪些会受损。这取决于他们所在公司的类型、地理位置、资历，以及他们适应的速度。

原文：https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers