2031年一个周二早上7点40分，你还没写代码，今天也不会写，但这没关系。你睡觉时，四个智能体（agent）处理你昨天下午排好的待办：三个完成，提交了拉取请求（pull request），附测试、录屏和存疑处；第四个凌晨2点13分停下问：退款退回原卡，但客户卡3月过期，怎么办？它能写退款代码，却无法决定公司该承担什么，于是问你。你上午看三个拉取请求，找客服沟通，写清规则，让人不再猜。

2031 年某个星期二早上 7:40，你还没写一行代码。你今天大概也不会写，而这没关系。

你睡觉时，四个智能体在处理你昨天下午整理好的积压工作。其中三个完成了。它们的拉取请求在等你，每个都附带它添加的测试、一段功能可用的简短录屏，以及一处它自己不确定的说明。第四个智能体在凌晨 2:13 停下，给你留了个问题：

规格说明说退款退回原卡。这位客户的卡在三月过期了。该怎么办？

这个智能体能写上一整天退款代码。它做不到的是：决定你的公司欠一位卡已过期的客户什么。所以它停下来问了，这也正是你对一个新员工所期望的。你这一天早上是这样过的：读三个拉取请求，去找客服的某个人聊聊，然后把规则写得足够清楚，让任何人（人类或其他）都不用再猜。

想象场景 · 2031 年，星期二

Agents：1 2 3 4

You：5 6 7 8 9 10

22:00 02:00 06:00 10:00 14:00 18:00 22:00

智能体

1. 22:00 三个智能体处理昨天的积压工作，并发起三个拉取请求，每个都带有测试和录屏。
2. 22:00 第四个智能体停下，留下一个问题：退款退到原卡，但那张卡已过期。
3. 13:00 智能体根据你写下的退款规则开始构建，并配上你先写好的测试。
4. 21:30 今晚的运行从你批准的计划开始。

你

5. 07:40 阅读三个拉取请求并观看录屏。
6. 09:00 回答凌晨 02:13 的问题。你还回答不了。
7. 10:00 询问客服同事，卡片过期的客户期望怎样处理。
8. 11:00 把规则写成一份简短的规格说明和五个测试。
9. 14:00 阅读智能体在涉及资金的那部分工作。
10. 16:30 批准今晚的计划。回家。

这是编出来的一天，好歹是按比例画的。红色标记是唯一几次工作等人来处理的时间。

那个星期二是我编出来的。但这都不是科幻。能在无人值守下通宵工作的智能体今天就存在，其中一个每晚十点在我自己的机器上运行。它会想出一个小项目，构建它，测试它，而我吃早餐时才知道它做了什么。第一天早上，我完全不知道它建了什么。那个构建现在成了 Rule Safari，是本网站上一个活着的项目，还有一篇文章解释它的工作原理。

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

编程自 1954 年起就在终结

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

我很喜欢这句话。它那么自信，甚至还带了预算：用 FORTRAN 解决问题的成本“不到不用 FORTRAN 时的一半”。当时行业里管这种事叫 automatic programming（自动编程）。汇编器和编译器就叫这个名字。你描述想要什么，机器就会写出程序。

FORTRAN 在 1957 年发布，它确实消除了一种编码工作。现在几乎没人再手工把公式翻译成机器指令了。调试倒是活得好好的。（这个月我追了一个 Scry bug，问题出在一个每十二小时才保存的书签上，所以我可以确认调试活得很好。）

FORTRAN 真正做的是：把工作中一项乏味的部分拿走，把整件事往上抬了一级。人们不再想寄存器，而开始想更大的问题。程序写起来更便宜了，于是所有人都想要更多程序。从那以后，这种事一遍遍发生。

