上个月，一个程序员在 Hacker News 上发帖，标题叫《LLM 正在毁掉我的软件工程职业生涯，我不知道该怎么办》。 他说他现在每天的活儿是：让 AI 写代码，然后 review AI 写的代码。产出的速度确实翻了几倍，但他一点都不觉得自己变厉害了，只是从一个写代码的人，变成了一个给 AI 改代码的人。 底下吵成一锅粥。有人安慰他，有人说这是时代的必经之路，还有人劝他赶紧转行。 我看到这篇的时候，正好在跟进一个项目，做的是给康复系统的智能体做工程化。项目里最累的部分不是写代码，是判断——判断 AI 给出的方案对不对、边界有没有漏、异常路径要不要补。这些活儿看起来不炫技，但一件都省不掉。 所以我想认真回答一个问题： AI 真的会取代程序员吗？ 去年在 ICML 2026 上，普林斯顿大学教授 Arvind Narayanan 讲了一个把整个开发圈听愣了的观点。 他把软件工程切成三块，像一个三明治： Decide（决定） ：客户到底要什么，需求成不成立，边界在哪，准备怎么做。E xecute（执行）： 编码和调试。De liver（交付）：理 解改动、做集成、补测试、上线、维护，并且为结果负责。 然后他说了一句关键的话：Agent 压缩的是中间那一段。 中间那段，本来就没占满整个项目 很多人的直觉是：AI 写代码快了 10 倍，那开发就该快 10 倍。 Narayanan 的估算是—— Execute 原本可能只占三分之一 。 你让 AI 修一个 bug，它几秒钟就能甩给你一份 diff。但在你让它动手之前，总得有人判断：这个 bug 的复现路径对不对？问题到底出在业务逻辑、数据，还是基础设施？改完之后，回归范围多大？会不会影响兼容？监控和回滚要不要重新配？ 这些活儿，一件都没有因为 AI 变快而消失。 更扎心的是，代码生成得越便宜，事情反而越多。 以前两周只能做一个方案，现在一天能生成五个；以前很多功能因为排不上期就自然消失了，现在每个想法都有机会变成一个能跑的 Demo。 Demo 变多了，但决定该做哪一个的人，一个都没多。 于是就出现了一个反直觉的结果：Execute 越快，Decide 和 Deliver 越忙。 团队没有少做决定，只是 更早地、更多地面对这些决定 。 那个「70% 准确率」的坑 如果你想把 AI 接进工作流，这组数据你必须知道。 一个 AI 标称准确率 70%，听起来已经能干不少活了。但这个 70% 是什么意思？ 是它 固定在 70% 的任务上每次都做对 ？还是 面对任何任务都有 30% 概率突然翻车 ？ 跑分表里，这两种情况可能给出同一个数字。但放进真实生产环境，差别大得离谱。 Narayanan 的团队把「靠谱」这件事拆成了四块： 维度 大白话 一致性 同一个活儿，重复做十次结果一样吗 鲁棒性 环境稍微一变，它会不会失手 校准 它知不知道自己搞错了 运行安全 失败了能不能救回来 然后他们查了这两年的数据： AI 的能力曲线一路陡升，可靠性只涨了大约 5 到 10 个百分点。 这就是为什么行业里有个越来越明显的共识：现阶段，「让 AI 帮我干活」比「让 AI 独自接管」要靠谱得多。 前者允许你随时改方向、补上下文、拦下危险操作。后者要求它在没人盯着的时候也稳稳当当。 只要任务碰到生产数据库、密钥、支付或者客户数据——那 5% 的不确定性，贵得能让你哭。 硅谷两大佬说的其实是同一件事 有意思的是，Narayanan 和黄仁勋的论证路径完全不同，但碰到了同一块地方。 黄仁勋在 GTC 上被问到「AI 会不会减少软件岗位」，直接怼了一句：complete nonsense（纯属胡扯）。他的理由很商业：NVIDIA 自己的软件工程师数量还在增加。如果一个工程师靠 AI 能产出更多有价值的软件，公司不会刚好满足于原来的产出再把人一裁了——只要新增的产出还能换回钱，继续招人就有账可算。 Narayanan 讲得更有意思。他查了几起「AI 导致裁员」的案例，发现 这些公司往往先有财务压力，把裁员归因于 AI 只是更省事 。他借用了一个经济学的概念，叫「固定工作量谬误」。 这有个经典例子：ATM 银行机大规模铺开之后，银行柜员岗位不但没减少，反而变多了。因为取钱变便宜了，排队的人多了，业务量也涨了。 软件工程一路从机器码走到高级语言、开源框架、云服务，每一轮都降低了门槛。程序员没有因为工具变强而消失，软件反而钻进了更多行业和设备。 只是「代码写得更快」，不等于「岗位按比例减少」。中间漏掉的就是需求扩张这一项。 未来长什么样：起重机操作员 Narayanan 用了一个比喻，我觉得特别贴切——未来的知识工作者，会越来越像 起重机操作员 。 机器负责干重活，人负责控制、理解和判断。 放到 AI 编程上，这意味着程序员的能