为什么 AI 还没有取代软件工程师,也不会取代

为什么 AI 还没有取代软件工程师,也不会取代

人们对 AI 取代工作,充满焦虑和不确定。怎么越过含糊的警告和夸张的预言,让数据来说话?一个很好的切入点,是去看 AI 能力走得最远、采用又异常快的职业:软件工程。

我们的论点是:已有的证据,足以拒绝这样一种叙事。AI 能力越过某个门槛,就会引发大规模裁员。即使在一个几乎没有监管壁垒的行业里,这件事都没发生。其他大多数职业,只会得到更多缓冲。

我们也已经相当清楚这是为什么。可以把许多知识工作,包括软件开发,想象成一个“决定—执行—交付”三明治。AI 压缩的是中间那层“执行”。但另外两层抗拒自动化的程度,不会只靠能力提升就被攻克。

最后,我们对软件工程需求的未来走向,持谨慎乐观。这篇文章是一个系列的第一篇。下一篇会讨论:即便整体需求健康,为什么单个软件工程师的职业生涯仍可能颠簸。这个系列基于经济学和软件工程的已发表文献、我们自己对 AI 智能体的评估和观察,以及许多软件工程师对本职业当下和未来的反思。反思既来自公开写作,也来自我们和这个群体的交流。

那些“AI 导致大规模裁员”的故事,听起来很像“AI 洗白”

先看三个上过头条的故事,以及它们和现实的落差。

今年 2 月,金融科技公司 Block 宣布裁员 4000 人。旗下有 Cash App、Square、Afterpay 等产品。创始人杰克·多西说,AI 正在“催生一种新的工作方式”。可以用“更小、更扁平的团队”做事。他还特别提到 2025 年底以来模型能力的跃升。

但后续报道呈现的图景截然不同。疫情期间 Block 的员工人数涨了三倍多。公司正承受巨大的财务压力。Cash App 团队的数据科学家 Naoko Takeda 发帖说,Block“把 AI 硬塞进每个人的喉咙”。但她看到的“生产力提升非常有限”。她拒绝了一份加薪 75% 的挽留,辞职离开。其他受访员工对 AI 在 Block 到底能做什么、多西是否真正理解这些问题,有着尖锐不同的看法。

正如 Aaron Levie 指出的,CEO 们特别容易对 AI 的用处产生幻觉。他们能快速做出原型。却看不见把原型变成成品所需的 90% 工作。多西关于 AI 的公开说法,看起来恰好符合这个模式。

4 月,Snap 裁员约 1000 人。CEO 埃文·斯皮格尔在裁员备忘录里主要把原因归于 AI。他还说,AI 已经生成了 65% 的新代码。但实际上,这次裁员发生在一名激进投资者要求削减成本的运动之后。Snap 自 2017 年上市以来,每个完整财年都净亏损,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 法案。它要求对涉及 100 人以上的工厂关闭和大规模裁员作出披露。2025 年 3 月,纽约州成为美国第一个在 WARN 申报里加入“AI 披露”勾选框的州。在完整的第一个年度里,160 多家公司提交了 WARN 通知。没有一家勾选 AI。我们联系了纽约州劳工部。对方确认,截至 5 月底,只有一家公司 Nespresso 勾了这个框。如果这些申报属实,在相关时期纽约州约 2.5 万名被裁员工里,只有 46 人,约千分之二,和 AI 有关。

对“AI 驱动大规模裁员”叙事更致命的一点是:裁员本身就不是衡量 AI 潜在生产力收益的正确信号。研究已经很清楚:AI 的影响是通过“放慢招聘,而不是增加离职”来传导的。解雇现有员工,恰恰会损失那些让员工能有效使用 AI 的隐性知识和组织资本。而且裁员代价高昂:遣散费、士气打击、重新招聘的风险。既然自然流失几年内就能达到同样的效果,大规模裁员在很大程度上并无必要。

那么跳出裁员,看整体就业趋势,数据又说了什么?美联储经济学家的一篇重要论文汇总了美国的证据。就业仍在增长。但和“没有 AI”的反事实相比,ChatGPT 之后就业增速放慢了约每年 3 个百分点。这项研究有个重要局限。它的方法捕捉不到自雇。所以部分增速放缓可能被创业吸收了。我们从其他研究里也有证据,AI 让创业变得更容易。所以真实图景,很可能比美联储的研究显示的还要健康。

