Why AI hasn’t replaced software engineers, and won’t

为什么人工智能尚未取代软件工程师，未来也不会

将编码代理视为普通技术

Arvind Narayanan

和

Sayash Kapoor

2026年6月11日

人们对人工智能取代工作产生了巨大的焦虑和不确定性。我们如何才能超越模糊的警告和夸张的预测，用数据来回答这个问题？一种有效的方法是观察人工智能能力发展最快、采用速度异常迅速的领域：软件工程。

在本文中，我们认为有足够的证据可以驳斥“一旦人工智能能力达到一定阈值，就会导致大规模裁员”的观点。即使在监管壁垒非常少的行业中，这一观点都不成立，那么其他大多数职业很可能更加受到保护。

我们对这一现象也有很好的理解。我们可以将许多类型的知识工作，包括软件开发，视为“决定-执行-交付”的三明治结构。人工智能压缩了“执行”这一层——三明治的中间部分——但其他两层却以一种仅靠能力提升无法克服的方式抵制自动化。

我们对未来软件工程需求的发展轨迹持谨慎乐观的态度。本文是系列文章的第一篇，下一篇文章将探讨为什么即使整体需求健康，个别软件工程师的职业生涯可能仍然充满挑战。该系列文章基于经济学和软件工程领域的已发表文献，我们对人工智能代理的评估和观察，以及许多软件工程师对人工智能对其职业当前和未来影响的反思，这些反思既来自已发表的著作，也来自我们与社区的互动。

软件行业关于人工智能导致大规模裁员的故事似乎属于典型的“人工智能洗白”

考虑三个登上头条新闻的故事，以及它们与现实之间的对比：

• 2月，金融科技公司Block（Cash App、Square、Afterpay等应用的开发商）宣布裁员4000人，据创始人Jack Dorsey称，这是因为人工智能“正在创造一种新的工作方式”，“团队规模更小、结构更扁平”，并特别提到了2025年底模型能力的改进。但后续报道揭示了一幅截然不同的画面。在疫情期间，公司员工数量增长了三倍以上，公司正面临巨大的财务压力。Cash App团队的数据科学家Naoko Takeda发帖称，Block“强行将人工智能推给所有人”，但她看到“生产力的提升非常有限”。她拒绝了75%的保留薪资加薪，选择辞职。其他接受采访的员工对Block的人工智能能力以及Dorsey是否真正理解相关问题有着截然不同的看法。正如Aaron Levie指出的那样，首席执行官特别容易对人工智能的实用性产生幻觉，因为他们可以快速构建原型，却看不到将其转化为成品所需的90%的工作。Dorsey关于人工智能的公开言论似乎正好符合这一模式。

• 4月，Snap裁员约1000人，CEO埃文·斯皮格尔在裁员备忘录中主要将AI作为裁员的原因。他还表示，AI生成了65%的新代码。实际上，裁员是由于一位激进投资者发起的削减成本运动所致。（自2017年IPO以来，Snap每年都出现净亏损，2026年股价下跌超过30%）。值得注意的是，裁员的性质，例如增强现实部门中涉及各种职位的150个岗位，与如果由AI驱动所预期的裁员类型并不一致（即，整体上涉及编程和其他“受AI影响”的职位，而不是集中在某个部门）。

• 5月，Intuit宣布裁员3000人，并与Anthropic和OpenAI达成协议。媒体将这两件事联系起来，将裁员描述为由AI驱动的重组。这一次，CEO实际上反驳了这一简单的叙述，表示“这一切与AI无关”，裁员针对的是“协调性高的职位”和过多的管理层级。

我们并没有刻意挑选这些例子。在我们研究的每一个关于AI驱动软件工程裁员的故事中，都出现了相同的叙述偏差。事实证明，“AI洗白”裁员是一种经济范围内的现象，许多调查显示了这一点：

• 59%的美国招聘经理承认，他们在解释裁员或冻结招聘时强调AI，因为与提及财务限制相比，AI更容易获得利益相关者的认同。

• Forrester首席分析师J. P. Gownder表示，对于那些准备进行所谓由AI驱动裁员的公司：“当我们问他们是否已经准备好一个成熟且经过验证的AI应用来填补这些职位时，10次中有9次答案是否定的，而且他们甚至还没有开始。”

