首页文章详情

为什么人工智能没能取代软件工程师,而且未来也不会

神译局2026-07-17 15:06
编程智能体不过是普通技术罢了

神译局是36氪旗下编译团队,关注科技、商业、职场、生活等领域,重点介绍国外的新技术、新观点、新风向。

编者按:AI裁员只是高管的“幻饰”?本文拆解知识型工作的三明治模型,看清软件工程师不可替代的底层真相。文章来自编译。

关于人工智能取代就业的焦虑和不确定性正广泛蔓延。我们该如何摆脱那些语焉不详的警告和夸大其词的预言,用客观数据来审视这一问题?一个绝佳的方法是去看看人工智能能力发展最前沿、且普及速度异常迅猛的行业:软件工程。

在本篇文章中,我们指出已有充足的证据来反驳一种论调——即一旦人工智能的能力达到某个临界点,就会引发大规模裁员。鉴于在几乎没有任何监管壁垒的软件行业情况都是如此,大多数其他行业所受到的缓冲保护很可能会更稳固。

我们也对造成这一现象的根本原因有了清晰的认识。我们可以把包括软件开发在内的许多知识型工作,看作是一个“决定-执行-交付 三明治”。人工智能压缩了处于三明治中间的“执行”层,但另外两层对自动化的抵抗力,绝非仅靠技术能力的提升就能攻破的。

我们对软件工程未来的需求走向持谨慎乐观的态度。本文是该系列文章的首篇,下一篇将探讨即便行业整体需求稳健,为什么个人软件工程师的职业生涯仍可能遭遇颠簸。本系列基于经济学和软件工程领域的已发表文献、我们对人工智能智能体的亲自评估与观察,以及众多软件工程师对人工智能技术给自身行业所带来当下与未来冲击的反思——这些反思既源自公开发表的文章,也来自我们与该社群的交流互动。

那些盛传人工智能导致软件行业大规模裁员的故事,似乎属于典型的人工智能“粉饰”(AI washing)

不妨看看这三则曾登上头条的新闻,以及它们与残酷现实的巨大反差:

1、今年2月,金融科技公司 Block(Cash App、Square、Afterpay 等应用的开发商)宣布裁员4,000人。据其创始人杰克·多西(Jack Dorsey)称,人工智能“赋能了全新的工作方式”,可让“团队更小、更扁平”,并特别提到了2025年晚些时候模型能力的飞跃。

但随后的跟进报道却揭示了截然不同的真相。在疫情期间将员工人数扩大了三倍多之后,该公司正承受着巨大的财务压力。Cash App 团队的一位数据科学家武田直子(Naoko Takeda)发文称,Block“硬生生地把人工智能塞给每个人”,但她看到的“生产力提升极其有限”。她拒绝了75%的留任加薪,毅然离职。其他接受采访的员工对于人工智能在 Block 的实际能力,以及多西对这些技术问题的理解是否称职,有着截然相反的看法。

正如亚伦·列维(Aaron Levie)所指出的,首席执行官们格外容易对人工智能的实用性产生幻觉,因为他们能快速搭出原型,却看不见将其转化为最终产品所需付出的剩下90%的艰苦工作。多西关于人工智能的公开言论,似乎完全符合这一规律。

2、今年4月,Snap 裁员了约1000人,CEO 埃文·斯皮格尔(Evan Spiegel)在裁员备忘录中主要将原因归咎于人工智能。他还声称,公司65%的新代码都是由人工智能生成的。而现实情况是,此次裁员是一场激进投资者施压要求削减成本的运动的结果。(自2017年上市以来,Snap 每年都录得净亏损,其股价在2026年更是下跌了30%以上)。发人深省的是,裁员的结构属性——比方说增强现实部门中涵盖多个岗位的150个职位的削减——与我们所预期的人工智能驱动的裁员毫无关联(如果是技术替代,应该表现为全公司范围内编程等其他“易受 AI 冲击”的岗位的普遍裁撤,而不是集中在某个特定部门)。

