写代码从来都不是软件工程的瓶颈！普林斯顿教授：AI越会写

来源：市场资讯

（来源：图灵人工智能）

单击上方“图灵人工智能”，选择“星标”公众号

您想知道的人工智能干货，第一时间送达

转自51CTO技术栈，仅用于学术分享，如有侵权留言删除

编辑 | 姜篇

Writing code was never the bottleneck.

写代码，从来不是软件工程真正的瓶颈。

最近普林斯顿大学教授Arvind Narayanan在ICML 2026上的一场演讲中，提出了一个问题。

当AI越来越能干，未来还有什么工作留给我们？

过去半年，Coding Agent的进步几乎都能在IDE里摸到，速度一天比一天快。

可开发者并没有因此变得清闲。需求还是要理，方案还是要定，AI交回来的代码照样得审。

Narayanan：Agent确实压缩了编码时间，只是编码原本就没有占满整个项目。那些藏在编码前后的工作，现在反而更显眼了。

代码出来更快，项目周期没有跟着缩短

Narayanan把软件工程画成了一块“三明治”：Decide、Execute、Deliver。

Decide：先弄明白客户要什么，需求是否成立，边界在哪里，准备怎么做。

Execute：编码和调试。Coding Agent最擅长压缩的就是这一层。

Deliver：理解改动、做集成、补测试、上线、维护，并且为结果负责。

在他的估算里，Execute原本可能只占三分之一。AI把中间这段加速了，前后的两段并不会自动消失。

演讲引用多篇工程文章：代码生成变快后，行业又重新发现“编码不是瓶颈”

软件工程的Decide-Execute-Deliver结构

拿修Bug来说，Agent很快就能给出一份diff。

可在它动手前，总要有人判断复现路径是不是对的，问题究竟在业务逻辑、数据还是基础设施。改完以后，还得看回归范围、兼容性、监控和回滚。

代码生成得越便宜，团队越容易同时尝试更多方案。方案多了，选择、审查和收尾不会跟着便宜。工作量只是从键盘前移到了判断与交付。

70%的正确率，为什么还不够进生产环境

演讲里还有一组数据，和每个准备把Agent接进流水线的团队都有关。

一个Agent准确率70%，听上去已经能干不少事。但这70%究竟是什么意思？是它在固定的70%任务上每次都做对，还是面对任何任务都有30%的概率突然失败？跑分表里，两者可能得到同一个数字；放进生产环境，差别却大得离谱。

Narayanan的团队把可靠性拆成四件事：一致性、鲁棒性、校准能力和运行安全。换成开发者熟悉的说法，就是：同一任务能不能稳定复现，环境稍微变化会不会失手，模型知不知道自己做错了，以及失败后能不能恢复。

过去两年，Agent能力快速上升，可靠性只提高了约5至10个百分点

Narayanan判断，现阶段协作型Agent仍会比全自动Agent更成功。

这也是为什么“让Agent帮我工作”和“让Agent独自接管工作”不是一回事。前者允许人随时改方向、补上下文、拦下危险操作；后者要求系统在没人盯着的时候依旧稳定。

只要任务牵涉生产数据库、密钥、支付或客户数据，5%的不确定性都可能贵得惊人。

对开发团队来说，落地顺序应该更朴素：先让Agent参与，再谈无人值守。

权限边界、可观测日志、测试门槛、人工审批和回滚路径没有补齐之前，别急着把一次漂亮Demo改名叫自动化。

Agent压缩的，只是软件工程中间那一段

AI擅长的任务，通常有一个共同点：答案容易验证。代码能不能编译，测试过没过，性能有没有提升，都能给出相对清楚的反馈。

麻烦在于，软件项目最早和最晚的决定，经常没有标准答案。客户嘴里那句“做得简单一点”到底指什么？该不该为了一个大客户改底层抽象？这次重构是还债，还是在制造另一笔债？模型虽然能给意见，但它拿不到全部组织背景，也不会替团队承担后果。

于是会出现一个反直觉结果：Execute越快，Decide和Deliver越忙。

以前两周只能做一个方案，现在一天能生成五个；以前功能排不上期，很多争议会自然消失，现在每个想法都有机会变成一个能跑的Demo。

团队没有少做决定，只是更早面对这些决定。

生产力提高10倍，就该少招90%程序员？

一个很常见的论调：如果Agent让工程师效率提高10倍，公司以后只需要十分之一的人。