1. 1947 汇编语言（Assembly language）你不再：把指令写成原始数字。Kathleen Booth，《Coding for A.R.C.》
2. 1957 FORTRAN你不再：手工把公式翻译成机器指令。1954 年报告称：它“应该几乎可以消除编码和调试”。
3. 1972 C你不再：为每台新机器重写同一个程序。
4. 1981 The Last One你不再：结果什么也没停。它是一个 BASIC 程序生成器，名字意思是“你永远需要买的最后一个程序”。
5. 2008 Stack Overflow你不再：独自解决每一条错误信息。
6. 2010 npm你不再：什么都自己写。
7. 2021 GitHub Copilot你不再：敲样板代码。
8. 2025 Coding agents你不再：敲大部分代码。
9. 20?? Next你不再：？

每一级阶梯都替程序员卸下了一项工作。虚线那一级承诺攀登已经结束了。

我最喜欢的一级是 1981 年。一家名叫 D.J. “AI” Systems 的英国公司（真的叫这个）卖了一个叫 The Last One 的 BASIC 程序生成器。名字本身就是卖点：它会替你写所有程序，所以它会是你永远需要买的最后一个程序。评测者发现它对某些商业程序有用。它并不是最后一个。

每一级阶梯的模式都差不多：某件事被自动化了，做这工作的人不再手工做那件事，但这个领域照样在扩张。GitHub 在 2025 年报告里数出超过 1.8 亿开发者，其中超过 3600 万人是在此前 12 个月内新加入的。

所以我不认为 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 生成的代码花的时间更长。）

Stack Overflow 开发者调查，2023 至 2026 年。2026 年的调查去掉了“使用或计划使用”这个问题，并重写了信任相关问题，所以这两条线只到 2025 年为止。2023 年约有 9 万名开发者作答，2026 年超过 3 万名。

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

开始前，开发者预计 AI 会把时间缩短 24%。做完后，他们认为 AI 缩短了 20% 的时间。而时钟显示：用了 AI，他们花的时间长了 19%。

长了 19%！而他们做完还确信 AI 帮了忙。

• 经济学家预测（专家预测）：时间减少 39%
• 机器学习研究者预测（专家预测）：时间减少 38%
• 开发者在任务前预计：时间减少 24%
• 开发者在任务后感觉：时间减少 20%
• 时钟实测：时间增加 19%

METR，2025 年 7 月：16 名开发者，246 个问题，主要工具是 Cursor 配 Claude 3.5 和 3.7 Sonnet。专家预测来自论文。变慢的幅度区间很宽，大约在 2% 到 39% 之间。

在有人截图拿去做爆款言论之前：这只是一个针对 16 个人的研究，用的是 2025 年初的工具，代码库他们比任何模型都熟。

METR 又试图再做一次。更大规模的研究在 2025 年 8 月启动，有 57 名开发者和 800 多个任务；2026 年 2 月，METR 说数据太不可靠，不能拿来下结论。主要是因为开发者不断拒绝参加，因为他们“不想在没有 AI 的情况下工作”。早期数字暗示，对回来的开发者有 18% 的提速（区间宽到完全可以包含零提速）。

我觉得这是一场实验失败得最 2026 的方式：人们拒绝加入没有 AI 的那一组。

我从 METR 得出的结论比任何标题都更窄，也更有用：你感觉多快，并不是一种测量。 如果你想知道 AI 有没有让团队更快，就像测量别的事情一样去测量它。

那条持续上升的线

METR 另一个大项目追踪 AI 智能体能独立完成多长的任务。他们让人类专家在一组软件任务上计时，然后找出智能体有一半概率能完成的那个任务时长。2019 年，GPT-2 能搞定大约占一个人 3 秒的任务。GPT-4 在 2023 年到了约 4 分钟。Claude 3.7 Sonnet 在 2025 年 2 月达到 1 小时，一年后的 Claude Opus 4.6 达到约 12 小时。

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

METR 的时间跨度（1.1 版）：以人类专家时间计算，每个模型有一半概率能完成的任务长度。METR 说，以它当前的任务集，超过 16 小时都不可靠，所以 Claude Mythos Preview 在 5 月测出的 17 小时没有画在线上。虚线部分延长了六个月翻一番的趋势。它是趋势，不是承诺。