3、今年5月,Intuit 宣布裁员3000人,同时宣布了与 Anthropic 和 OpenAI 的合作交易。媒体迅速将这两件事联系起来,把裁员描绘成人工智能驱动的转型重组。然而这一次,首席执行官站出来反驳了这种流于表面的论调,明确表示“这与人工智能毫无关系”,裁员针对的是“沟通协调成本高昂的岗位”以及冗余的管理层级。

我们并没有刻意挑选这些例子。在我们调查的每一篇关于人工智能导致软件工程裁员的报道中,都发现了与这种表面叙事相悖的事实。事实证明,用“人工智能”来粉饰裁员是整个经济体中的普遍现象,许多调查报告也印证了这一点:

  • 59%的美国招聘经理承认,他们在解释招聘冻结或裁员时会刻意强调人工智能,因为相比于承认财务吃紧,这种说法在利益相关者那里更讨巧。

  • Forrester 首席分析师 J. P. 冈德(J. P. Gownder)在谈到那些筹划所谓人工智能裁员的公司时表示:“当我们询问他们是否已经准备好成熟、经过验证的人工智能应用来接替这些岗位时,十有八九答案是否定的——他们甚至还没开始做。”

  • 在《哈佛商业评论》对全球1000多名高管的一项调查中,21%的人出于对人工智能的“预期”而进行了大规模裁员,另有39%的人进行了轻度或中度的预期性裁员。相比之下,真正因为实际部署人工智能而进行了大规模裁员的仅有2%。这高达十倍的差距表明,高管们和普通人一样,极易被“人工智能取代就业”的误导性叙事所俘获。

另一个耐人寻味的数据点来自《工人调整和再培训通知法案》(WARN Act),该法案要求对影响超过100名工人的工厂关闭和大范围裁员进行特定信息披露。2025年3月,纽约州成为美国第一个在 WARN 法案申报中加入人工智能披露勾选项的州。在整整第一年里,有160多家公司提交了 WARN 通知。没有一家公司勾选了人工智能选项。我们联系了纽约州劳工部,他们证实截至5月下旬,只有一家公司(奈斯派索,Nespresso)勾选了该选项。如果这些数据属实,在相关时期内,纽约州约25000名被裁工人中,只有46人受到人工智能的影响,比例仅为千分之二左右。

对于“人工智能引发大规模裁员”的论调而言,更具毁灭性的一点在于:裁员本身根本就不是评估人工智能潜在生产力效益的正确指标!研究明确表明,这种影响主要通过“放缓招聘,而非增加解雇”来体现。辞退老员工恰恰会使企业失去那些能让员工高效驾驭人工智能的隐性知识和组织资产。此外,裁员在遣散费、损害士气以及重新招聘风险方面的成本极高。考虑到这些代价,裁员大可不必,因为员工的自然流动在几年内就能达到同样的人员精简效果。

那么,当我们把视线从裁员移开,投向整体就业趋势时,数据告诉了我们什么?美联储经济学家的一篇重要论文汇编了美国背景下的证据。软件工程师的就业人数仍在增长,但他们发现,与没有人工智能的假设情况相比,在 ChatGPT 诞生后,其年增长率放缓了大约3个百分点。这项研究的一个重要局限在于,其方法无法捕捉到自雇(自主创业)人群,因此增长放缓的部分可能已被创业热潮所消化。其他研究确实证明了人工智能让创业变得更加容易。因此,真实的行业景象可能比美联储研究报告所显示的还要健康。

最后,有必要承认在软件工程领域,确实存在两种间接由人工智能引发的失业,但与人工智能直接取代软件工程师完全是两码事。第一种情况是,人工智能有时候会彻底摧毁对某种产品的市场需求,比方说 Chegg(作业帮扶)或 Stack Overflow(技术问答),这两家公司都解雇了员工。人工智能并没有直接去做这些员工的工作,而是消除了市场对这种工作的需求。这与历史有着极强的相似性:在1950年美国人口普查的270种职业中,只有一种职业因自动化而彻底消失——电梯操作员。但许多其他职业却因新技术的出现而变得不合时宜,比如电报员。