最后值得承认两类真实存在、但性质不同的“间接由 AI 驱动”的软件岗位流失。第一类,AI 有时会直接摧毁某个产品的需求。比如 Chegg(作业辅导)或 Stack Overflow(技术问答),两家都裁了员。AI 并没有直接去做这些员工原本做的工作。而是让这份工作变得不再需要。历史的平行案例很贴切:1950 年美国人口普查的 270 个职业里,只有一个职业是被自动化消灭的,电梯操作员。但还有许多职业是被新技术变得过时,比如电报员。

另一类可信的“AI 裁员”故事,发生在卖 AI 的公司,而不是买 AI 的公司身上。当 IBM 或 SAP 宣布因 AI 裁员时,更准确的说法是:我们把人力从传统业务线调到了增长最快的产品线。这是围绕营收机会的普通企业重组,不是技术在取代工人。

为什么编程智能体没有导致劳动力被取代:“决定—执行—交付”三明治

许多科技领袖,比如上面那位 Snap 的 CEO,在谈裁员或预言未来岗位流失时,总爱顺带提一句“AI 写了多少比例的代码”。这喂养了一种简单的心理模型:AI 写了所有的代码,就不再需要程序员了。幸运的是,这个模型是错的。“AI 写的代码占比”这个指标,和劳动力是否被取代,几乎完全脱节。原因如下。

**首先,写代码从来就不是瓶颈。**比如一篇 2019 年的论文汇总已有研究后得出结论:“开发者真正花在写代码上的时间出人意料地少。根据研究不同,在 9% 到 61% 之间。”这一发现和该论文自己基于微软 6000 名开发者的数据相符。随着编程智能体开始被采用,2025 年底涌现了大量博客文章。大家意识到:让智能体写掉大部分代码,对整体生产力的影响微乎其微。

如果写代码不是瓶颈,那什么是?任务拆解调查指向的是开会、调试这类事。但这只会引出更多问题:开发者在那些会议里到底在做什么,为什么 AI 做不了?调试难道不会随着能力提升而被自动化吗?要理解真正的瓶颈,我们必须走向定性,去深挖软件工程师自己对“自己所做之事中哪些抗拒自动化”的理解。我们分析后发现,真正的瓶颈有三:决定和具体化要做什么;验证交付物并为之负责;完成前两件事所需的、对代码库、业务和环境的深层理解。换句话说,软件工程师的工作是一个“决定—执行—交付”三明治。理解是三层共同的前提。AI 压缩了三明治的中间,基本没动两端。只要软件开发团队仍然负责决策、并对交付物负责,工程师就仍然需要花时间建立对系统的深层理解。这三点,就是瓶颈。

一张图可以概括:软件开发由三层构成。决策:问题框定、规格制定、规划。执行:设计与实现。交付:测试、验证、集成、维护等。注意,这三层是概念层,不是时间阶段。一个项目进行中来回切换很常见。

支持“三明治模型”的证据,来自一篇近期的论文《写代码 vs 发布代码》。研究者分析了 GitHub 上 10 万名开发者。AI 智能体让写出的代码行数涨了 8 倍。这和“AI 几乎完全压缩了执行层”的想法相符。但发布次数只增加了 30%。这强烈表明,人类的瓶颈,决定层和交付层,依然在原地。

这个三明治还能被进一步压缩吗?我们认为不能。在管线的一端,开发团队需要决定做什么。初级软件工程师学到的最重要的经验之一是:需求规格制定耗时出人意料地长。一旦把它压缩,后面会付出多得多的代价。这一层难以自动化。因为它要思考用户需求、市场信号、组织优先级,有时还包括监管约束。

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

在三明治的另一端,人类团队需要为交付物负责。也许未来的某一天,团队会在没有充分测试和理解的情况下发布关键代码。但今天的 AI 实在太不可靠。这种马虎的做法,会对软件团队及其客户构成生存威胁。

即便未来的技术壁垒消失,我们也不必把控制权让给 AI。“AI 作为常态技术”的一个核心洞见是:我们可以通过共享规范、法律和政策,集体选择让人类继续负责。这是控制 AI 影响速度、提升安全性的更有韧性的方式。远胜于试图放慢技术能力的发展。这些“速度壁垒”其实已经借由责任法和行业监管大体就位了,还可以进一步加强。

在这种图景里,随着执行层越来越多地委托给 AI,未来的软件工程师角色会变得像起重机操作员。AI 智能体承担大部分认知重活。监督智能体、让它保持在控,成为人类工作的主要部分。