一张对数坐标图，末端还有虚线，是很多糟糕预测的开始，所以我得小心。这个定义里“一半时间”承担了很多分量。基准任务比你的代码库干净。而且 METR 在 9 月就停止更新那个页面了。但如果这条线大致继续下去，到 2028 年左右，智能体将有一半概率能处理一个月的真人工作。我那个 2031 年的星期二就是这么来的。我不是凭空捏造的，我是从一张对数坐标图里拽出来的——那是有坐标轴的稀薄空气。

造这些东西的公司自己已经活在某种版本里了。Google 在 2024 年 10 月说，超过四分之一的新代码由 AI 生成；半年后这个数字是“远超 30%”。2025 年 3 月，Anthropic 的 Dario Amodei 预测 AI 会在三到六个月内写出 90% 的代码。这话说得太早了。但到 2026 年 5 月，Anthropic 说合并进自家代码库的代码里，超过 80% 是 Claude 写的。

当代码变得便宜，排队就发生了转移

把一个流程中的某一步变快，工作就会堆到下一个最慢的步骤前。任何在周六晚上后厨干过活的人都懂：把烤炉提速，盘子就会开始在传菜口等着。

软件团队正在经历的正是这个。2025 年，Faros AI 查看了 1,255 个团队、超过 1 万名开发者的遥测数据。AI 采用率高的团队里，开发者完成的任务多 21%，合并的拉取请求多 98%，而他们的评审时间增加了 91%。

Faros 在 2026 年用 2.2 万名开发者又做了一次。每名开发者的任务完成量上升 34%，这听起来不错，直到你看到后面的数：评审时间中位数长了五倍。完全没有经过任何评审就合并的拉取请求多了 31%，事故与拉取请求的比率增加了两倍多。

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

也替维护者想一想。curl 的负责人 Daniel Stenberg 在 2025 年 5 月开始封禁提交“AI 垃圾”漏洞报告的人，说这个项目“实际上被 DDoS 了”。2026 年 1 月，curl 关掉了它的漏洞赏金计划。

• 决定要做什么
• 写下来
• 写代码
• 评审
• 检查是否能跑
• 发布并运行

今天：代码到达的速度超过人们能读的速度，所以拉取请求等着被评审。

条形大小只是示意，并非实测。2026 年的形状依据上面 Faros AI 的数字；2031 年那个是我的猜测。切换年份可以看到工作卡在哪里。

Fred Brooks 在 1986 年就看到了这种情况的一个版本。在《No Silver Bullet》里，他借用亚里士多德的说法，把软件的困难分成两类：本质（essence）和附属（accidents）。附属是工具给我们造成的麻烦，比如语法、样板代码和跟构建打架。本质则是他所说的“这个概念结构的规格说明、设计和测试”，说得花哨一点，就是：搞清楚这东西到底应该做什么。AI 正变得非常擅长处理附属问题。本质就是凌晨 2:13 那个退款问题，而它仍然在你桌上。

我们可能正在锯断的那一级阶梯

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

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

今年 8 月，他们用截至 2026 年 6 月的数据更新了研究。在受 AI 影响岗位上的年轻劳动者，现在比“若与受 AI 影响较小的同龄人同步增长”本应达到的水平低 19%。有经验的劳动者没有可比的差距。这种影响主要来自公司一开始招聘的年轻人就变少了。

市场其他部分也不算火热。Indeed 的软件开发岗位招聘指数比 2020 年 2 月低约 21%，此前在 2025 年 5 月曾触底，低了 39%。

斯坦福的作者们谨慎地称其发现只是描述性的，不是因果性的；2022 年以来还发生了很多别的事。利率上升了，很多公司在疫情期间雇了太多人（Indeed 指数在 2022 年初的峰值达到 2020 年水平的两倍多）。但这个规律和智能体擅长的事情吻合得让人不安：那种我们以前交给团队新人的、小而明确的任务单。