另一种看似人工智能造成的裁员故事,发生在兜售人工智能而非购买人工智能的公司身上。因此,当 IBM 或 SAP 等公司宣布因人工智能而裁员时,更准确的说法应该是:“我们将员工编制从传统职能部门重新分配到了我们增长最快的业务线。”这只是围绕商业变现机会进行的常规企业重组,而非技术对劳动力带来的排挤。

为什么编程智能体不会导致岗位被取代:“决策-执行-交付 三明治”模型

许多科技巨头的高管(如上文提及的 Snap 首席执行官)在发布裁员报告或预测未来失业时,总是喜欢晒出由人工智能编写的代码比例。这助长了一种简单粗暴的思维模式:一旦人工智能包揽了所有代码,程序员就失业了。幸运的是,这种思维模式是错误的。这个“人工智能编写代码比例”的指标,与真正决定劳动力是否被取代的核心因素几乎完全脱节。原因如下。

编写代码本身现在不是,过去也从来不是整个流程的瓶颈。比方说,2019年的一篇论文在总结现有研究后得出结论:“开发人员编写代码的时间少得令人吃惊,根据研究不同,仅占9%到61%”。这一发现与该论文自身来自微软6000名开发人员的数据相吻合。随着编程智能体开始普及,2025年晚些时候网络上涌现出大量的技术博客,纷纷指出编写代码并非瓶颈所在,因为开发人员意识到,即便让智能体承包了绝大部分代码的编写,对整体生产力的拉动依然微乎其微。

如果写代码不是瓶颈,那什么才是?任务拆解调查指向了开会或调试(debugging)等事务。这又引出了更多疑问:开发人员在那些会议上究竟在干什么,为什么人工智能不能代劳?随着技术能力的提升,调试难道不会实现自动化吗?要洞察真正的瓶颈,我们必须进行定性分析,深入挖掘软件工程师自身对“他们工作中哪些部分无法被自动化”的深刻理解。

当开展这项分析时,我们发现真正的瓶颈在于以下三点:(1) 决定并明确要开发什么;(2) 验证并对交付的成果负责;(3) 开展前两项工作所必需的、人类对代码库、业务逻辑以及宏观环境的深刻洞察。

换句话说,软件工程师的工作是由“决策-执行-交付”构成的三明治(而理解则是这三者的先决条件)。人工智能极大地压缩了三明治中间的“执行”层,但两端基本保持原样。只要软件开发团队依然牢牢掌握决策权并对交付成果承担最终责任,工程师就仍需投入大量时间来建立对系统的深度认知。这就是三大瓶颈所在。

图:软件开发由三个层次组成:(1) 决策——问题定义、需求规范、规划;(2) 执行——设计与实现;(3) 交付——测试、验证、集成、维护等。请注意,这些是概念上的逻辑分层,而非时间上的先后阶段。在项目推进过程中,在这几层之间来回切换是家常便饭。

关于人工智能生产力效应的“三明治模型”,在一篇题为《编写代码 vs. 交付代码》的最新论文中得到了证实。通过对 GitHub 上10万名开发人员的观察,研究人员发现,人工智能智能体使编写的代码行数暴增了八倍,这印证了人工智能几乎将三明治的“执行”层压缩到了极致。然而,这仅仅带来了30%的发布版本(releases)增加,有力地证明了人类瓶颈(“决定”与“交付”层)依然坚固。

这个三明治还能被进一步压缩吗?我们认为不能。在工作流的一端,开发团队必须决定开发什么。初级软件工程师学到的最重要的一课就是:需求规范(行业内对这一层的术语称呼)耗时之长令人咋舌,如果强行压缩这一层,后续将会带来无尽的痛苦。这一层很难被自动化,因为它需要全盘权衡用户需求、市场信号、组织内部的优先级,在某些情况下还要兼顾法律合规约束。

随着人工智能能力的迭代,随着时间的推移,可以委派给人工智能的决策类型确实会增加。但这并不会让“决定”层变得更薄——因为一旦某个决策可以交由 AI 处理,它就不再是竞争优势的来源,而人类决策的价值链就会向更高维度迁移。软件的复杂度随着时间的推移不断攀升,因此这个进化过程是没有上限的。

