开发者分享阅读 Anthropic 论文的启发,讨论 AI 在代码生成中的角色与深远影响。
Anthropic 最近发布了《AI 自我构建时》这篇论文,解释了 AI 如何越来越多地帮助构建下一代 AI。如今,Anthropic 生产环境中 80% 以上的代码由 Claude 编写,工程师提交的代码量比 2024 年增加了约 8 倍。
我进入这篇论文时,心里带着我认为许多开发者现在都有的那种隐隐的焦虑。读完后,我感到不那么害怕了。
不是因为这些数字很小。实际上并不小。
那是因为在读完整篇论文后,我意识到 AI 变得更好的事情,并不是让开发者有价值的事情。执行速度在加快,成本在降低。但判断力——决定什么值得构建、结果是否真的有意义、何时应该质疑答案而不是接受它的能力——没有。这个区别在网络上的大多数讨论中被遗漏了,一旦你看到它,整篇论文读起来就会很不一样。
如果你想在阅读我的想法之前先读原文论文,这是链接:Anthropic 的《AI 自我构建时》。
趋势放缓
人类保持参与,但我们的工作方式改变了
递归自我改进
在过去的几个月里,我可能读了数百篇关于 AI 取代开发者的文章。
有些很有深度。有些显然只是为了吸引点击而写。但过了一段时间,它们开始混在一起,我注意到了一些有趣的事情。
最响亮的观点几乎从未来自讨论原始资料的人。它们来自对总结的总结、推文的截图,或专注于单一统计数据而忽视周围一切的标题。
所以当 Anthropic 发布《AI 自我构建时》时,我决定自己完整阅读,而不是等待别人来解释。
我预期会更加担忧。相反,我觉得网络上的讨论变得比论文本身更加戏剧化。
数字是真实的。速度是真实的。像 Anthropic 这样的公司内部发生的变化是真实的。这些都不应该被忽视。但这并不意味着这篇论文本身就能令人放心。有些数字确实令人震惊。但整体图景比互联网通常呈现的要复杂得多。
这不是要总结每一页。这只是讲阅读这篇论文如何改变了我对关于 AI 和软件工程讨论的看法。
在深入之前,有一点背景值得一提。Anthropic 发布这篇论文不是为了预测软件工程未来可能是什么样子。他们是为了解释他们在自己的工程和研究团队中已经看到的情况,因为 AI 成为了他们开发过程中更大的一部分。这个区别很重要。这篇论文主要是在描述他们已经观察到的变化,而不是他们只是希望会发生的变化。
我没想到的一点是,这篇论文花在对未来做出预测上的时间很少。相反,它从回顾过去开始。
作者们阐述了 AI 如何逐步成为 Anthropic 自身工程工作流的一部分,这个背景很重要,因为它改变了你阅读之后所有内容的方式。这篇论文不是在说"这是可能有一天会发生的事情"。它在说"我们是如何走到这里的"。
在早期,大约 2021 年到 2023 年,事情看起来和其他任何软件公司一样。工程师编写代码、审查 pull request、修复 bug 和做技术决策。AI 还不是开发过程的一部分。
然后它开始帮助完成较小的任务。起初,看起来很像我们许多人今天使用 AI 的方式。生成一个函数。解释一段代码。建议重构。工程师仍然在驱动每一步,而 AI 的作用更像是坐在编辑器旁边的另一个工具。
大约在 2025 年,这种关系开始改变。Claude 不仅仅是建议代码,而是开始处理工作流的更大部分。它可以编写文件、运行它们、检查输出、修复错误,并在一个人需要再次介入之前重复这个周期几次。工程师的角色并没有消失,但他们需要进行的动手实现工作量已经在改变。
根据论文,到 2026 年,这些工作流变得更加自主。AI 智能体能够工作更长的时间,在某些情况下,还能协调与其他智能体的工作。
论文中的一个例子使这种进程更容易理解。一次常规软件升级意外导致数万个 AI 训练任务失败。一位工程师让 Claude 访问环境,并提供了一些关于问题的背景。在大约两个小时内,Claude 识别了一个导致失败的晦涩配置标志,验证了修复,并解决了问题。根据作者的说法,同样的调查对一位经验丰富的工程师来说可能需要两到三天。
这样的故事本身就令人印象深刻,但它们仍然只是一个例子。让我信服的是论文用数据支持了它们。这些数字表明这不是一次性的成功,而是公司内部更广泛变化的一部分。
在讨论所有这一切意味着什么之前,值得看看这些数字本身。它们很容易被夸大。它们也很容易被忽视。两种反应都不是特别有帮助。
这个头条数据可能已经在社交媒体上传播开来。截至 2026 年 5 月,Anthropic 表示超过 80% 的合并到其生产代码库的代码由 Claude 编写。在 Claude Code 于 2025 年初推出之前,这个数字只有个位数。
这种影响也体现在生产力上。工程师现在合并的代码量是 2024 年的大约 8 倍。根据论文,这发生在两个明显的跳跃中。第一个是当 Claude 不再仅仅建议代码,而是开始运行它的时候。第二个是当 AI 智能体能够在更长的时期内自主工作的时候。
研究方面讲述了类似的故事。Anthropic 分享了一项约 130 名研究人员的内部调查结果。中位数的回答是,与没有使用 AI 相比,人们认为他们在使用 AI 时的产出大约是原来的四倍。
能力基准也在快速发展。一个基准衡量 AI 系统是否能成功复现已发表研究论文的结果。据报道,成功率从 2024 年的大约 20% 增加到仅十五个月后接近饱和该基准。另一个衡量标准估计 AI 能可靠地独立完成现实任务的时间,根据论文,这个窗口大约每四个月翻倍,从只花几分钟的任务增长到花约十二小时的任务。
这些数字令人印象深刻。让我对它们更有信心的是作者们如何坦诚地讨论他们的局限性。他们反复指出自己测量中的差距。代码行数是一个不完美的生产力指标。调查回答可能会高估实际的生产力收益。基准不总是能捕捉现实工程工作中发生的情况。
这实际上使数据更有说服力。它感觉不像市场营销,更像是一个团队试图解释他们在自己组织内部真实看到的东西。
论文中最重要的部分在所有数字之后。在阅读了它们之后,我发现自己在问一个简单得多的问题。
如果 Claude 在写大多数代码,工程师在做什么?
答案,至少从我读论文的方式来看,是开发者所做的工作并没有消失。它在改变。
Claude 在执行方面变得格外出色。给它一个明确定义的任务、足够的背景和正确的工具,它就能以惊人的速度推进实现。它可以编写代码、运行实验、调试问题、测试不同的方法,并在重复工程工作上的迭代速度远快于一个人。
但软件工程从来都不只是关于写代码。
决定哪些问题值得解决仍然需要人去做。当一个实验在技术上成功但在回答错误的问题时,需要有人识别出这一点。当一个结果看起来正确时,需要有人问一问它在更大系统中是否真的有意义。这些决定远比代码行数或基准测试分数更难量化,但文章表明这些仍然是工程师创造价值的重要部分。
作者们甚至尝试了量化其中一部分。他们查看了真实研究会议的记录,其中人类的某个决定后来被证明是低效的或干脆是错的。然后他们向 Claude 展示了该点之前的所有内容,并询问它接下来会做什么。他们最好的模型从 2025 年底的约 51% 的选择更好下一步,进步到仅仅几个月后的大约 64%。
这是有意义的进展。与此同时,这也意味着该模型在每种情况下都没有选择更好的方向。在更开放性的决策上,仍然存在明显的差距。
文章中的一个对比有助于将其放在透视中。作者描述了随着工程师获得经验,职责如何变化。在职业早期,大部分工作涉及实施已由他人定义的任务。随着经验的增加,人们需要更多地负责决定应该如何处理这些任务,最终还要决定首先应该关注哪些问题。
我不认为这个对比意味着 AI 只是替代初级工程师,而资深工程师毫发无损。软件工程不是那样工作的,AI 也不是。这表明的是,随着实现变得更容易,围绕理解系统、评估权衡、审查工作和做出良好决策的技能变得更加宝贵。
这最终成了我从文章中得到的最大收获。
我认为讨论的真正内容并不是开发者是否会变得不必要。而是随着软件工程的某一部分变得极其快速,工作的平衡如何改变。这比把对话简化为"AI 写了大部分代码"的方式,是一种更有用的思考方式。
作为职业生涯早期的人,我对此的看法
我认识的很多人确实为 AI 担忧。有时这种担忧来自社交媒体,有时来自会议演讲,有时只是因为看到这些工具改进得有多快。当你读到世界上领先的 AI 公司之一的生产代码中超过 80% 现在是由 AI 编写的时,不禁会想知道这对其他人意味着什么。
我也有过这些想法。读这篇文章并没有让这些问题消失,但它改变了我思考这些问题的方式。
对我来说最大的区别是,我停止了关注数字本身。80% 听起来很巨大,直到你开始问这 80% 实际上代表什么。文章让我意识到我一直在按代码被写出来的数量来衡量软件工程,而现实中很多最有价值的工作发生在任何人打开编辑器之前。这个视角的转变使得这篇文章感觉不那么像一个关于替代的故事,而更像是一个关于改变工作流的故事。
我对此想得越多,就越想起我们为什么花那么多时间学习计算机科学基础。当你在学习操作系统、网络、数据库、算法或分布式系统时,很容易想知道你什么时候会用上这些想法。与构建应用或发布功能相比,它们可能感觉很抽象。但这些科目不只是在教授语法或 API。它们教你如何推理系统。它们教你如何思考权衡、理解复杂性、识别瓶颈,以及解释为什么某些东西的行为方式是那样。这些技能在实现变得更容易时变得更宝贵,因为它们是帮助你评估实现是否实际正确的技能。
那是我的视角真正改变的地方。开发者被替代的恐惧往往来自于想象编写代码是整个工作。软件工程从来都不是那样工作的。编写代码很重要,但理解问题、设计系统、审查解决方案、与其他工程师交流,以及在没有明显答案时做出决策也同样重要。
我的职业生涯还很早,我知道经验更丰富的人对此会有不同的看法。那是完全合理的。这只是我在仔细阅读文章而不是对其周围头条新闻做出反应后得出的结论。
这可能的三种发展方向
文章避免了我在很多 AI 讨论中看到的东西。互联网经常谈论 AI,就好像只有两种可能性:要么一夜之间一切都改变,要么什么都没有真的改变。文章采取了更平衡的方法。它列出了几个可能的方向,并坦诚没有人确切地知道我们将走向哪一条。
第一种可能性是,今天的快速进展最终开始放缓。每项技术某处都有极限,无论这些极限来自硬件、能源、数据、研究挑战,还是仅仅是剩余的问题变得极其难以解决。Anthropic 承认了这种可能性,但基于他们目前拥有的证据,他们不认为他们已经看到了这些极限。在他们跟踪的不同能力衡量指标中,曲线仍在同一方向移动。这并不意味着进展永远以相同的速度继续。它只是意味着他们还没有看到有说服力的迹象表明改进正在放缓。
人类留在循环中,但我们的工作方式改变了
这是对我来说感觉最可信的场景,部分原因是它不需要从我们今天已经所在的地方跃出一个戏剧性的飞跃。文章并未争辩开发者突然消失或 AI 在一夜之间接管软件工程。它描述了一个未来,其中 AI 逐渐成为工作流的更大一部分,而人们继续做出需要上下文、经验和责任的决定。
在过去的几年里,AI 已成为许多开发者工作流中的另一个工具。我们用它来解释陌生的代码、编写测试、生成样板代码、调试问题,或帮助我们从不同的角度思考一个问题。这些都没有消除对开发者的需要。如果有的话,它改变了我们花时间的地方。我们之前也见过这种转变。高级编程语言并没有消除程序员,它们只是将工作向上提升了一个层次。AI 处理更多重复性实现工作看起来像同样的转变,而不是不同的转变。
递归自我改进
最后一种可能性是吸引最多注意力的那种。这是一个想法,即 AI 最终变得能够对 AI 研究做出如此多贡献,以至于每一代新的都帮助创建一个甚至更好的,几乎没有人工参与。进展开始更少地依赖人工研究工作,更多地依赖可用的计算、基础设施和资源。
文章认真讨论了这种可能性,但小心不要将其作为不可避免的结果呈现。仍然有很多未知数,作者坦诚地承认他们不知道何时(甚至是否)达到这一点。我认为这种诚实使文章更具可信度。对技术做出大胆预测很容易。更难的是承认不确定性仍然存在的地方。
当我开始阅读《当 AI 构建自己时》时,我认为我在试图回答一个问题。AI 真的在替代开发者吗?
当我到达文章的末尾时,我意识到我实际上已经开始问一个完全不同的问题。随着 AI 成为开发过程本身的一部分,软件工程如何改变?
这些是非常不同的对话。一个主要是由恐惧驱动的。另一个由好奇心驱动。这种视角的转变可能是我从阅读这篇文章中得到的最大的东西。
Anthropic 分享的数字是真实的,很难忽视。他们的生产代码中超过 80% 现在是由 Claude 编写的。工程师的代码发布量比仅仅几年前显著增加了。AI 系统变得能够独立工作更长时间。这一切都不像炒作。
但这篇论文读起来并不像网络上经常讨论的那样。在整篇文章中,作者们反复承认不确定性。他们讨论了自己测量方法的局限性。他们讨论了多个可能的未来,而不是呈现一个不可避免的结果。他们惊人地谨慎地将观察到的内容与他们认为接下来可能发生的事情区分开来。
阅读这篇论文之前,我主要是对标题、短视频和只关注单一统计数据而缺乏背景的帖子做出反应。阅读原始资料并没有消除所有顾虑,但它用对实际变化和仍然非常不确定的内容的更清晰认识,取代了许多模糊的焦虑。
我的职业生涯还很早期,所以我不会假装什么都知道。也许五年后,我会回顾并意识到我低估了 AI 会如何改变软件工程。也许我会意识到我担心得比需要的多。现在,我真的不知道。
我所知道的是,阅读原始资料与阅读其他人对它的解释感觉非常不同。如果用一句话来总结我从这篇论文中获得的内容,那就是:被自动化的东西不是我试图变得更好的技能。
写这篇文章让我放慢速度,思考我自己的很多焦虑来自哪里。对我来说,这不是技术本身。这是不断的头条新闻流告诉我这项技术应该意味着什么,但没有鼓励我去阅读原始资料。
阅读这篇论文后,我觉得我对机会和不确定性都有了更清晰的认识。我仍然对 AI 感到兴奋。我仍然对它的走向保持谨慎。但我不再认为这两种感受必须相互矛盾。
我很想听听你的想法。如果你自己读过这篇论文,你是否得出了相同的结论,或者有什么完全不同的东西给你留下了深刻印象?如果你的职业生涯也处于早期,AI 是否改变了你对成为软件工程师的想法?如果你在这个行业呆了更长时间,我特别想听听你从你的角度如何看待这些变化。
在下方留言。我会读每一条评论,我很想继续这个对话。
Anthropic, When AI Builds Itself
透明度说明:本文的横幅图像是使用 DEV Community 内置的 AI 图像生成功能生成的。我编写了提示,生成了多个变体,并选择了用于本文的最终图像。
某些评论可能仅对已登录的访客可见。登录以查看所有评论。某些评论已被文章作者隐藏 - 了解详情
对于进一步的操作,你可以考虑阻止此人和/或举报滥用