高级工程师是在工作中炼成的，主要是先在真实团队里当初级：做无聊的任务单，把生产环境搞崩一次，再有个好心人解释为什么。如果智能体把无聊的任务单都拿走了，下一代高级工程师从哪来？如果你没怎么写过代码，就很难好好评审代码。

我没有干脆的答案。我猜，2035 年过得好的团队，会是那些在 2026 年仍继续招初级、并给他们另一种学徒训练的团队：在高级工程师旁边评审智能体的工作，端到端负责一个小系统，以及编写智能体赖以构建的规格说明和测试。写这些规格说明和测试是一份真正的工作。它有可能变成那份核心工作。

关于 2031 年的五个猜测

下面是五个猜测。

团队会变小，但数量会多很多。 据 Y Combinator 的 Jared Friedman 说，2025 年冬季批次里有四分之一的团队，代码库大约 95% 由 AI 生成。2 月，Block 裁了约 4000 人，Jack Dorsey 提到 AI 工具以及“更小更平的团队”。这一点我可能错了，但我仍然不认为这总体上会等于软件岗位变少；美国劳工统计局也不这么认为，它预测 2025 到 2035 年软件开发者、QA 分析师和测试人员的岗位将增长 10%。

当某样东西变便宜，我们往往会想要更多。经济学家称之为杰文斯悖论（Jevons paradox），名字来自 William Stanley Jevons；他在 1865 年提出，更高效的蒸汽机会让英国烧掉更多煤。以前要一个团队干一个季度的软件，以后一个人一周就能做出来；很多过去没人付得起钱去解决的问题，会突然变得值得解决。

规格说明和测试成为源头。 今天我们把代码当成拥有的东西，把规格说明当成没人读的文档。我认为这会翻转过来。规格说明和测试变成你评审和争论的对象，代码则变得更像编译器的输出：你可以打开检查，但很少会手工编辑。（没错，这又是 1954 年的承诺。也许这次能成真。）

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

读代码会成为一种职业。 我们有一整个围绕写代码的职业生涯，却几乎没有围绕读代码的。我预计这会改变，招聘板上会出现类似“验证工程师”的职位，工具也会好很多：向评审者展示录屏、有风险的代码行，以及智能体没写的那些测试。Faros 的数字说，我们今天就需这个，更别说 2031 年了。

每次改动都会带标签。 我认为拉取请求通常会写明是谁或什么写的、谁检查的、以及实际验证了什么。我已经做了一个小型版本：我每晚运行的智能体构建的每个项目，都会在 README 和本网站上说明这一点。

回到星期二

FORTRAN 确实消除了一种编码工作。它没有消灭编码者。它让编码者多了很多，在更难的问题上工作，而调试也跟着一起来了。

我认为 AI 也在做同样的事，只是更快、更乱。2031 年的开发者整天都在决定该存在什么，把它解释得足够清楚，让机器能构建出来，然后检查返回的东西是否正确。这一直都是最难的部分。我们之前只是忙着敲键盘，没那么多时间做它。

社区讨论围绕「把 LLM 编程代理类比成编译器，并预言 2031 年开发者不再写代码」展开。多数人不接受「AI 就是编译器」的简单类比，认为它混淆了确定性、可验证的翻译与非确定性生成；但很多人同意抽象层级会继续上移，真正分歧在于未来程序员是转为写规格、管理并评审代理，还是仍必须靠代码保证精确性与可维护性。

认为把 LLM 代理类比成编译器是错误比喻

• 编译器接收严格定义的编程语言，输入输出大致一一对应、可预测、可证明；自然语言开放且多义，LLM 从模糊想法直接生成完整实现，非确定性且会出错或作弊，不能像编译器那样被无条件信任。若硬说 AI 会达到编译器级的零错误可靠度，那只是换了外衣的极端预期。（较多人） > 编译器输入与输出大致一一对应，而 LLM 拿到一个想法就能一路生成到底，两者根本不是同一类东西。（@jacquesm）

认为编译器只是消灭了某类编码，并未消灭编程或程序员