在三明治的另一端,人类团队必须对交付的成果承担全部责任。或许在未来的某一天,团队会在没有完全测试和理解的情况下直接上线关乎企业命脉的核心代码(mission-critical code),但就目前而言,人工智能的不可靠性使得这种草率的行为会给软件团队及其客户带来灭顶之灾。

即使未来的技术壁垒不复存在,我们也不必向人工智能拱手让出控制权。将“人工智能视作普通技术”的核心洞察在于,我们可以通过共同的规范、法律和政策,集体选择让渡给人类来承担最终责任。比起试图遏制技术能力的研发脚步,这是一种在控制人工智能冲击速度并提升安全性方面更有韧性的途径。得益于侵权责任法和特定行业的监管法规,这些“减速带”已经在很大程度上发挥了作用,而且未来还可以进一步强化。

在这种愿景下,随着越来越多的执行层工作交由人工智能处理,软件工程师未来的角色将类似于起重机操作员。人工智能智能体将承担大部分的认知重活,而人类的核心工作转变为监督智能体并确保其处于受控状态。

一些评论家辩称,人类保持控制的未来不太可能实现,因为雇佣人类来做这件事的成本太高了。互联网上已经流传着几则广为传播的荒唐故事:由于缺乏有效监管,编程智能体竟然删除了生产数据库或造成了其他破坏。但我们认为这些只是“狗咬人不是新闻,人咬狗才是新闻”式的奇闻轶事,而非正在形成的行业常态。它们之所以能疯传,恰恰是因为这种极其不负责任且罕见的行为具有震撼效应,能够扮演警钟和反思契机的角色,帮助技术社群警惕对人工智能的过度依赖。正如一句老话所说那样:“如果一件事成了新闻,就不必过于焦虑”。不过,如何监测在整个经济体中(而不仅仅是在软件工程领域),在涉及重大利益的高风险任务上,缺乏监管使用人工智能的现象是否在抬头,仍是当下最紧缺的关键数据盲区之一。

顺便提一句,三明治被挤压并不是什么新鲜趋势,也并非人工智能所独有。早在二十多年前,美国劳工统计局就已开始将“程序编写”(programming)与“软件工程”(software engineering)分开统计。大概意思是指,程序员只负责执行,而软件工程师则管理着三明治中更大的版图。这不仅导致纯粹的编程岗位一直在萎缩,而且其薪酬也低得多,因为这个岗位被视作体力杂活。人工智能只是加速了这一早已存在的趋势,进一步贬低了纯技术性技能的价值。

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

在“决策-执行-交付”三明治的两端,人类依然深度参与,即使中间层正被人工智能加速自动化——这种模式似乎广泛适用于大多数知识型工作,尽管在软件领域其发展最为超前。毕竟,复杂的决策制断和责任担当是绝大多数行业所共有的。对这一现象缺乏认识,导致了许多对“大规模失业近在眼前”的盲目自信断言,比方说关于人工智能将取代放射科医生的预言。

氛围编程(Vibe coding)不等同于智能体工程(agentic engineering)

关于软件工程变革程度之所以产生混乱,原因之一是人们将“氛围编程”(vibe coding)这一术语宽泛且不严谨地套用在各种极其不同的工程实践上,而这道光谱两端的模式在概念上有着本质区别,且大相径庭。

在真正的“氛围编程”中,用户只需向智能体下达指令,在运行过程中不加监督,不审查生成的代码(甚至可能根本不具备审查的技术能力),也不评估最终的输出结果,除非出现了肉眼可见的严重崩溃。

这与大多数软件工程师实际使用智能体的方式形成了鲜明对比——他们将其视为一种工具,人类始终掌握着核心控制权并对输出结果负责。令人欣慰的是,“智能体工程”(agentic engineering)这一术语正在被广泛接受,用以准确描述这一实践。