Narayanan不认可这句话。

他和合作者检查了多起“AI导致裁员”的案例，发现相关公司往往先有财务压力，把裁员归因于AI更方便。

更深一层的问题是，软件需求并不是固定的一桶水。开发成本降低后，那些过去因为太贵而没做的内部工具、小众功能和个性化软件，反而会被重新提上日程。

“固定工作量谬误”：效率提高，并不等于社会上的总工作量保持不变。

软件工程一路从机器码走到高级语言、开源框架和云服务，每一轮都降低了开发门槛。

程序员没有因为工具更强而消失，软件反而钻进了更多行业、设备和流程。

Coding Agent会不会带来完全相同的结果还不能提前下结论，但把“代码写得更快”直接换算成“岗位按比例减少”，至少漏掉了需求扩张。

Boris把团队拆成五种人，最难省掉的是“收尾”

Claude Code负责人Boris Cherny最近也写过一组相似的观察。

他把未来产品团队分成五种人：Prototyper、Builder、Sweeper、Grower和Maintainer。

把这五种角色放回Narayanan的“三明治”，能看到一条很清楚的分界：

Agent最容易加速Prototyper和Builder手里的Execute；到了Sweeper、Grower和Maintainer，工作开始大量进入Deliver。

AI可以一口气生成几千行代码，却不会替团队决定哪些抽象该删，哪个指标才代表产品真的变好，某个兼容包袱能不能冒险拿掉。

生成第一版的门槛正在下降，把第一版收拾成长期可用的系统，仍然需要工程判断。

黄仁勋算了另一笔账：工程师越高效，公司越想多招

黄仁勋在达沃斯谈AI、生产力与就业。

黄仁勋在GTC Taipei 2026的演讲里，也回应了“AI会减少软件岗位”的说法。

他称这种推断是“complete nonsense”，并拿NVIDIA自己举例：软件工程师的数量还在增加。

他的逻辑很商业：如果一名工程师借助AI能产出更多有价值的软件，公司不会天然满足于原来的产出，再顺手裁掉剩下的人。只要新增产出还能换来收入，继续招人就有账可算。

Narayanan从劳动经济与软件流程出发，黄仁勋从企业回报出发，两人的论证路径不同，碰到的却是同一处：效率提高之后，工作总量并不会原地不动。

岗位内容会变，招聘结构会变，简单把人数除以生产力倍数，得不到真实答案。

程序员会变成“起重机操作员”

Narayanan用了一个很贴切的比喻：未来的知识工作者更像起重机操作员。机器负责重活，人负责控制、理解和判断。

这个比喻放到Coding Agent里，并不抽象。程序员的能力清单正在多出几项：

●会拆任务：把目标、上下文、边界、验收条件和风险交代清楚。

●会搭反馈回路：测试、日志、静态检查、性能指标都要让Agent读得懂。

●会审结果：看得出“测试通过”背后有没有漏掉业务边界、权限和兼容性。

●会管权限：知道哪些命令能自动执行，哪些操作必须停下来等人确认。

●会为上线负责：保留diff、审计记录和回滚路径，出了问题能定位，也能收回来。

演讲中的比喻：机器负责认知重活，人仍掌握控制权

这些能力过去也存在，只是在资深工程师、Tech Lead、SRE和产品负责人身上。

Agent把编码速度推高以后，它们会更直接地决定一个团队能不能把生成结果变成生产系统。

别把最好的学习窗口拿去等失业

有人相信AI很快会替代大部分工作，于是最理性的动作是趁技能贬值前尽快积累财富；

Narayanan相信，把AI当成放大器，趁现在补那些与模型互补的能力，包括主动性、品味和判断。

对开发者来说，这不是一句乐观口号。代码会继续变得便宜，责任不会。需求没想明白，Agent只会更快地做错；测试和审查不到位，它也会更快地把问题送进生产环境。

程序员的工作不会停在“亲手敲出每一行代码”。它会向前走到问题定义，向后走到验证、交付和维护。未来谁能把机器的速度真正应用到真实工程中，谁就更接近Narayanan说的那种“人与AI共同的超级智能”。

所以，当Agent又刷新一个编码榜单时，不妨少问一句“它还要多久替代我”，不妨多想一下：如果代码已经不再稀缺，我还能不能把问题选对，把系统交付好，并为最后的结果负责？