• 早期编码指把纸上程序译成机器码、手工分配寄存器、处理数值机器码；Fortran 等让人不再做机器相关编码和编码纠错，但“编码”的含义后来变成写高级语言代码。结果不是程序员变少或编程结束，而是人们少写汇编、转向更难问题，程序员数量反而增加，调试也保留下来。（较多人） > FORTRAN 消灭了一种编码，却没消灭编码者，反而让更多人去解决更难的问题，调试也跟着来了。（@lifeisstillgood）

认为 2031 年不写代码的场景已经部分发生，日常工作转向沟通代理与评审

• 有近 30 年经验的工程师自称现在不需要编程也能完成工作；有人认为文章里的 2031 例子在 2026 就已过时，几乎没有理由再用 PR，问题交给有上下文和规划的代理即可；有人已经每天和代理开视频会议过夜产出、讨论问题。也有人调侃文章里 2031 年周二早上还没写代码，就像自己今年的周二早上，只是 7:40 还没上班，代表这种日常已被部分人视为现实。（较多人） > 以我近 30 年经验来看，如今的工作体验就是我已经不需要编程也能做完事了。（@tmountain）

认为即便用代理生成代码，仍算编程且必须写规格并人工评审

• 用代理写可维护代码仍需提供规格，表面看是从关心语法变成关心规格，但因模型不确定且会走捷径，产出必须人审；若规格精确到了无歧义，那其实就是代码本身，历史会重演。（少数人） > 让 LLM 产出可维护代码的前提是给它规格，这仍然算编程，只是不必纠结语法；但它不确定又爱作弊，所以还必须评审。（@vatsachak）

认为 AI 擅长翻译与重复，独特项目价值仍要靠代码精确表达

• 低代码和可视化编程未成主流，是因为几乎每个项目都有独特之处，现成组件不适用，代码才能精确表达想要的东西；AI 很擅长重写、移植、反编译等“别人做过”的翻译工作，但那不是真正的编程，且不如原作。要注入独特价值，最精确的方式仍是写代码，而 AI 依赖文本只是因为过去过度依赖代码。（少数人） > AI 很擅长重写、移植这类“别人做过”的翻译工作，但项目要做出独特价值，最精确的表达方式还是写代码。（@GuB-42）

认为 AI 冲击所有信息类工作，程序员失业也没资格抱怨

• 这次工具变革确实不同于以往，编程职业可能进入新形态并出现失业；但考虑到过去 50 年软件行业自动化掉了大量其他职业，程序员并没有多少立场抱怨。更广泛地说，只要工作被描述为“盯着屏幕处理信息”，都会被 LLM 盯上，不限于编程。（少数人） > 这次确实不一样；即便软件工程师遭遇更艰难时期和失业，考虑到过去 50 年我们自动化掉了那么多职业，也没什么立场抱怨。（@BurningFrog）

有价值的补充

• 除了编译器，SQL、4GL 等也曾被视作新的抽象层，可见每一代都会出现“更高一层”的工具。（@jmclnx）
• 终端曾把编程从机房里的多人社交、女性参与变成对着绿色荧光屏的孤立工作，许多女性因此离开；这提示新工具可能重演对协作方式和从业者结构的冲击，而不仅是抬高抽象层级。（@dvh）
• “代理更像员工，编译器更像计算器”：编译器是确定性工具，代理则需要交代目标、管理过程并复核产出。（@ninininino）
• 早期“编码”指处理数值机器码、手工分配寄存器并把纸上程序译成机器码；Fortran 被视为转录数学记号，不算编码，编程语言去掉的是机器编码与编码纠错，并未放弃可精确推理的形式规格；Iverson 在图灵奖演讲中提出“记号作为思维工具”，说明高级语言与规格也会反过来塑造思考。（@layer8）
• 编译器最初被称为自动编码器，编译原指像编书一样把多个库例程拼成一个映像；后来术语重新洗牌，“编码”才变成泛指用任何语言写程序代码。（@kazinator）