随着智能体工程成为常态,工程师们正发现监督编程智能体其实出乎意料地耗费精力。比方说,知名开发者兼人工智能转型记录者西蒙·威利森(Simon Willison)就曾提到,由于需要不断监督智能体,他在上午11点前就已经筋疲力尽。这也与我们自身的实际体验高度吻合。

更多定量证据来自 SWE-chat——这是一个记录了自愿加入日志跟踪工具的开源开发者与编程智能体交互的数据集。研究发现,智能体生成的代码中只有44%能最终保留在用户的提交记录(commits)中;通过“氛围编程”方式提交的代码,其引入安全漏洞的概率是纯人工编程的九倍;而且用户最核心的诉求其实是理解现有代码,而非生成新代码(比例为19%对13%)。尽管该数据集由于样本的自愿性存在一定的筛选偏差,使我们无法单凭此项研究盖棺定论,但它无疑印证了来自其他维度的众多证据:氛围编程与智能体工程这两种模式是截然不同的。

智能体工程绝非氛围编程

需要重申的是,这两者并不是两个孤立的类别,而是谱系的两端,中间存在着模糊的过渡地带。并非每个项目要么是随手可丢的玩具,要么是关乎生死的关键系统。也不是每一个工作流都能精准地对号入座进表格的左栏或右栏。但这对应聘就业的核心启示是坚如磐石的——企业绝不可能通过雇用毫无资质的“氛围编程型码农”来取代软件工程师,并指望以此交付商业级的生产环境软件。

未来将走向何方?

人工智能的鼓吹者可能会辩称,大裁员时代终将来临,现在没发生只是因为接近人类水平的软件工程能力才刚刚崭露头角(或者尚未完全实现)。但如果三明治模型是正确的,这些末日预言就不会变成现实。人工智能已经基本上将三明治的中间层压缩到了极致(而这种压缩实际上在几十年前就已经开始了)。因此,即使让执行层变得瞬时且完美无瑕,与现状相比也只会有微弱的改变。另外两层之所以能够抵御人工智能的侵蚀,根本原因并非在于技术能力的局限。

事实上,软件工程师的岗位不仅不会因人工智能而消亡,对他们的市场需求甚至可能迎来一波激增。当由于技术带来生产力跃升,使得软件(或任何其他商品)的生产成本变得更低廉时,人们就会购买远比以前更多的软件(用经济学术语来说,软件具有极高的“价格弹性”)。而且正如我们所指出的,人工智能并不能直接取代软件工程师(两者的“替代弹性”很低),因此对更多软件的渴求,最终会衍生出对更多软件工程师的需求。在关于人工智能的辩论中,人们经常借用一个关系较弱但听起来更玄妙的经济学术语——“杰文斯悖论”(Jevons’ paradox)来描述这一概念。

从历史规律来看,这正是一直以来的发展轨迹——美国的程序员就业人数已从1950年前后的近乎为零,暴增至如今的数百万人。这与农业等行业形成了鲜明的对比,在农业中,由于机械化和自动化,劳动力需求遭遇了众所周知的毁灭性打击。两者的本质区别在于,人类能够消耗的卡路里总量是相对恒定的——即使仅仅增加25%也会引发大范围的肥胖危机——而人类社会所生产的软件总量却已经翻了百万倍。现在一辆现代化的汽车上,各大车载电脑里运行的代码行数就已高达上亿行。

如果说对代码的需求存在天花板的话,我们也还远远未触及到天花板。实质上,所有的认知型工作都能从软件中获益。随着人工智能降低了编程的门槛,人们正源源不断地创造出各式各样的“一次性小工具”——无论是为了工作还是个人娱乐——而在这之前,开发这些小工具在成本上是完全不划算的。

需要明确的是,尽管我们坚信未来的软件数量会呈爆炸式增长,且软件工程师的数量也很可能会增加,但这并不意味着科技巨头们会变得更加庞大。事实上,如今绝大多数软件工程师都任职于非软件类企业内部,而且这一比例在未来可能会进一步攀升。此外,目前还出现了一种“人工智能整合”(AI rollups)的思路,即风险投资或私募股权机构收购那些传统实体行业的“街边小店”——如牙科诊所、会计事务所等等——并通过向这些企业派驻软件工程师或人工智能工程师,将它们从底层逻辑重构成“AI原生”企业。当然,这最终也有可能沦为又一场资本泡沫和噱头。现在下结论还为时过早。