有些评论者认为,人类保持在控的未来不太可能出现。因为付钱让人这么做太贵了。已经有几个病毒式传播的故事,讲无人好好看管的编程智能体删掉了生产数据库,或造成其他类型的破坏。但我们把这些看作“狗咬人不是新闻、人咬狗才是新闻”式的故事。它们能病毒式传播,恰恰因为这种行为不负责任、极不寻常,有冲击力。反而成了定期的提醒和教训,帮这个群体警惕过度依赖 AI。正如那句格言所说:“如果它上了新闻,就别担心它。”不过,能否察觉“在高风险任务中草草使用 AI”是否在整个经济范围内呈上升趋势,仍是我们今天最关键的数据缺口之一。不只关乎软件工程。

顺带一提,三明治被压扁并不是新趋势,也并非 AI 独有。二十多年前,美国劳工统计局就开始把“编程”和“软件工程”分开统计。大体上,程序员只负责执行。软件工程师管的是三明治的更大一部分。编程岗位不仅一直在萎缩,薪酬也低得多。因为它被视为粗活。AI 只是加速了这个长期趋势,进一步贬低了纯技术技能的价值。

这个模式,即便 AI 越来越多地自动化中间层,人类仍深度参与决定和交付两端,似乎广泛适用于大多数知识工作。只是在软件领域走得最远。毕竟,复杂决策和问责是大多数领域的共同点。对这一现象缺乏认识,已经导致了许多过度自信的岗位流失预言。比如针对放射科医生的那些。

“氛围编程”不是“智能体工程”

人们对软件工程到底在如何变化感到困惑,一个原因是“vibe coding”这个词被用得太随意。它涵盖了光谱极广的实践。而光谱两端在概念上截然不同,差异远大于相似。

在真正的 vibe coding 里,用户只是告诉智能体要做什么。运行时不管不顾。不审查代码,甚至可能根本没能力审查。也不评估输出。最多在东西明显坏掉时才察觉。

这和大多数软件工程师实际使用智能体的方式形成对比:智能体是工具。人类保持在控,并对输出负责。幸运的是,“agentic engineering”,智能体工程,这个说法正在流行起来。它描述的就是后一种实践。

随着智能体工程成为常态,工程师们发现,监督编程智能体出人意料地耗时。比如著名开发者、AI 转型的记录者 Simon Willison 就提到,监督智能体让他到上午 11 点就已经心力交瘁。我们的体会也一样。

更定量的证据来自 SWE-chat。一个由选择加入记录工具的开源开发者贡献的编程智能体交互数据集。研究发现,智能体生成的代码只有 44% 最终进入用户的提交。vibe coding 式提交引入漏洞的概率是纯人类提交的 9 倍。用户最常见的意图是理解现有代码,而不是生成新代码。19% 对 13%。这个数据集的自选择性质意味着我们不能只凭它下强结论。但它确实和许多其他证据相互印证:vibe coding 和智能体工程的模式相当不同。

重申一下,这不是两个泾渭分明的类别。而是光谱的两端,中间有模糊地带。并非每个项目要么是可丢弃的、要么是任务关键型的。并非每个工作流都能精确落入某个表格的左栏或右栏。但对岗位问题的关键推论依然成立:公司没法靠雇佣不合格的 vibe coder 来替代软件工程师,去发布生产级软件。

未来会怎样?

AI 的鼓吹者可能会说:大规模裁员会来的,只是还没发生。因为“人类水平的软件工程能力”非常新近,或者尚未实现。但如果三明治模型成立,这些预言不会成真。AI 已经在很大程度上压缩了三明治的中间。这种压缩实际上几十年前就开始了。所以哪怕让执行层变得瞬间且完美,相对于现状也只是小小的变化。另外两层之所以抗拒 AI,不是因为能力限制。

事实上,软件工程岗位不仅不会因 AI 消失,对软件工程师的需求甚至可能增加。当软件因为技术进步而变得更便宜时,人们会买多得多的软件。用经济学术语说,软件的价格弹性很高。而正如我们所论证的,AI 并不能替代软件工程师,替代弹性很低。所以对更多软件的需求,会派生出对更多软件工程师的需求。一个相关但更时髦的经济学说法,“杰文斯悖论”,常被扔进 AI 讨论里,指的正是这个概念。

