Simon Willison 近日转引 Arvind Narayanan 和 Sayash Kapoor 的文章，把“AI 会不会让程序员失业”这个争议拉回到一个更可检验的问题：软件工程师的工作，究竟是不是主要由写代码构成。

两位作者的判断相当克制：目前已有证据足以反驳一种流行叙事——只要 AI 达到某个能力阈值，就会引发软件工程师大规模裁员。这个判断不等于 AI 对就业没有影响，也不等于岗位结构不会变化。它说的是，至少到目前为止，“大规模替代”还没有被数据和工作现场共同证明。

纽约 WARN 数据给“AI 裁员潮”降了温

文章引用了一个具体事实。2025 年 3 月，纽约州成为美国首个在 WARN Act 裁员申报中加入 AI 披露选项的州。完整首年里，超过 160 家公司提交 WARN 通知，但没有一家公司勾选“AI 相关裁员”。

这不是全美国数据，更不能外推到全球就业市场。纽约 WARN 只覆盖特定地区、特定规模和特定类型的裁员申报，也无法捕捉企业冻结招聘、岗位合并或外包变化。但它至少削弱了一个常见说法：AI 已经明确造成可见的大规模正式裁员。

软件工程之所以适合作为观察样本，是因为它常被视为最容易被生成式 AI 冲击的职业之一。GitHub Copilot、ChatGPT、Cursor、Claude Code 等工具都直接进入了开发流程，而且软件行业监管壁垒较低。如果连这个领域都还看不到清晰的大规模替代证据，那么对其他监管更重、现场责任更强的职业，判断就更应谨慎。

说法现有证据能支持什么不能支持什么
AI 已造成程序员大规模失业纽约 WARN 首年未显示 AI 相关裁员申报不能证明所有地区都没有影响
AI 能显著提升写代码效率编码、补全、生成样板代码更快不能等同于替代完整工程职责
软件工程师不会受影响岗位尚未被大规模替代不能排除招聘标准、团队结构变化

写代码提速，不等于软件工程自动化

这篇文章真正有价值的地方，不是替程序员“报平安”，而是拆开了一个常被混用的概念：写代码只是软件工程流程中的一段，不是全部。

AI 现在最擅长加速的是“把代码输入电脑”的环节。它能补全函数、生成测试样例、解释报错，甚至在明确任务下完成一段可运行代码。对于熟练工程师，这些工具已经是现实生产力，而不是演示视频里的玩具。

但工程团队的瓶颈经常不在打字速度。真正耗时、也真正昂贵的部分，往往是决定做什么、怎么拆任务、如何在旧系统里落地、出了问题由谁负责。会议和调试看起来像低效率环节，背后其实常常是需求冲突、技术债、权限边界和业务风险。

历史上也有类似参照。高级语言、开源框架、云服务、CI/CD 都曾大幅减少重复劳动，但它们没有消灭工程师，反而提高了软件系统的复杂度和交付频率。工具越强，组织越敢把更多业务放进软件里，工程责任也随之放大。

对工程师和管理者，真正变化在职责重心

Narayanan 和 Kapoor 把软件工程难以自动化的瓶颈归为三类：决定并明确要构建什么，验证交付并为结果负责，理解代码库、业务和运行环境。Willison 也承认，AI 可以辅助决策和验证；但他强调，人的深层理解仍是价值来源。

这对工程师的现实含义很直接。只会把需求翻译成代码的人，会被工具压缩价值；能弄清需求是否正确、方案是否可靠、上线后谁受影响的人，会更像 AI 工作流里的责任中枢。

对技术管理者也是如此。采购 Copilot、Cursor 或企业版大模型工具，不能只看“代码生成速度”。更该观察三件事：缺陷率有没有下降，需求返工有没有减少，资深工程师是否从重复编码转向架构、评审和交付把关。如果这些指标没有改善，所谓效率提升很可能只是把风险更快地写进代码库。

接下来最该看的，不是某个模型在基准测试里会不会多解几道编程题，而是企业是否开始把软件工程岗位成规模地改造成“少量人监督大量 AI 代理”的组织形态。目前这一步还没有被充分证明。AI 正在改变软件工程，但它替代的更像是部分动作，不是整套责任。