编译器当年也被说成终结编程

2031 年，某个周二早上 7:40，你还没写下一行代码。今天大概率也不会写，这没什么。

你睡觉的时候，四个 agent 处理完了你昨天下午整理好的待办事项。其中三个已经做完，它们的 pull request 正等着你，每个都附带了新增的测试、一段功能运行时的简短录屏，还有一份说明，列出它们拿不准的地方。第四个 agent 在凌晨 2:13 停了下来，只留给你一个问题：

规格里写的是退款退回原卡。这位客户的卡三月份就过期了。这种情况该怎么处理？

写退款代码，agent 可以写一整天。它做不到的，是替你决定公司该对一个卡已过期的客户负什么责任，所以它停下来发问，这正是你希望新员工做的事。你的早晨大概是这样：读三个 pull request，去找客服那边的人聊一聊，然后把规则写清楚，清楚到没人（不管是不是人）需要再猜一次。

那个周二是我编的。不过里面没有一样是科幻。如今已经有能在夜里无人值守地干活的 agent，其中一个每晚十点在我自己的机器上运行。它会自己设想一个小项目，把它做出来，再测试一遍，而我吃早饭的时候就能知道它做成了什么。第一个早上，我完全不知道它建了什么。那个项目现在叫 Rule Safari，是本网站上的一个在线项目，另有一篇文章讲它是怎么运作的。

那么，这是编程的终结吗？这个问题人们已经问了七十多年。我觉得这挺让人安心，也觉得有点可疑。

编程从 1954 年起就一直在终结

1954 年 11 月 10 日，IBM 的 Programming Research Group 完成了一份关于新语言 FORTRAN 的初步报告。报告里有一句话说，FORTRAN“应当几乎消除编码和调试”。

我很喜欢这句话。它自信得不得了，甚至还附带了预算：用 FORTRAN 解决问题，“成本不到”不用它时的一半。当时业界对这类东西有个叫法。汇编器和编译器被称为自动编程。你描述你想要什么，机器来写程序。

FORTRAN 于 1957 年发布，它确实消除了一类编码工作。如今几乎没人再手工把公式翻译成机器指令了。调试则安然无恙地活了下来。（这个月我追查了一个 Scry 的 bug，最后发现根源是书签每十二小时才保存一次，所以我可以确认调试活得很好。）

FORTRAN 真正做的，是把工作中枯燥的那一部分拿走，让整个工作上升了一个层次。人们不再琢磨寄存器，转而思考更大的问题。写程序的成本降低了，于是人人都想要更多程序。从那以后，这件事一遍又一遍地发生。

我最喜欢的是 1981 年那一级。一家叫 D.J. “AI” Systems 的英国公司（没错，真叫这个名）卖过一款 BASIC 程序生成器，名叫 The Last One。名字本身就是全部卖点：它会替你写完所有程序，所以会是你这辈子需要买的最后一个程序。

评测者发现它对某些商业程序确实有用。但它并不是最后一个。

每一级台阶上的规律都一样：某样东西被自动化了，亲手做这件事的人不再亲手做了，而这个领域照样在扩张。GitHub 在 2025 年的报告里统计到超过 1.8 亿名开发者，其中 3600 多万是过去十二个月里新加入的。

所以我不认为 AI 会终结编程。我确实认为这一级有一处不同，那就是速度。GitHub Copilot 的预览版 2021 年 6 月发布。到 2025 年，Stack Overflow 调查中 84%的开发者已经在用或打算用 AI 工具。四年，从新鲜玩意变成默认选项。

2026 年的真实图景

眼下气氛很热闹，那就先从数字说起。（说到气氛：Andrej Karpathy 在 2025 年 2 月造了“vibe coding”这个词，指的是那种你“彻底交给感觉”的编程方式。Stack Overflow 当年就问了这件事。72%的开发者说它不属于自己的职业工作，另有 5%说坚决不是。我很喜欢他们居然提供了这个选项。）

Stack Overflow 的调查是我们手头规模最大的定期体检，里面的采用曲线很陡：2023 年 70%的开发者已在用或打算用 AI 工具，2025 年升到 84%，其中一半的职业开发者每天都在用。

你大概会以为用得这么多，开发者应该很爱这些工具。并没有。好感度从 2023 年的 77%跌到 2025 年的 60%，今年才回升到 62%。2025 年，不信任 AI 输出准确性的开发者（46%）多于信任的（33%）。最让人头疼的问题，66%的人选了“AI 给出的方案差不多对，但又不完全对”。

我深有同感。差不多对是一种很贵的错，因为你得逐行读过去，才能找出不对的那一处。（45%的人说，调试 AI 生成的代码更费时间。）

要说整个 AI 热潮里我最喜欢的研究，那得数它，主要是因为它太不留情面了。2025 年初，非营利研究机构 METR 做了一次规范的随机对照试验。16 名经验丰富的开源开发者在自己维护多年的仓库里处理了 246 个真实 issue，每个 issue 被随机分配为允许使用 AI 工具或禁止使用。