历史上也正是这个模式:美国的程序员就业人数从 1950 年左右的近乎零,增长到了今天的数百万。这和农业等职业形成鲜明对比。在那些职业里,劳动力需求被机械化和自动化打得七零八落。区别在于,人们摄入的卡路里相对固定。哪怕增加 25% 也带来了肥胖流行。而软件的产量已经增长了上百万倍。现代汽车的各种车载电脑上,运行着大约一亿行代码。

如果代码需求有天花板,我们离它还远得很。几乎所有认知工作都能从软件中受益。随着 AI 让编程更便宜,人们正在创造各种一次性小工具。无论是工作还是个人用途。这些东西在以前,根本不值得专门去做。

说清楚一点:虽然我们认为未来会有多得多的软件,也可能有更多的软件工程师,但这不意味着大科技公司会变得更大。今天大多数软件工程师已经在非软件公司内部工作。未来这一比例可能还会上升。

然后是“AI 整合”的想法:风险投资或私募股权公司收购“主街”生意。牙科诊所、会计师事务所之类。然后从头把它们重建成“AI 原生”的。把软件工程师或 AI 工程师嵌入这些生意。当然,这最后可能只是一阵炒作。现在下结论还太早。

有些人预言,对软件工程技能的需求会因“民主化”而下降。他们承认,未来产出的软件会比以往任何时候都多。花在生产软件上的人类时间也会比以往多。但这份工作将由不是软件工程师的人来做。其想法是,AI 会把软件工程民主化到这种程度:比如法律软件,可以由受过法律训练而不是软件训练的人更容易地创造出来。

也许吧。但我们赌它不会。这同样掉进了把 vibe coding 和智能体工程混为一谈、把执行层和整个三明治混为一谈的陷阱。事实上,回顾编程的历史,每一次都有类似的“我们正站在民主化门槛上”的说法。FORTRAN、COBOL、SQL 这些老语言问世时,都伴随着这样显赫的期望。从来都没实现过。真正的壁垒从来不是学语法。而是拥有足够的娴熟判断力,在保持问责的同时做出好决策。

说到底,这可能只是个语义之争。有一点很清楚:人们花在“让计算机做新事情”上的时间,会随时间增加。这可能以构建软件的形式出现。也可能是用智能体管理复杂工作流。或者别的什么。它需要的,是软件技能、AI 技能和领域专长的混合。至于今天这批软件工程师,是否最能适应去填补这些新角色,还有待观察。

最后这一点,适应的必要性,正是这个系列下一篇的引子。总体劳动力需求在软件领域很可能保持强劲。这不意味着大多数个体劳动者不会受到影响。我们将会论证:AI 会在软件的生产方式上造成巨大的结构性转移。这将深刻影响哪些软件工程师会受益、哪些会受损。取决于他们所在公司的类型、地域、资历,以及适应的速度。

延伸阅读

Deena Mousa 指出,基于“AI 暴露度”这类指标的、宽泛的、全经济范围的 AI 影响分析是肤浅的。她呼吁“细致的、针对具体职业的工作”。我们希望这个系列能在建立对 AI 如何改变软件工程的细腻理解上发挥一点作用。我们此前和 Justin Curl 合著过一篇分析 AI 在法律服务中应用的论文,认真讨论了让那个职业独一无二的监管及其他瓶颈。我们计划未来做更多针对具体职业的深挖。

四十年前,Fred Brooks 在一篇堪称非凡的文章《没有银弹》里,区分了软件的“本质复杂性”和“偶然复杂性”。他论证说,软件的部分复杂性是偶然的。源于当下技术的局限,比如编程语言的笨拙。会随着工具改进而缓解。但部分复杂性是本质的。因为“把软件的正确行为规格化”本身就很难。他有力地阐明了为什么三明治的“决定层”又厚又抗拒自动化。有意思的是,早在那时,通过 AI 提升程序员生产力的期望就已经很流行了!Brooks 论证说,AI 或任何其他技术只减少偶然复杂性,它不会带来数量级的生产力提升。Brooks 是《人月神话》的作者。那几乎肯定是软件工程领域最知名、影响最深远的写作。《没有银弹》后来也被收入该文集。

感谢 Felix Chen 对本文草稿的反馈。

✍️ 出处

出处

  • 刊物:AI as Normal Technology
  • 原名:Why AI hasn’t replaced software engineers, and won’t
  • 作者:Arvind Narayanan 与 Sayash Kapoor
  • 说明:中文由好读整理,版权归原作者。原文来自作者邮件通讯。
1 / 1
← 滑动或点击两侧翻页 →