普林斯顿教授：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、生产力与就业。