编译器也曾被视为编程的终结者:2026年数据揭示AI编程代理的真相
简而言之
AI编程代理不会终结编程;它们将自动化编程的另一个层面,就像1957年FORTRAN将公式转换自动化一样。这是一篇在hrih.si上发表并提交至Hacker News的广受讨论的文章所提出的论点,该文章在Hacker News上获得了150分和197条评论。文章自身的证据具有两面性:AI编程工具的使用率从2023年开发者中的70%上升至2025年的84%,但同期正面评价却从77%下降至60%,而METR进行的一项随机对照试验发现,经验丰富的开发者在自己代码库中使用AI工具时,耗时反而增加了19%,尽管他们认为自己速度提升了20%。
文章的核心主张是,软件工作的瓶颈已从编写代码转向审查代码,而编程中最困难的部分——决定应该构建什么——仍然需要人类来完成。Hacker News的评论者大多反驳了编译器的类比,认为编译器能从精确的输入产生精确、可重复的输出,而LLM则做不到这一点。
1954年的FORTRAN报告承诺消除编码和调试
1954年11月10日,IBM编程研究小组完成了一份关于新语言FORTRAN的初步报告。报告中指出,FORTRAN“应能几乎消除编码和调试”,并且问题解决的成本“不到”不使用它时“的一半”。那个时代的汇编器和编译器被统称为自动编程。
FORTRAN于1957年发布。它确实消除了某种类型的编码——现在几乎没有人再手工将公式转换为机器指令了——但调试仍然存在。文章作者提到,他曾在自己的项目中追踪一个错误,最终发现它源于一个每十二小时才保存一次的书签。
文章识别的模式是一致的:某些工作被自动化,从事该项工作的人不再手工操作,而该领域仍在不断增长。GitHub的2025年报告统计了超过1.8亿开发者,其中过去十二个月新增超过3600万。
抽象阶梯,正如文章所述
文章列出了一个时间线上的各个层级,每一级都移除了程序员的一部分工作:
- 1947年 — 汇编语言。 程序员不再使用原始数字编写指令。归功于Kathleen Booth的《A.R.C.编码》。
- 1957年 — FORTRAN。 程序员不再手工将公式转换为机器指令。
- 1972年 — C语言。 程序员不再为每台新机器重写同一程序。
- 1981年 — The Last One。 一家名为D.J.“AI”Systems的英国公司推出的BASIC程序生成器,其销售前提是这将是您需要购买的最后一个程序。评论者发现它对于某些商业程序很有用。但事实并非如此。
- 2008年 — Stack Overflow。 程序员不再独自解决每一个错误信息。
- 2010年 — npm。 程序员不再自己编写一切。
- 2021年 — GitHub Copilot。 程序员不再输入样板代码。
- 2025年 — 编程代理。 程序员不再输入大部分代码。
文章认为,这一层级与其它层级的区别在于速度而非本质:GitHub Copilot的预览版于2021年6月发布,到2025年,Stack Overflow调查中84%的开发者已使用AI工具或计划使用。从新奇到普及仅用了四年。
2026年数据的实际显示
采用率很高,但情绪并非如此。Stack Overflow的开发者调查是该文章引用的最大规模的定期调查,显示开发者使用AI工具或计划使用的比例从2023年的70%上升至2025年的84%,当时有一半的专业开发者报告每天使用。正面评价则呈相反趋势,从2023年的77%下降至2025年的60%,然后在2026年回升至62%。
2025年,更多开发者不信任AI输出的准确性(46%)超过信任它(33%)。被选为最令人沮丧的问题(66%的受访者选择)是“AI解决方案几乎正确,但并不完全正确”。45%的人表示调试AI生成的代码需要更长时间。
文章指出一个方法论上的注意事项:2026年Stack Overflow调查移除了“使用或计划使用”的问题,并重写了信任问题,因此这两条趋势线止于2025年。2023年有大约90,000名开发者参与回答,而2026年则超过30,000名。
Andrej Karpathy于2025年2月创造了“vibe coding”一词,用来指代“完全顺应感觉”的做法。当年Stack Overflow询问时,72%的开发者表示这并非他们专业工作的一部分,另有5%表示坚决不是。
METR的随机试验:感觉更快不是测量结果
文章称METR 2025年的随机对照试验是其在AI热潮中最喜欢的研究。十六位经验丰富的开源开发者在他们自己的代码库(他们已工作多年的项目)中处理了246个真实问题,每个问题被随机分配为允许或禁止使用AI工具。
开始前,开发者预计AI能将时间减少24%。完成后,他们相信AI将时间减少了20%。但时钟显示他们使用AI后耗时增加了19%。这种减慢有较宽的误差范围,大约在2%到39%之间。实验设置主要使用Cursor与Claude 3.5和3.7 Sonnet。论文中的专家预测则乐观得多:经济学家预测减少39%的时间,机器学习研究者预测减少38%。
METR从2025年8月开始尝试进行更大规模的复制研究,涉及57位开发者和800多个任务。2026年2月,METR表示数据过于不可靠,难以依赖,主要是因为开发者一直拒绝参与,因为他们“不想在没有AI的情况下工作”。早期数据暗示有经验的开发者提速18%,但误差范围足以包含完全没有提速的情况。
文章的要点刻意狭窄:感觉有多快不是测量结果。 团队如果想知道AI是否使他们更快,应该像测量其它事物一样去测量。
METR的时间跨度曲线:大约每六个月翻一番
METR的另一个主要项目跟踪AI代理能够独立完成多长任务。该方法是在一套软件任务上计时人类专家,然后找到代理能在一半时间成功完成的任务长度。
- 2019年 — GPT-2: 任务耗时约三秒。
- 2023年 — GPT-4: 约四分钟。
- 2025年2月 — Claude 3.7 Sonnet: 一小时。
- 一年后 — Claude Opus 4.6: 约十二小时。
纵观整个系列,这个数字大约每六个月翻一番;自2023年以来,接近每四个月翻一番。METR表示,目前任务下,超过16小时即不可靠,因此5月份Claude Mythos Preview的17小时测量值未绘制在线上。METR于9月停止更新该页面。
文章明确指出了这一预测的局限性:“一半时间”在定义中起了很大作用,基准测试任务比真实代码库更简洁,而对数刻度图上的一条虚线正是许多糟糕预测的开始方式。即使该趋势大致持续,代理大约在2028年将能在一半时间内完成相当于人类一个月的工作。
各实验室自身代码的报告
- Google在2024年10月表示,其新代码中有超过四分之一是AI生成的,六个月后这一比例“远高于30%”。
- 2025年3月,Anthropic的Dario Amodei预测AI将在三到六个月内编写90%的代码。文章指出这为时过早。
- 到2026年5月,Anthropic表示其自身代码库中超过80%的合并代码是由Claude编写的。
当代码变得廉价,瓶颈移至审查
文章的核心机制是一个排队论论点:加快流程中的一步,工作就会堆积在下一个最慢的步骤之前。Faros AI的遥测数据支持了这一点。
2025年,Faros AI查看了来自1,255个团队中超过10,000名开发者的遥测数据。AI采用率高的团队中的开发者完成的任务多21%,合并的拉取请求多98%,而他们的审查时间增加了91%。
Faros在2026年对22,000名开发者进行了再次分析。每位开发者的任务完成量增加了34%,但中位审查时间增长了五倍,31%的拉取请求在完全没有审查的情况下合并,而事件与拉取请求的比例增加了两倍以上。
质量数据也指向同一方向:
- Veracode在2025年测试了100多个语言模型在80个编码任务上的表现,45%的结果存在安全漏洞。
- GitClear发现复制粘贴的行占变更代码的比例从2021年的8.3%上升到2024年的12.3%,而移动代码(重构产生的代码)则从约四分之一下降到不足10%。
- curl的负责人Daniel Stenberg于2025年5月开始封禁提交“AI垃圾”错误报告的人,写道该项目“实际上正遭受DDoS攻击”。2026年1月,curl关闭了其漏洞赏金计划。
Fred Brooks早在1986年就曾区分过这个问题
文章将其论点基于Fred Brooks 1986年的论文《没有银弹》,该论文借用亚里士多德的术语将软件难度分为两类。偶然是我们工具给我们带来的麻烦:语法、样板代码、与构建系统作斗争。本质是“对这个概念构造的规格说明、设计和测试”——弄清楚这个东西应该做什么。
文章对本质的说明是一个虚构的代理,它在凌晨2:13停下来问问题而不是继续执行:
规格说明说退款应退回原卡。这位客户的卡已于3月过期。应该发生什么?
文章认为,代理可以整天编写退款代码,但它无法决定公司应该向一个卡已过期的客户提供什么。AI在偶然性方面变得非常擅长。本质问题仍然在人类的办公桌上。
初级招聘的崩溃是文章最不喜欢的部分
2025年8月,Erik Brynjolfsson和斯坦福数字经济实验室的两位同事使用ADP薪资数据研究了谁在被雇佣。22至25岁软件开发者的就业率比2022年末的峰值下降了近20%。年长开发者没有显著变化。
次年8月发布的一项更新(数据截至2026年6月)发现,在受AI影响岗位上的年轻工人比如果他们与受影响较小的同龄人保持同步时的水平低19%。经验丰富的工人没有显示出类似的差距。效果主要来自公司一开始雇佣的年轻人减少。
Indeed的软件开发职位发布指数比2020年2月低约21%,此前在2025年5月触底,低于39%。文章指出,斯坦福的作者称他们的发现是描述性的,而非因果性的,并且还有其他因素在起作用:利率上升,许多公司在疫情期间过度招聘——Indeed的指数在2022年初达到峰值,为2020年水平的两倍多。
文章的担忧在于学徒制。高级工程师是在工作中培养出来的,主要是通过在真实团队中担任初级工程师:处理无聊的工单,在生产环境发生一次事故,然后有某位善良的人解释原因。如果代理接走了无聊的工单,文章问道,下一代高级工程师从哪里来?并指出如果自己从未写过多少代码,很难很好地审查代码。其提出的答案是一种不同的学徒制——在资深工程师的陪同下审查代理的工作,端到端拥有一个小型系统,并编写代理构建所依据的规格说明和测试。
对2031年的五个猜测
文章以明确的预测结尾,这些预测以猜测的形式提出,未来可再审视:
- 团队规模变小,但数量更多。 根据Y Combinator的Jared Friedman的说法,Winter 2025批次中有四分之一的代码库大约95%是AI生成的。2月,Block裁减了约4,000个职位,Jack Dorsey指出AI工具和“更小更扁平化的团队”。文章仍然不认为软件职位总数会减少,引用了美国劳工统计局预计2025年至2035年软件开发人员、QA分析师和测试人员将增长10%的预测,并援引了杰文斯悖论——William Stanley Jevons在1865年认为,更高效的蒸汽机会让英国燃烧更多的煤。
- 规格说明和测试成为源头。 代码变得更像编译器的输出:可检查,但很少手工编辑。
- 为单一人群服务的软件。 当一个工具的成本是一晚上而不是一个季度时,人们会像今天制作电子表格一样制作软件。
- 阅读代码成为一门职业。 文章预计招聘网站上会出现类似“验证工程师”的职位,以及工具能向审查者展示记录、有风险的行以及代理未编写的测试。
- 每次更改都带有标签。 拉取请求将例行说明是谁或什么编写了它,谁检查过它,以及验证了什么。
Hacker News的反驳:编译器不是LLM
讨论中最常被提及的反对意见是编译器类比在确定性上不成立。正如一位评论者所说:
编译器应接受精确输入并可靠地产生精确输出,且可重复。如果LLM能做到这一点,它们就是编译器,我们就不会有这场讨论了。
另一位将差异视为作者身份而非翻译:
如果我写了一部小说,有人把它翻译成法语并出版,那就是编译器。如果我给某人一些简要笔记,由他替我写小说,那就是LLM。这些本质上是不同的东西。
第三位认为变化范围比编程更广:
使用编译器时,(大致上,不考虑优化)输入和输出之间存在1:1的对应关系。而使用LLM时,你有一个想法,它会从头到尾驱动整个过程。这与我们迄今所做的任何事情都不一样。专注于编程也很奇怪:LLM将影响所有与信息相关的工作。
历史纠正:“编码”的含义并非文章所暗示的
几位评论者认为,1954年FORTRAN的引文被断章取义了。一位解释称,编码一词最初是指将纸上写好的抽象程序翻译成机器码,而编译器最初被称为自动编码器:
编译一词更像是指链接:生成包含多个库例程的映像。换句话说,类似于将多部作品编成一本书。编译器出现后,编码一词转变为用任何语言编写程序代码。 [...] 尽管术语重新调整,具体现实是人们在汇编语言上工作减少,而不是工作的人减少或编程终结。
另一位评论者就FORTRAN提出了同样观点,指出它被视为转录数学符号,并不被认为是编码,并引用了IBM院士Iverson的图灵奖讲座,主题是作为思维工具的记号法。
“足够精确的规格说明就是代码”的反对意见
一位评论者反驳了文章关于规格说明和测试成为真相来源的预测:
足够精确的规格说明就叫作代码。这又是编译器故事的翻版。
同一位评论者指出,可视化编程和快速应用开发——Visual Basic是最典型的例子——并未出现在文章的时间线中,尽管它们在1990年代风靡一时,并且认为每个项目在某种程度上都是独特的,这就是为什么现成组件很少合适,以及为什么代码仍然是表达意图最精确的方式。在这种观点下,AI恰恰在您确实想要他人已经做过的事情时最为有效——重写、移植、反编译——这是翻译工作而非编程。
一条相关评论同意这一类比,但附有一个警告:“维护vibe coded代码需要向LLM提供规格说明。这仍然是编码,但您现在可以自由地只提供规格说明,而不必担心语法。由于它们是非确定性的并且喜欢作弊,您仍然需要审查。”
讨论中的其它线索
- 一位评论者观察到编译器类比已经在实践中得到验证:“我们现在确实基本只使用编译器。我上次阅读反汇编来解决问题至少是十年前了。”
- 另一位将这种转变与终端的出现相比较,后者将编程从共享机房带到了单人办公室,并指出在终端出现前许多程序员是女性,之后则离开了。- 一位评论者预测该职业将萎缩至设计:“在我的孩子一生中,成为一名程序员将像成为一名鞋匠。人们仍然会穿鞋,并参与制鞋。但工作将在于设计而非大规模生产。”
- 一个更直率的评价:“我认为这是悲伤过程的讨价还价阶段。”
- 一位评论者指出文章自身虚构的前提可能很快就会过时,回应凌晨2:13退款问题时说:“2031年:为什么不呢?”
- 另一位评论者描述了每天与代理开视频会议以审查通宵工作的做法,并链接了一个个人项目,该项目为模型提供了声音、身体和礼仪指令。
评论中提出的来源出处质疑
一位评论者声称,托管该文章的博客是在发表前不久创建的,目的是营销AI写的书籍,指出其关于页面上的占位文本(“示例介绍 · 用您的个人简介替换此内容。”),并声称当被问及写作中使用了多少AI时,作者在Reddit上屏蔽了他们。同一位评论者承认,文章的科学来源看起来研究充分,并非幻觉。这一说法未经证实,在此仅作为评论而非调查结果报告。
最终结论
文章自己的结论是,FORTRAN消除了一种编码,但没有消除程序员,而AI以更快速、更混乱的方式做了同样的事情。按照其描述,2031年的开发者白天要决定应该构建什么,足够清晰地解释给机器去构建,并检查返回的结果是否正确——这项工作一直是最困难的部分,而且程序员以前因为忙着打字而缺少时间去做。
文中最强有力的证据不是类比,而是测量差距:METR的开发者认为AI使他们快了20%,而时钟显示慢了19%,Faros AI的遥测数据显示审查时间增长五倍,而拉取请求量大约翻倍。无论编译器比较是否成立,瓶颈已经明显转移。