• 在一项对1000多名全球高管的HBR调查中，21%的人表示他们已经大幅削减了员工数量“以应对”AI，另有39%的人进行了小幅或中等程度的预期裁员。相比之下，只有2%的人已经因实际AI实施而大幅削减了员工数量。10倍的差距表明，高管们和其他人一样，很容易被关于AI取代工作的误导性叙述所影响。

另一个有趣的数据显示来自《工人调整和再培训通知法》（WARN Act），该法要求对影响超过100名工人的工厂关闭和大规模裁员进行某些披露。2025年3月，纽约成为美国第一个在WARN Act文件中增加AI披露复选框的州。在第一年，超过160家公司提交了WARN通知。没有一家公司勾选了AI复选框。1我们联系了纽约州劳动部，他们确认到5月下旬为止，只有一家公司，即Nespresso，勾选了该复选框。2如果这些文件是准确的，那么在相关时期纽约州约25,000名被裁员的工人中，只有约46人，即约0.2%，受到了AI的影响。

对于由AI驱动的大规模裁员的叙述来说，这更加令人信服：裁员本身就不应是AI潜在生产力收益的正确信号！研究明确表明，这种影响是通过“较慢的招聘速度而非增加离职率”来实现的。解雇现有员工会导致失去那些使员工能够有效操作AI的隐性知识和组织资本。此外，从遣散费、士气损害和重新招聘风险的角度来看，这成本很高。鉴于这些成本，自然流动在几年内就能达到同样的效果，因此基本上没有必要进行裁员。

那么，当我们超越裁员，从整体就业趋势来看，数据又告诉我们什么呢？来自美联储经济学家的一篇重要论文在美国背景下汇总了相关证据。软件工程师的就业人数仍在增长，但他们发现，与没有人工智能的假设情况相比，自ChatGPT推出后，这种增长速度每年大约慢了3个百分点。这项研究的一个重要局限性是，其方法无法捕捉到自我雇佣的情况，因此可能部分增长放缓被创业活动所吸收。我们确实有其他研究的证据表明，人工智能使创业变得更加容易。因此，真实的情况可能比美联储的研究所暗示的更加积极。

最后，我们有必要承认软件工程领域中两种由人工智能间接驱动的失业现象，这些现象是真实存在的，但与人工智能取代软件工程师不同。首先，在某些情况下，人工智能会大幅减少对产品的需求，例如Chegg（作业帮助）或Stack Overflow（技术帮助），这两家公司都裁员了。人工智能并没有直接完成这些员工所做的工作，而是消除了对这些工作的需求。历史上的类比非常强烈：在1950年美国人口普查中列出的270种职业中，只有一种职业被自动化取代——电梯操作员。但许多其他职业则因新技术而变得过时，例如电报员的工作。

另一个可信的人工智能驱动的裁员故事出现在那些销售人工智能而非购买人工智能的公司中。因此，当像IBM或SAP这样的公司因人工智能而宣布裁员时，更准确的表述应是“我们将人员从传统职能重新分配到了我们增长最快的业务线”。这属于围绕收入机会的普通企业结构调整，而非技术取代工人。

订阅以获取基于证据的人工智能发展分析

为什么编码代理尚未导致劳动力替代：决定-执行-交付三明治

许多科技领导者，如上面提到的Snap首席执行官，会报告由人工智能编写的代码所占的百分比，同时报告裁员或预测未来的失业情况。这助长了一种简单的思维模型，即一旦人工智能编写了所有代码，就不需要程序员了。幸运的是，这种思维模型是错误的。这个由人工智能编写的代码的指标几乎完全与劳动力替代的关键因素无关。原因如下。

编写代码从来就不是，也从未是瓶颈。例如，2019年的一篇论文总结了现有研究，得出的结论是“开发者在编码上花费的时间出人意料地少，根据研究的不同，从9%到61%不等”。这一发现与该论文本身从微软6000名开发者那里获得的数据一致。随着编码代理的兴起，2025年底出现了大量博客文章指出，编写代码并不是瓶颈，因为开发者意识到，使用代理编写大部分代码对整体生产力影响不大 [1, 2, 3, 4, 5, 6, 7, 8]。

如果编写代码不是瓶颈，那什么才是呢？任务分解调查指出了诸如会议或调试之类的事情。这又引发了更多的问题：开发者在这些会议中到底在做什么？为什么这些工作不能由人工智能完成？随着能力的提升，调试不会被自动化吗？要理解真正的瓶颈，我们必须进行定性分析，并深入探讨软件工程师对自身工作内容的理解，这些工作内容是难以自动化的。

