AI 把编程这件事接管之后，作为程序员的我该何去何从？

编者按：当“AI 正在接管编程”成为技术圈最热门、也最容易被情绪化传播的话题之一时，真正值得追问的，或许并不是“程序员会不会消失”，而是：当代码生成越来越廉价之后，软件工程中真正稀缺、也真正不可替代的能力，究竟会转移到哪里。这篇文章并不回避 AI 对初级开发岗位带来的真实冲击，也不满足于重复“程序员不会被替代”的安慰性判断。作者试图回答的是一个更具体、也更现实的问题：在 AI 已经深度介入编码流程之后，工程师的核心价值是否正在从“写代码”转向“定义问题、设计验证机制、控制风险并完成系统交付”。 前一阵看到一条新闻，Claude Code 的创建者 Boris Cherny 在一档播客里说“编程被解决了”。这句话被国内不少自媒体反复引用，标题取得很重——“程序员的时代结束了”、“AI 替你写代码的时代来了”。 如果你真去翻那期原始播客，会发现节目的标题写得相当克制：「Head of Claude Code: What happens after coding is solved」——重点不在“被解决”，而在“之后”。Boris 在节目里坦白自己自去年 11 月起一行代码都没手写过，每天提交几十个改动都靠 Claude Code，但他紧接着补了一句：所有合并请求仍然要先过 Claude 自动审一遍，再过一道人工审核这一关。主持人 Lenny 在节目里替他总结了这件事——以前的瓶颈是写，现在是审。 这个细节在传播过程中被删掉了。但被删掉的不是无关紧要的修饰，恰恰是整件事最有信息量的部分：编程没有被消灭，它的瓶颈从一处转移到了另一处。问题是——转移到哪了？转移之后，做软件工程的人到底要做什么？ 这些也是这篇文章想回答的问题。我首先会承认 AI 在替代论上确实命中的那一部分，然后再解释为什么“程序员要失业了”是夸大其词，最后尝试给出一个具体的判断：工程师的工作正在从一种活变成另一种活，那个新的活叫什么、怎么练。 真的有人在被替代 先说真的那部分。 斯坦福数字经济实验室在 2025 年中期发布的一组数据显示，22 到 25 岁的软件开发者就业率，自 2022 年底高峰起已经下降了将近两成。这是一条相当陡的曲线。同期更多的数据也在印证——全球初级开发岗位过去一年缩水两到三成，英国科技行业的应届岗位 2024 年缩减了近一半，2026 年第一季度全球科技公司裁员里，明确归因到“AI 替代”的占比从去年不到一成跳到了五分之一。 数字背后是岗位品类层面的塌陷。我不需要列举太多类型，几个例子就够了：纯切图的前端、写增删改查的初级后端、套模板做后台管理系统的工程师、刚毕业还在练手的新人。这些岗位的共同点是任务清晰、变种不多、出错容易看出来——也就是说，是 AI 现在最擅长接管的那一类。 如果你的工作是五年前那种入门级任务的当代版本，那 Boris 那句话对你来说就是真的。这一段没什么好安慰的，我也不打算用“AI 创造了更多新岗位”这种空话来搪塞。新岗位会有，但不一定落到你头上、不一定按你期待的速度落下来。 但替代论的另一半是夸大的 让我举三个反例。 第一个反例，AI 编程最热情的鼓吹者之一、前 OpenAI 的 Andrej Karpathy。他在 2025 年初创造了一个词 vibe coding，大致意思是“完全把代码托付给模型，连改动都不看一眼“。但同年十月他自己开源了一个叫 Nanochat 的项目（一个迷你版的 ChatGPT 完整训练管线），他在仓库的讨论区里很坦白地写道：这个东西基本上是手写的，我也尝试过让 Claude 和 Codex 帮忙，但它们做得不够好，反而帮倒忙——大概是因为这个仓库离它们见过的数据分布太远了。vibe coding 这个词的发明者，自己做严肃技术项目时回到了手写。原因不是模型不强，是模型没见过这种东西。 第二个反例更有意思，来自 Anthropic 官方。他们在一篇讨论“长任务智能体框架“的工程博客里，公开承认了 Claude 的一个失败模式：我们观察到的最严重的失败模式之一，是 Claude 倾向于把一个功能标记为完成、但实际上没有经过真正的测试。模型厂家自己说出这种话的分量很重——你要他们承认这件事，跟让一家车厂承认自己刹车在某些工况下会失灵差不多。 第三个反例是数据。已经有相当多学术研究在跟踪 AI 写的测试到底靠不靠谱，结论很不乐观。AI 生成的测试普遍偏向“正常路径“——也就是只检查代码在最理想输入下不出错，不会去构造边界值和坏输入。一个被广泛引用的实验中，AI 生成的测试在变异测试（一种衡量测试到底能抓多少 bug 的方法）下的得分只有四成左右，而专业工程师的水平通常在七成以上。另一个实验里，AI 生成的测试准确率只有 6.3%——也就是每一百条测试里只有六条是真正在检查代码该检查的事，其他都在做无效断言。 这三个反例放在一起，指向同一个结论：AI 不是不能写代码，是不能可靠地验证自己写的代码。它能造，但它没法判断造的对不对。 真正的分界线是“可验证性” 那 AI 能不能搞定一个项目，分界线到底在哪？ 很多人——也包括我自己最初的直觉——会把“AI 能不能搞定”对应到“项目复杂度”。小项目能全包，大项目就不行。但这个分法经不起推敲。Anthropic 自己用 Claude Code 来写 Claude Code，Cursor 团队用 Cursor 来写 Cursor，这些都不是小项目，是几十万行的产品代码。复杂度不是真分水岭。 更准的分法，我觉得是可验证性。具体说就是：一段代码写出来之后，确认它做对了的成本有多低？ 如果验证成本低——比如写一个小工具函数，跑一下输入输出就知道——AI 可以全包，验证可以彻底自动化，错了立刻能发现。 如果验证成本高——比如改一段并发逻辑，错了可能要在生产环境跑几天才显现；改一段支付链路，错了直接是钱的损失；改一段老代码，错了破坏的是十年前某个人在某种特殊场景下做的兼容；重构一个跨服务的接口，错了影响的是其他团队的代码——这种代码 AI 不是不能写，是它写完之后你没法快速判断对不对，怀疑的代价远大于实现的代价。 这条线划清楚之后，很多事就好理解了。Simon Willison 给过一条非常硬的判断：“我不会把任何我无法向另一个人解释清楚的代码合并到我的仓库。”翻译成工程语言就是：你能不能验证代码——以你自己作为标尺——是合并的前提。Redis 作者 antirez 也说过类似的话，他用了一个更工程化的比喻——人是用来帮代码跳出局部最优解和错误的。这个“跳出”，靠的不是写代码的能力，是判断代码偏离没偏离需求的能力。两个人说的其实是一回事。 一个翻车的实例 讲一个具体的故事。这是我自己最近一段时间的项目。 我用 Claude Code 加规范驱动开发的工作流，跑通了一个九个包的中型代码仓库（一个 AI 设计工程智能体）。其中有一个版本号叫 Sprint 3.3 的任务，是把现有的元素检查器从“只读”升级为“所见即所得 CSS 编辑面”——用户在预览界面里点中元素，直接拖滑块改 padding、改圆角、改阴影，改完一键让 AI 把变化写回源码。 这个 Sprint 又拆成 13 个子任务，前 12 个是实现，第 13 个是收官——跑手