当Agent又刷新一个编码榜单时不妨少问一句“它还要多久替代我”不妨多想一下如果代码已经不再稀缺我还能不能把问题选对把系统交付好并为最后的结果负责Writing code was never the bottleneck.写代码从来不是软件工程真正的瓶颈。最近普林斯顿大学教授Arvind Narayanan在ICML 2026上的一场演讲中提出了一个问题。当AI越来越能干未来还有什么工作留给我们过去半年Coding Agent的进步几乎都能在IDE里摸到速度一天比一天快。可开发者并没有因此变得清闲。需求还是要理方案还是要定AI交回来的代码照样得审。NarayananAgent确实压缩了编码时间只是编码原本就没有占满整个项目。那些藏在编码前后的工作现在反而更显眼了。代码出来更快项目周期没有跟着缩短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又刷新一个编码榜单时不妨少问一句“它还要多久替代我”不妨多想一下如果代码已经不再稀缺我还能不能把问题选对把系统交付好并为最后的结果负责