当我们进行这项分析时，它揭示了三个真正的瓶颈：（1）决定和明确要构建的内容；（2）验证并对其交付的内容负责；（3）执行这两个任务所需的深刻的人类理解——对代码库、业务和环境的理解。

换句话说，软件工程师的工作包含一个“决定-执行-交付”的三明治结构（理解是这三部分的前提）。AI压缩了三明治的中间部分，但对两端几乎没有改变。只要软件开发团队负责决策并对其交付的内容负责，工程师仍然需要花费时间深入理解系统。这三个瓶颈依然存在。

图：软件开发包含三个层次：（1）决策——问题定义、规格说明、规划；（2）执行——设计和实现；（3）交付——测试、验证、集成、维护等。请注意，这些是概念上的层次，而不是时间上的阶段。在项目进行过程中，常常会在这些层次之间来回切换。

AI生产力影响的三明治模型的证据来自一篇关于“编写代码与交付代码”的近期论文。研究人员在GitHub上对10万名开发者进行了研究，发现AI代理使编写的代码行数增加了八倍，这与AI几乎完全压缩了三明治中“执行”层的观点一致。但这也只导致了30%的发布次数增加，这强烈表明人类瓶颈（“决定”和“交付”层）依然存在。

三明治结构还能进一步压缩吗？我们认为不能。在流程的一端，开发团队需要决定要构建什么。初级软件工程师学到的最重要的教训之一是，需求规格说明（该层次的专业术语）出人意料地耗时，如果被压缩，会导致后续更多的问题。这一层很难自动化，因为它需要考虑用户需求、市场信号、组织优先事项，以及在某些情况下监管限制。

随着AI能力的提高，可以委托给AI的决策类型会随着时间的推移而增加。但这并不会使“决定”层变薄——一旦某个决策可以委托给AI，它就不再是竞争优势的来源，而人类决策的价值则会向上迁移。软件随着时间的推移变得越来越复杂，因此这一过程没有上限。

在三明治的另一端，人类团队需要对其交付的内容负责。也许在未来的某一天，团队可以在没有充分测试和理解的情况下交付关键任务代码，但目前的AI如此不可靠，这种随意的做法将对软件团队及其客户构成生存威胁。

即使未来技术障碍消失，我们也不必将控制权交给AI。AI作为正常技术的核心见解是，我们可以共同选择通过共享规范、法律和政策来保持人类的责任。这比试图减缓技术能力的发展速度，是一种更稳健的方式来控制AI的影响并提高安全性。这些速度障碍由于责任法律和行业特定的监管已经基本存在，但可以进一步加强。（如需更详细的论述，请参阅原始文章。）

在这种愿景中，随着越来越多的执行层工作被委托给人工智能，未来软件工程师的角色将类似于起重机操作员。AI代理将承担大部分认知上的繁重工作；监督代理并保持对其控制，将成为人类的主要工作。

一些评论者认为，人类在未来保持控制是不可能的，因为请人来做这件事的成本太高。已经有一些关于监督不力的编码代理删除生产数据库或造成其他类型损害的病毒式传播的故事。但我们认为这些只是“人咬狗”的新闻，而不是正在形成的新常态。这些新闻之所以会病毒式传播，正是因为他们代表了如此不负责任和不寻常的行为，具有冲击力，并且作为常规提醒和学习机会，帮助社区防范对AI的过度依赖。正如谚语所说，“如果上了新闻，就不用太担心”。然而，今天，我们仍然面临一个最关键的数据缺口，即能否检测到在高风险任务中对AI的监督使用是否有所增加，这不仅限于软件工程，而是整个经济领域。

顺便提一下，三明治被压扁的现象是一种新趋势，并非仅仅由于AI。早在二十年前，美国劳工统计局就开始将编程从软件工程中单独统计。简而言之，程序员只负责执行，而软件工程师则管理三明治中更大的部分。不仅编程工作在减少，而且其薪酬也远低于软件工程师，因为它被视为苦力工作。AI只是加速了这一长期存在的趋势，进一步降低了纯技术技能的价值。

软件工程与程序员就业。图表由《华盛顿邮报》制作。

这种模式——人类在决定-执行-交付三明治的两端仍然高度参与，而AI则越来越多地自动化中间层——似乎广泛适用于大多数知识型工作，尽管在软件工程领域进展最快。毕竟，复杂决策和问责是大多数领域的共同特征。对这一现象缺乏认识，导致了许多过于自信的关于即将失业的预测，例如关于AI将取代放射科医生的预测。