开工之前，这些开发者预计 AI 能把他们的用时缩短 24%。做完之后，他们相信自己确实缩短了 20%。而计时结果说：用了 AI，他们多花了 19% 的时间。

多花了 19%！可他们干完还笃定 AI 帮上了忙。

在有人截图拿去发暴论之前，先说清楚：那只是一项针对十六个人的研究，用的是 2025 年初的工具，代码库还是他们比任何模型都更熟悉的。

而且 METR 试着重做了一遍。2025 年 8 月启动了一项规模更大的研究，57 名开发者、800 多个任务，到 2026 年 2 月，METR 表示数据太不可靠，没法作为依据。主要原因是开发者不断拒绝参与，因为他们“不愿意在没有 AI 的情况下工作”。早期数字暗示回归的开发者提速了 18%（区间宽到足以包含完全没有提速）。

我觉得这是史上最“2026 年”的实验失败方式。人们拒绝加入没有 AI 的那一组。

我从 METR 那里得到的结论比任何标题都更窄，也更有用：你感觉有多快，不是一种测量。 如果你想知道 AI 是否让团队变快，就按你测量其他任何东西的方式去测。

那条一直向上的线

METR 另一个大项目追踪的是 AI agent 能独立完成多长的任务。他们让人类专家为一组软件任务计时，然后找出 agent 有一半概率成功的任务长度。2019 年，GPT-2 能完成一个人大约三秒钟的任务。2023 年 GPT-4 到了大约四分钟。2025 年 2 月，Claude 3.7 Sonnet 达到一小时；一年后，Claude Opus 4.6 达到约十二小时。

在整个序列中，这个数字大约每六个月翻一番。自 2023 年以来，更接近每四个月翻一番。

一张末端拖着虚线的对数坐标图，正是许多糟糕预测的起点，所以我得谨慎些。“一半的时间”这个说法在定义里承担了太多分量。基准测试的任务比你的代码库干净得多。而且 METR 在九月就停止更新那个页面了。但如果这条线大致还能延续下去，到 2028 年前后，agent 就能有一半的时间完成人类一个月的工作量。我的“2031 年星期二”就是这么来的。不是凭空捏造，是从一张对数坐标图里拽出来的。而坐标图不过是带坐标轴的凭空捏造。

造这些东西的公司，已经活在这样一个版本里了。Google 在 2024 年 10 月说，其新增代码中有超过四分之一由 AI 生成，六个月后这个数字变成“远超 30%”。2025 年 3 月，Anthropic 的 Dario Amodei 预测 AI 将在三到六个月内写出 90%的代码。那次太早了。但到 2026 年 5 月，Anthropic 表示合并进自家代码库的代码中，超过 80%由 Claude 编写。

代码变便宜了，队列就往前挪

流程中某一步变快，活儿就会堆在下一个最慢的环节前面。周六晚上在餐厅后厨干过的人都懂：烤架提速了，盘子就开始在出餐口排队。

软件团队正在经历的就是这个。2025 年，Faros AI 分析了 1,255 个团队、超过 10,000 名开发者的遥测数据。AI 采用率高的团队，开发者完成的任务多了 21%，合并的 pull request 多了 98%，而他们的评审时间上升了 91%。

Faros 在 2026 年又做了一次，覆盖 22,000 名开发者。人均任务完成量上升 34%，听起来不错，直到你读完剩下的部分。评审时间中位数涨到了原来的五倍。31%的 pull request 在完全没有任何评审的情况下被合并，而事故与 pull request 的比例翻了三倍多。

代码变便宜了，读代码变贵了，有些团队就悄悄不读了。这很要命，因为代码并不总是好的。Veracode 在 2025 年用 80 个编程任务测试了 100 多个语言模型，45%的结果存在安全漏洞。GitClear 发现，复制粘贴的代码行占变更代码的比例从 2021 年的 8.3%升到 2024 年的 12.3%，而移动的代码（重构会产生的那种）从大约四分之一降到不足 10%。

也替维护者想一想。curl 负责人 Daniel Stenberg 从 2025 年 5 月起开始封禁提交“AI 垃圾”漏洞报告的人。他写道，这个项目“实际上正在遭受 DDoS 攻击”。2026 年 1 月，curl 关停了漏洞赏金计划。

Fred Brooks 早在 1986 年就预见到了这件事的某个版本。在《没有银弹》中，他借用亚里士多德的说法，将软件的困难分为两类：本质与偶然。偶然是工具给我们带来的麻烦，比如语法、样板代码、跟构建系统较劲。本质则是他所说的“这一概念构造的规格说明、设计与测试”，说白了就是：想清楚这东西到底该干什么。AI 在偶然这一块正变得非常擅长。本质则是凌晨 2:13 那个退款问题，它还压在你桌上。

