为什么 AI 没有、也不会取代软件工程师
关于 AI 取代就业的焦虑和不确定性正在蔓延。我们该如何摆脱那些模糊的警告和夸大的预测，用数据来回答这个问题？一个很好的切入点是看看 AI 能力最为领先、应用也极为迅猛的行业：软件工程。
本文中，我们认为现有证据足以驳斥这样一种叙事——即一旦 AI 能力突破某个临界点，就会引发大规模裁员。考虑到软件行业几乎不存在什么监管壁垒尚且如此，其他大多数职业受到的缓冲只会更大。
我们也已经比较清楚地理解了背后的原因。我们可以把包括软件开发在内的许多知识工作，看作一个"决策—执行—交付"的三明治结构。AI 压缩了中间的"执行"层，但另外两层对自动化的抵抗力很强，仅靠能力提升是无法突破的。
最后，我们对软件工程需求的未来走向持谨慎乐观的态度。本文是系列文章的第一篇，下一篇将讨论为什么即便整体需求健康，个体软件工程师的职业道路仍可能崎岖不平。本系列的依据包括经济学和软件工程领域的已发表文献、我们自身对 AI 智能体的评测和观察，以及众多软件工程师对 AI 之于本行业当下与未来影响的反思——这些反思既来自他们的公开著述，也来自我们与社区的交流。
所谓 AI 引发软件业大规模裁员的故事，大概率是典型的"AI 洗白"
来看三个登上新闻头条的故事，以及它们与现实的反差：
今年二月，金融科技公司 Block（旗下产品包括 Cash App、Square、Afterpay 等）宣布裁员 4,000 人。据创始人 Jack Dorsey 解释，AI 正在"催生一种全新的工作方式"，让团队"更小、更扁平"，并明确提到了模型能力在2025 年末取得的进步。
但后续报道揭示了截然不同的情况。在疫情期间员工人数增长了两倍多后，公司承受着巨大的财务压力。Cash App 团队的数据科学家 Naoko Takeda 发文称 Block "把 AI 硬塞给所有人"，但她看到的"生产力提升非常有限"。她拒绝了一份仅保留 75% 薪水的留任方案并选择离职。其他受访员工对 AI 在 Block 的实际能力，以及 Dorsey 是否真正理解这些问题，有着截然不同的看法。
正如 Aaron Levie 指出的那样，CEO 们特别容易对 AI 的效用产生幻觉——他们能快速搭出原型，却看不到把原型变成成品所需的那 90% 的工作。Dorsey 关于 AI 的公开言论似乎完全符合这一模式。今年四月，Snap 裁员约 1,000 人，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 多名全球高管，其中 21% 已经进行了较大规模的裁员，理由是"预期" AI 会带来冲击，另外 39% 也基于同样的预期进行了小规模或中等规模的裁员。相比之下，仅有 2% 是因为 AI 实际落地实施而进行了大规模裁员。这 10 倍的差距说明，高管和普通人一样，极易被"AI 取代岗位"这类误导性叙事所裹挟。
另一组有意思的数据来自《工人调整与再培训通知法》（WARN Act），该法要求企业在关厂或大规模裁员（涉及 100 名以上员工）时履行信息披露义务。2025 年 3 月，纽约成为美国第一个在 WARN Act 备案表中增设 AI 披露选项的州。在首个完整的年份里，超过 160 家公司提交了 WARN 通知，但没有一家勾选了 AI 这一项。1 我们联系了纽约州劳工部，对方确认截至五月下旬，仅有 Nespresso 一家公司勾选了该选项。2 如果这些备案数据可信，那么在相应时间段内，纽约州约 25,000 名被裁员工中仅有 46 人受到 AI 影响，占比约千分之二。
更令"AI 引发大规模裁员"这一叙事站不住脚的是：裁员本身就不是衡量 AI 潜在生产效益的正确信号！研究已经表明，其作用体现为"招聘放缓而非离职增加"。裁掉现有员工，恰恰会损失那些让员工能够有效运用 AI 的隐性知识和组织资本。此外，裁员在遣散费、员工士气以及再招聘风险方面代价高昂。鉴于这些成本，裁员基本没有必要——自然的人员流动几年内就能达到同样的效果。
那么，把目光从裁员转向整体就业趋势，数据又告诉我们什么？美联储经济学家撰写的一篇重要论文汇总了美国本土的证据。软件工程师的就业仍然在增长，但他们发现，与"没有 AI"的假设情景相比，ChatGPT 出现后的增速放缓了大约每年 3 个百分点。该研究有一个重要局限：方法论无法捕捉到自主就业的情况，因此增长放缓的部分原因也可能是被创业活动吸收了。我们确实有来自其他研究的证据表明，AI 让创业变得更轻松。所以实际情况可能比美联储研究显示的还要乐观。3
最后，有必要承认软件工程领域存在两类确实存在、但与"AI 取代软件工程师"不同的间接 AI 驱动型失业。第一类是 AI 有时彻底摧毁了产品需求，例如 Chegg（作业辅导）或 Stack Overflow（技术问答）的案例——这两家公司都进行过裁员。AI 并未直接承担这些员工的工作，而是让这类工作不再被需要。历史上也有很强的相似案例：1950 年美国人口普查中的 270 种职业里，只有一种被自动化淘汰了——电梯操作员。但还有许多职业因新技术而过时，例如电报员。
另一种可信的 AI 驱动型裁员来自那些销售 AI 而非使用 AI 的公司。所以当 IBM 或 SAP 这类公司以 AI 为由宣布裁员时，更准确的描述其实是"我们把人员从传统业务重新调配到了增长最快的产品线"。这是围绕营收机会进行的常规公司重组，而非技术取代了工人。
订阅，获取关于 AI 影响的循证分析
订阅为什么编程 Agent 没有带来劳动力替代：决策—执行—交付的三明治结构
许多科技领袖，比如前面提到的 Snap 公司 CEO，在宣布裁员或预言未来岗位流失的同时，总会附带上"AI 写的代码占比"这个数字。这助长了一种过于简单的认知：一旦 AI 能写所有代码，程序员就毫无用武之地了。好在这种认知是错的。"AI 生成代码量"这个指标几乎与劳动力替代的核心问题完全脱节。下面来解释原因。
写代码从来不是瓶颈，将来也不会是。例如，一篇 2019 年的论文 综合了已有研究后得出结论："开发者实际花在编码上的时间少得惊人，各项研究的比例从 9% 到 61% 不等"。这一发现与论文基于微软 6,000 名开发者的自有数据所得结果一致。2025 年末，随着编码 Agent 逐渐被采用，大量博客文章涌现，纷纷指出写代码并非瓶颈——开发者们发现，用 Agent 生成大部分代码对整体生产力几乎没什么提升 [1, 2, 3, 4, 5, 6, 7, 8]。
如果写代码不是瓶颈，那什么才是？任务拆解类的调查把矛头指向了会议、调试之类的活动。但紧接着又冒出更多问题：开发者在那些会议上到底在做什么？为什么 AI 做不了？调试难道不会随着 AI 能力提升而自动化吗？要弄清真正的瓶颈，我们必须做定性研究，深入了解软件工程师自身对"哪些工作内容难以被自动化"的理解。
我们做这项分析时，发现真正制约效率的瓶颈有三个：（1）决定并明确要做什么，（2）验证并对交付成果负责，（3）执行前两个环节所需的对代码库、业务和环境的深入理解。
换句话说，软件工程师的工作就像一个"决策—执行—交付"的三明治（理解能力是贯穿三者的前提）。AI 压缩了三明治的中间层——执行，但基本没动两头的决策和交付。只要开发团队还在主导决策并对交付负责，工程师就仍然需要花时间去深入理解系统。这三层就是瓶颈所在。
图示：软件开发包含三个层次：（1）决策——问题界定、需求规格、规划；（2）执行——设计与实现；（3）交付——测试、验证、集成、维护等。需要说明的是，这是概念上的分层，而非时间上的先后顺序，在项目过程中来回穿插是常态。
"三明治模型"的证据来自最近一篇关于"写代码 vs. 发代码"的论文。研究人员对 GitHub 上 10 万名开发者进行了分析，结果发现 AI Agent 让代码编写量增长了 8 倍，这与"AI 几乎完全压缩了三明治的执行层"的判断吻合。然而，发布数量仅增长了 30%，这有力地说明决策层和交付层这些人为瓶颈依然存在。4
这个"三明治"还能继续压缩吗？我们不这么认为。流水线的一端是开发团队需要决定要构建什么。初级软件工程师学到的最重要的经验之一是，需求规格说明（行业里对这个层次的叫法）花的时间比预想中要长得多，如果压缩这一层，后续会带来更大的痛苦。这一层难以自动化，因为它需要思考用户需求、市场信号、组织优先级，有时还要考虑监管限制。
随着 AI 能力的提升，可以委托给 AI 的决策类型会越来越多。但这并不会让"决策"层变薄——一旦某项决策可以委托给 AI，它就不再是竞争优势的来源，人类决策的价值会向上迁移。软件的复杂度会随时间持续增长，所以这个过程没有天花板。
在三明治的另一端，人类团队需要为他们交付的东西负责。也许未来某一天，团队可以在没有充分测试和理解代码的情况下就发布关键业务代码，但以今天 AI 的可靠性，这种草率的做法将对软件团队及其客户构成生存性的威胁。
即使未来技术障碍消失了，我们也并不需要把控制权交给 AI。《AI 作为常规技术》的一个核心观点是，我们可以通过共同规范、法律和政策来选择让人类继续承担问责责任。相比于试图放缓技术能力的开发速度，这是控制 AI 影响速度、提升安全性的更具韧性的方式。这些速度层面的障碍已经因法律责任制度和行业专项法规而大体到位，但还可以进一步加强。（关于这一观点更详细的论述，可参阅原文。）
按照这个设想，随着越来越多的执行层被委托给 AI，未来的软件工程师角色将类似于吊车操作员。AI 智能体会承担大部分繁重的认知工作，而监督智能体、保持对其控制将成为人类的主要职责。
一些评论者认为，让人类继续保持掌控权并不现实，因为为此付费的成本太高。的确出现过几则广为传播的事件，讲的是缺乏监督的编程智能体删除了生产数据库或造成了其他破坏。但我们更愿意把这些看作"人咬狗"式的新闻，而不是正在形成的新常态。它们之所以疯传，恰恰是因为这种不负责任的行为极其罕见，具有冲击力，同时也在不断提醒和促使整个行业反思，避免过度依赖 AI。常言道，"上了新闻的事，反而不必担心"。不过，能否准确监测出在经济各领域（而不只是软件工程中）高风险任务上 AI 缺乏监督的使用是否在增多，仍然是当下最关键的数据空白之一。
顺便一提，"三明治被压扁"并不是什么新趋势，也并非 AI 独有。早在二十多年前，美国劳工统计局就开始把"编程"和"软件工程"分开统计了。大致来说，程序员只负责执行，而软件工程师则掌管三明治中更大的那一部分。编程岗位不仅在缩减，薪资也低得多，因为它被视为苦力活。AI 只是加速了这一早已存在的趋势，让纯粹的技术技能进一步贬值。
这种模式似乎普遍适用于大多数知识工作，只是软件领域的发展最为领先：即使 AI 越来越多地自动化中间环节，人类仍深度参与“决策—执行—交付”这三个环节中的两端。毕竟，复杂决策与责任承担是多数领域共通的要求。由于没有充分认识到这一现象，许多人一度过度自信地宣称工作即将消失，比如预测 AI 将取代放射科医生。
Vibe coding 不等于 agentic engineering
之所以难以判断软件工程究竟发生了多大变化，一个原因是“vibe coding”一词被随意使用，用来指代跨度很大的各种实践。实际上，这些实践的边界在概念上截然不同，与其说相似，不如说差异更大。
真正意义上的 vibe coding 是：用户只告诉 agent 要做什么，不监督其运行，也不检查代码——甚至可能不具备审查代码的能力——更不会评估输出，最多只是看出明显出了故障。
相比之下，大多数软件工程师如今确实会把 agent 当作工具使用，但人仍掌握控制权，并对输出负责。幸运的是，agentic engineering 一词正逐渐成为描述这种实践的常用说法。
随着代理式工程成为常态，工程师们发现监督编码代理意外地耗费时间。比如知名开发者、AI 转型记录者 Simon Willison 就提到，自己监督代理到上午 11 点就已经心力交瘁。我们的体验也与此一致。
更量化的证据来自 SWE-chat，这是一份基于自愿启用日志工具的开源开发者编码代理交互数据集。研究发现，代理生成的代码中只有 44% 最终被纳入用户提交；氛围编码式提交的漏洞引入率是纯人工编码的九倍；用户最常见的意图是理解已有代码，而非生成新代码（19% 对比 13%）。由于该数据集是用户自愿参与采样的，仅凭它无法得出强有力的结论，但它的确印证了许多其他证据——氛围编码与代理式工程的模式差异相当大。
再次强调，两者并非泾渭分明的类别，而是同一光谱的两个端点，中间存在模糊地带。并非所有项目都是一次性的或任务关键型的，也并非所有工作流都恰好落在表格的左列或右列。但对就业问题而言，关键结论依然站得住脚——企业无法靠招聘不合格的氛围编码员来替代软件工程师，从而交付生产级软件。
未来会怎样？
AI 的拥趸可能会说，大规模裁员迟早会来；只是还没发生，因为人类水平的软件工程能力才刚刚出现（甚至还没实现）。但如果"三明治模型"是对的，这些预言就不会成真。AI 其实已经在很大程度上压缩了三明治的中间层（而且这种压缩实际上在几十年前就开始了）。所以即便让执行层变得瞬时且完美，相比现状也只是很小的变化。另外两层之所以对 AI 免疫，不是因为能力不足。
事实上，软件工程岗位不仅不会因 AI 而消失，甚至需求还可能上升。当软件（或其他任何东西）因技术进步而变得更廉价时，人们会购买多得多的软件（用经济学术语说，软件高度"价格弹性"）。正如我们所论证的，AI 并不会取代软件工程师（"替代弹性"很低），因此对更多软件的需求会转化为对更多软件工程师的派生需求。一个相关但更吸引眼球的经济学概念——"杰文斯悖论"——在 AI 讨论中经常被拿来解释这一现象。
历史上，这正是规律所在——美国的程序员就业人数从 1950 年前后接近于零，增长到了今天的数百万。这与农业形成了强烈反差，农业的劳动力需求因机械化和自动化而被大幅削减。两者的区别在于：人们对热量的需求相对固定——即使增长 25% 也只会导致肥胖问题；而软件的产出量已经增长了一百万倍。现代汽车的各个车载电脑中运行着大约一亿行代码。
如果代码需求存在上限，我们离那个上限还远得很。几乎所有脑力工作都能从软件中受益。随着 AI 让编码变得更便宜，人们正在创建各种一次性的实用工具——无论用于工作还是个人用途——而在此之前创建它们从来都不划算。
需要说明的是，虽然我们认为未来的软件数量会大幅增加，软件工程师的数量也可能随之增长，但这并不意味着大型科技公司会变得更大。如今大多数软件工程师其实已经在非软件类公司内部任职，而且这一比例未来可能还会上升。还有一种说法叫"AI 整合"，指的是风险投资或私募基金收购牙科诊所、会计师事务所这类"主流"企业，然后通过嵌入软件工程师或 AI 工程师，将其彻底改造为"AI 原生"形态。当然，这最终可能只是炒作，眼下还无法判断。
有人预测，由于"民主化"，软件工程技能的需求会下降。他们承认软件产出总量将前所未有地增长，投入软件开发的人力时间也会比以往更多，但做这些事的人不再是软件工程师。他们认为 AI 对软件工程的民主化程度会很高，比如法律软件的开发将更依赖于有法律背景的人，而非软件工程师。
也许吧。但我们并不看好这种判断。在我们看来，这同样是混淆了"凭感觉编程"与智能体工程、混淆了执行层与整个"决策—执行—交付"三层结构。事实上，回顾编程语言的发展史，"民主化即将实现"的声音从未断过——FORTRAN、COBOL、SQL 等老牌语言诞生时都伴随过类似的乐观预期，但始终没有成为现实。真正的门槛其实不在语法学习上，而在于是否具备足够的专业判断力来做出正确决策，同时还能为结果负责。
归根结底，这也许只是个语义之争。显而易见的是，人们花在让计算机做新事情上的时间会越来越多——无论是构建软件，还是用智能体管理复杂工作流，抑或其他形式。这需要软件技能、AI 技能和领域知识的结合。至于当今的软件工程师能否最好地适应并胜任这些新角色，还有待观察。
关于适应性这一点，将引出本系列的下一篇论述。软件行业的整体劳动力需求可能保持强劲，但这并不意味着大多数个体从业者不会受到影响。我们将论证，AI 将引发软件生产方式的巨大结构性变革，从而深刻影响哪些软件工程师会受益、哪些会受损——这取决于他们所在的公司类型、所在地区、资历深浅，以及适应变化的速度。