振兴编码并不是代理工程

软件工程正在发生变化的程度之所以存在混淆，其中一个原因是“vibe coding”一词的使用不够严谨，用来指代一系列广泛实践，这些实践的两端在概念上是截然不同的，差异大于相似。

在真正的vibe coding中，用户只是告诉代理要做什么，不会在运行时进行监督，不会审查代码——甚至可能没有能力这样做——也不会评估输出，除非明显出错时才会注意到。

这与大多数软件工程师实际使用代理的方式形成对比——作为一种工具，人类仍然保持控制并对其输出负责。幸运的是，“代理工程”这一术语正在逐渐被用来描述这种实践。

随着代理工程成为常态，工程师们发现监督编码代理竟然出奇地耗时。例如，知名开发者和AI转型记录者Simon Willison曾提到，他从早上11点开始就因监督代理而感到精神疲惫。这与我们的经验也是一致的。

更多量化证据来自 SWE-chat，这是一个由开源开发者参与日志工具的数据集，记录了编码代理的交互情况。研究发现，只有 44% 的代理生成的代码最终被用户提交；通过“氛围编码”提交的代码引入漏洞的速度是纯人工编码的九倍；最常见的用户意图是理解现有代码，而不是生成新代码（19% 对比 13%）。由于该数据集是自我选择的，我们不能仅凭这项研究得出强有力的结论，但它确实强化了其他许多证据，表明“氛围编码”和代理工程模式存在显著差异。

代理工程不是氛围编码

再次强调，这两者并不是两个截然不同的类别。它们是同一光谱的两个极端，中间存在一个模糊的过渡区域。并不是每个项目都是临时性的或关键任务的。并不是每个工作流程都完全符合表格左侧或右侧的分类。但就“工作”问题而言，关键的结论依然成立——公司不能通过雇佣不合格的氛围编码者来代替软件工程师，从而交付生产软件。

未来会怎样？

人工智能的乐观者可能会声称大规模裁员即将到来；但到目前为止，这种情况尚未发生，因为达到人类水平的软件工程能力是非常近期的事情（或者尚未实现）。但如果“三明治模型”是正确的，这些预测将不会成为现实。人工智能已经大幅压缩了三明治的中间部分（实际上，这种压缩早在几十年前就开始了）。因此，即使执行层变得即时且完美，也只是对现状的一点点改变。其他两层对人工智能的抵抗并不是因为能力的限制。

事实上，不仅软件工程工作不会因为人工智能而消失，软件工程师的需求甚至可能增加。当软件（或任何其他东西）由于技术生产力的提高而变得更容易创建时，人们将购买更多的软件（用经济学术语来说，软件具有高度的“价格弹性”）。正如我们所论述的，人工智能不会取代软件工程师（“替代弹性”较低），因此对更多软件的需求会进一步引发对更多软件工程师的需求。一个与之松散相关但更引人注目的经济学术语是“杰文斯悖论”，这个术语经常在人工智能的讨论中被用来描述这一概念。

从历史上看，这就是趋势——在美国，程序员的就业人数从 1950 年左右的几乎为零增长到如今的数百万。这与农业等职业形成了鲜明对比，农业由于机械化和自动化，劳动力需求曾被大幅削减。区别在于，人们消耗的卡路里数量相对固定——即使增加了 25%，也导致了肥胖流行——而软件的产量却增长了百万倍。现代汽车中，各种车载计算机上运行的代码行数可能多达数千万行。

如果对代码需求存在上限，我们距离这个上限还非常遥远。几乎所有认知工作都能从软件中受益。随着人工智能使编码变得更加便宜，人们正在创造各种一次性工具——无论是用于工作还是个人使用——这些工具在以前是完全没有意义去创建的。

需要明确的是，尽管我们认为未来将出现更多的软件，以及可能更多的软件工程师，但这并不意味着大型科技公司会变得更大。目前，大多数软件工程师已经在非软件公司内部工作，未来这一比例可能会进一步增长。此外，还有“AI rollups”的概念，指的是风险投资或私募股权公司收购“Main street”企业（如牙科诊所、会计师事务所等），然后从零开始重建这些企业，使其成为“AI原生”企业，方法是将软件工程师或AI工程师嵌入到这些企业中。当然，这可能最终只是炒作而已，现在还为时过早。