我们可能正在锯掉的那级梯子

这是数据里我最不喜欢的一部分。

2025 年 8 月，Erik Brynjolfsson 和斯坦福数字经济实验室的两位同事利用 ADP 的薪资数据，研究了谁在拿到录用。22 至 25 岁软件开发者的就业人数比 2022 年末的峰值下降了近 20%。年长的开发者没有明显变化。

今年 8 月，他们更新了这项研究，数据截至 2026 年 6 月。在受 AI 影响的岗位上，年轻劳动者的就业水平比“与受影响较小的同龄人保持同步”时应有的水平低 19%。有经验的劳动者没有出现可比的差距。大部分效应来自企业从一开始就少招年轻人。

市场其余部分也谈不上红火。Indeed 的软件开发岗位发布指数比 2020 年 2 月低约 21%，此前在 2025 年 5 月曾触底至低 39%。

斯坦福的作者们谨慎地称其发现是描述性的，而非因果性的，况且 2022 年以来还发生了很多别的事。利率上升了，很多公司在疫情期间招了太多人（Indeed 指数在 2022 年初的峰值超过 2020 年水平的两倍）。但这个模式与 agent 擅长的事情吻合得令人不安：那些小而定义清晰的工单，我们过去常交给团队里的新人。

高级工程师是在工作中练出来的，主要靠在真实团队里当 junior：做无聊的工单，把生产环境搞挂一次，然后有人好心地解释为什么。如果 agent 把所有无聊的工单都接走了，下一个高级工程师从哪里来？如果你没写过多少代码，就很难把代码评审做好。

我没有一个简单的答案。我的猜测是：2035 年做得好的团队，会是那些在 2026 年继续招初级工程师、并给了他们另一种学徒期的团队，也就是让初级工程师在资深工程师身边审查 agent 的产出，端到端负责一个小系统，并撰写 agent 据以构建的规格和测试。写这些规格和测试是一份正经工作，它可能成为那份工作。

关于 2031 年的五个猜测

好，现在进入猜测环节。收藏这个页面，2031 年回来笑话我。

团队变小，团队数量多得多。 据 Y Combinator 的 Jared Friedman 说，2025 年冬季批次里有四分之一，代码库大约 95% 是 AI 生成的。今年 2 月，Block 裁掉了约 4,000 个岗位，Jack Dorsey 把原因指向 AI 工具和“更小、更扁平的团队”。这一点我可能判断错了，但我仍然不认为这些加起来等于软件岗位总量减少，美国劳工统计局也不这么认为，它预测 2025 到 2035 年，软件开发人员、QA 分析师和测试人员的岗位将增长 10%。

东西变便宜了，我们往往就想要更多。经济学家称之为杰文斯悖论，得名于 William Stanley Jevons，他在 1865 年论证说，更高效的蒸汽机会让英国烧掉更多的煤。过去要一个团队做一个季度的软件，将来一个人一周就能做完，而许多以前没人负担得起去解决的问题，会突然变得值得解决。

规格和测试成为源头。 今天我们把手写代码当作自己拥有的东西，把规格当作没人读的文档。我认为这会反过来。规格和测试变成你审阅、争论的对象，代码则更像编译器的输出：你可以打开它、检查它，但很少手工编辑它。（没错，这又是 1954 年那个承诺。也许这次能站住。）

面向一个人的软件。 我那个每晚运行的 agent 会做一些没人要求的东西，包括我自己也没要求，其中有些还挺讨人喜欢。当一个能用的工具只花一个晚上而不是一个季度，人们做软件就会像今天做电子表格一样：为一个问题、一个人而做，用完就扔。

读代码会成为一门职业。 我们的整个职业生涯几乎都建立在写代码上，围绕读代码建立的职业却几乎没有。我认为这会改变：招聘网站上会出现“验证工程师”之类的岗位，工具也会好得多，能把录屏、风险代码行和 agent 没写的测试直接摆到评审者面前。Faros 的数据说明，不用等到 2031 年，现在就需要。

每个改动都带标签。 我认为 pull request 以后会常规性地写明：是谁或什么写的、谁检查过、实际验证了什么。我已经在小范围这么做了：我的夜间 agent 构建的每个项目，都会在 README 和这个网站上注明这一点。

回到周二

FORTRAN 确实消灭了一类编码工作，但没有消灭程序员。它造就了多得多的程序员，去解决更难的问题，调试也跟着一起来了。

我认为 AI 做的是同一件事，只是更快、更乱。2031 年的开发者，一天下来是在决定什么东西应该存在，把它讲清楚到机器能照着做出来，再检查交回来的东西对不对。这从来都是最难的部分。我们只是以前忙着敲代码，留给它的时间太少。

你现在的周二是什么样子？你 review 的代码是不是已经比写的多了？在评论区告诉我。我想知道我上面的猜测是不是已经错了。