一些人预测,由于技术的“平民化/普及化”(democratization),市场对专业软件工程技能的需求将会下滑。他们承认未来产出的软件将比以往任何时候都要多,人类投入到软件开发上的总时间也会创下历史新高,但他们认为这些工作将由非软件工程师的人来完成。这种观点的核心在于,人工智能将使软件工程变得门槛极低,比方说,懂法律的人编写法律软件,会比懂软件工程的人来写更加得心应手。

或许吧。但我们对此持怀疑态度,并愿意赌它不会发生。在我们看来,这种想法跌入了同一个误区:把氛围编程与智能体工程混为一谈,把单纯的执行层等同于整个“决策-执行-交付”三明治。事实上,回顾编程的发展史,每逢新技术诞生,总会有人高呼我们正处于人人皆可编程的门槛上——当年的 FORTRAN、COBOL 和 SQL 等古老语言问世时,无一不承载着这种巨大的期许。可是这种期许从未真正实现。真正的门槛从来不是学习枯燥的语法,而在于是否具备足够成熟的专业判断力,能够在做出正确抉择的同时,承担起应有的责任。

归根结底,这或许只是一个词义上的争论。显而易见的是,人类投入到引导计算机执行新任务上的时间只会与日俱增。这可能会表现为开发软件,也可能是通过智能体管理复杂的业务工作流,或是其他崭新的形式。它将需要软件开发技能、人工智能素养以及行业垂直领域知识(domain expertise)的深度融合。至于如今的软件工程师是否会成为最能适应并胜任这些新角色的人群,仍有待历史的检验。

最后提到的“顺应变革之需”这一要点,恰好为本系列的下一篇文章埋下了伏笔。软件行业整体的劳动力需求有望保持强劲,但这并不意味着绝大多数个体劳动者能够置身事外。我们将在下一篇中指出,人工智能将引发软件生产方式的剧烈结构性转变,这将对软件工程师的利益重新洗牌——决定谁是赢家、谁是输家的因素,将取决于他们所在的系统企业类型、所处的地理区域、资历深浅,以及他们自我迭代与适应的进化速度。

延伸阅读

迪娜·穆萨(Deena Mousa)指出,那些仅凭“人工智能暴露度”等抽象指标对全行业经济冲击开展的宏观分析流于表面,她呼吁进行“严谨的、针对特定职业的细分研究”。我们希望本系列论文能够为客观、全面地认识人工智能对软件工程的颠覆性重塑贡献绵薄之力。此前,我们曾与贾斯汀·柯尔(Justin Curl)合著过一篇分析法律服务行业中人工智能应用的论文,深入探讨了使该职业独树一帜的监管规则及其他瓶颈。未来,我们计划开展更多针对具体职业的深度垂直剖析。

在40年前发表的经典名篇《没有银弹》(No Silver Bullet)中,弗雷德·布鲁克斯(Fred Brooks)精辟地指出了软件的“本质复杂度”(essential complexity)与“次要复杂度”(accidental complexity)的区别。他认为,软件的某些复杂度是次要的,源于当时技术的局限性(如编程语言的繁琐),随着开发工具的进化,这些问题会随时间推移而迎刃而解。但有些复杂度则是本质的,因为明确定义软件的正确运行逻辑本身就是一项极具挑战的硬核工作。他强有力地论证了为什么三明治的“决定”层如此厚重且难以被自动化取代。有趣的是,当年利用人工智能提升程序员生产力的呼声就已经非常高涨了!布鲁克斯指出,由于人工智能或任何其他技术只能削减次要复杂度,它绝不可能带来数量级式的生产力飞跃。(布鲁克斯是《人月神话》的作者,这本文集毫无疑问是人类历史上声誉最隆、影响力最深远的软件工程圣 经。《没有银弹》后来也被收录进该文集中。)

译者:boxi。