有些人预测，由于民主化趋势，对软件工程技能的需求将会下降。他们承认，未来将会有比以往任何时候都更多的软件被开发出来，而且人类投入软件开发的时间也会比以往任何时候都多，但这些工作将由非软件工程师的人完成。这个观点认为，AI将使软件工程民主化到这样的程度，例如法律软件可以更容易地由受过法律培训的人而不是软件工程师来创建。

也许吧。但我们倾向于反对这种观点。在我们看来，这陷入了将“氛围编程”与“自主工程”混淆，以及将执行层与整个“决策-执行-交付”流程混淆的陷阱。事实上，当我们回顾编程的历史时，一直都有人声称我们正处于民主化的门槛上——过去的老语言如FORTRAN、COBOL和SQL在它们刚被引入时也都伴随着类似的高期望。但这些期望从未实现。真正的障碍并不是学习语法，而是拥有足够的专业判断力，以便在保持问责制的同时做出良好的决策。

最终，这种区别可能只是语义上的。很明显，人们花在让计算机做新事情上的时间将会随着时间的推移而增加。这可能表现为构建软件、使用代理管理复杂的工作流程，或者其他形式。这将需要软件技能、AI技能和领域专业知识的结合。至于今天哪些软件工程师最能适应这些新角色，还有待观察。

关于适应需求的最后一点，为本系列文章的下一篇文章奠定了基础。软件领域整体劳动力需求很可能保持强劲，并不意味着大多数个体工作者不会受到影响。我们将论证AI将对软件的生产方式造成巨大的结构性变化，这将对哪些软件工程师会受益或受损产生重大影响——这取决于他们所工作的公司类型、地理位置、职位级别以及他们适应变化的速度。

进一步阅读

Deena Mousa指出，基于“AI暴露度”等指标的广泛、宏观经济层面的AI影响分析过于表面，她主张进行“细致、针对特定职业的研究”。我们希望这一系列文章能在建立对AI如何改变软件工程的深入理解方面发挥一定作用。我们之前曾与Justin Curl共同撰写了一篇分析AI在法律服务中应用的论文，该论文深入探讨了使这一职业独特的监管及其他瓶颈问题。我们计划在未来进行更多针对特定职业的深入分析。

在一篇题为《No Silver Bullet》（四十多年前的一篇出色文章）中，Fred Brooks 区分了软件的“本质复杂性”和“偶然复杂性”。他指出，软件的一部分复杂性是偶然的，源于当前技术的限制，如编程语言的笨拙性，这种复杂性会随着工具的改进而逐渐减少。但另一部分复杂性是本质的，因为定义软件的正确行为本身就很困难。他有力地阐述了为什么“决策”层在三明治结构中很厚且难以自动化。有趣的是，当时就已经有人希望通过人工智能来提高程序员的生产力！Brooks 认为，由于人工智能或其他任何技术只能减少偶然复杂性，因此不会带来数量级的生产力提升。（Brooks 是《The Mythical Man-Month》一书的作者，这是一本几乎可以肯定是所有时代中最有影响力和最广为人知的软件工程著作合集。《No Silver Bullet》后来也成为该合集的一部分。）

我们感谢 Felix Chen 对草稿提出的宝贵意见。

该复选框实际上的标签是“技术创新或自动化”。如果勾选，会有一个下拉菜单，用于披露具体技术，如人工智能或机器人技术。

目前的《WARN Act》数据存在各种局限性——它仅限于纽约州，而且由于勾选或不勾选复选框所带来的不对称风险，公司可能会低估人工智能作为裁员原因的报告数量（尽管我们没有具体理由认为这一点）。在联邦和州层面，更强的透明度要求正在制定中；填补这一数据空白迫在眉睫。

我们感谢我们的同事 Mihir Kshirsagar 将我们与纽约州劳动部门联系起来，以及来自该部门的 Elena Grovenger 的迅速回应。

论文中使用了“coder”（编码人员）这一术语，但它是基于技能而非角色来定义的，因此涵盖的职位范围远远超出“编码”本身。基于行业、职位和技能的测量方法很难相互比较。

有趣的是，在一项关于移动应用的子研究中，论文发现所生成的应用程序使用率根本没有增加。这揭示了消费者软件和企业软件之间的一个重要差异。前者争夺的是相对固定的注意力资源；发布更多的应用并不意味着应用使用时间的增加。但在企业软件中，增长空间很大，因为之前由人工完成的流程可以被软件中介或自动化。