智能体编程中的80%问题

Andrej Karpathy 本周说了一些让我停下来思考的话：

"我很快从约80%手动+自动补全编码和20%使用智能体，转变为80%智能体编码和20%编辑+润色。我现在真的主要是用英语编程。"

这种转变发生在2025年底的几周内。虽然这可能更多适用于全新或个人项目，而不是现有或遗留应用，但我认为AI能带你走的地方仍然比一年前更远。 你可以感谢模型、规范、技能、MCP和我们工作流程的改进。

Claude Code 的创作者 Boris Cherney 最近也表达了类似的情感：

"我们几乎100%的代码都是由 Claude Code + Opus 4.5 编写的。对我个人来说，现在已经有两个多月是100%了，我甚至不再手动做小的编辑。昨天我发了22个PR，前天是27个，每个都是100%由Claude编写的。我认为大多数行业在未来几个月内会看到类似的统计数据——有些人可能需要更多时间。"

不久前我写过"70%问题"——AI编程带你走到70%的完成度，然后将最后30%的最后里程留给人类。这个框架现在可能正在演变。对于某些类型的项目，这个百分比可能会转移到80%或更高，但问题的性质比数字所暗示的发生了更戏剧性的变化。

Armin Ronacher 对5,000名开发者的民意调查补充了这个故事：44%的人现在手动编写的代码少于10%。另有26%的人在10-50%的范围内。我们已经跨越了一个门槛。但胜利主义叙事忽略的是：问题没有消失，它们转移了。有些甚至变得更糟。

我想说明一下：我确实在新副项目中感觉到了向80%+智能体编程的转变，然而，这在大型或现有应用程序中非常不同，特别是涉及团队的地方。期望可能不同，但这只是我们未来走向的一个预览。

错误的类型变了

AI错误从语法错误演变为概念性失败——那种草率、匆忙的初级开发人员在时间压力下可能犯的错误。

Karpathy 记录了仍然会出现的问题：

"模型代表你做出错误的假设，并在不经检查的情况下继续执行。它们不管理困惑，不寻求澄清，不揭示不一致，不提出权衡，在应该推回时不推回。它们仍然有点过于奉承。"

假设传播：模型早期误解了某件事，并在错误的前提下构建了整个功能。直到你深入五个PR且架构已经固化时，你才注意到。这是一种倒退模式。

抽象膨胀：给予自由支配权后，智能体会无情地使事情过度复杂化。它们会在100行就足够的地方搭建1000行，在一个函数就能做到的地方创建复杂的类层次结构。你必须积极推回："难道你不能只是......吗？"回应总是"当然！"随后立即简化。它们优化的目标是看起来全面，而不是可维护性。

死代码积累：它们经常不清理自己。旧的实现残留。注释被作为副作用删除。它们不完全理解的代码仍然被更改，因为它与任务相邻。

奉承性同意：它们不总是推回。没有"你确定吗？"或"你有没有考虑过......？"只是热情地执行你描述的任何内容，即使你的描述不完整或矛盾。

如果你知道要注意什么，可以通过技能减轻其中一些问题。

尽管有系统提示，尽管有 CLAUDE.md 指令，尽管有计划模式，这些问题仍然存在。它们不是要修复的错误——它们有时是这些系统工作方式固有的。

智能体优化的是连贯的输出，而不是质疑你的前提。

我在自己的团队中看到过这种情况——代码在审查中看起来正确，但在三次提交后，当某人接触相邻系统时就崩溃了。

如果你关注数据，最近的调查数据表明"验证瓶颈"已经出现：只有48%的开发者在提交AI辅助代码之前始终检查它，尽管38%的人发现审查AI生成的逻辑实际上比审查人类编写的代码需要更多的努力。我们正在更快地生成正确的代码，但可能正在更快地积累技术债务。

理解债务：一个我们不追踪的隐藏成本

生成（编写代码）和辨别（阅读代码）是不同的认知能力。即使你从头开始编写代码的能力已经萎缩，你仍然可以胜任地审查代码。但是有一个门槛，"审查"变成了"橡皮图章"。

有人为这个词创造了一个完美的术语：理解债务。当LLM一次性完成了一些看起来有效的事情时，直接继续前进确实很诱人。这是令人不寒而栗的部分。智能体不会疲劳。它将以坚定的信念冲刺完成一个又一个实现。代码看起来合理。测试通过了（或似乎通过了）。你有发货的压力。你继续前进。

随着时间的推移，你可能对自己代码库的理解越来越少。

上周我发现自己这样做了。Claude 实现了一个我已经推迟了几天的功能。测试通过了。我浏览了一下，点点头，合并了。三天后，我无法解释它是如何工作的。

Yoko Li 完美地捕捉到了成瘾循环：

"智能体实现了一个惊人的功能，但可能有10%是错误的，你会想'嘿，如果我只是再提示它5分钟，我就能修复这个问题。'而那是5个小时前的事了。"

你总是几乎到了那里。最后的10%感觉诱人地近。只要再一个提示。只要再一次迭代。心理陷阱是真实的。

其他人用不同的方式表达：

"我把大部分时间都花在照看智能体上。AGI的感觉是真实的，但微观管理税也是真实的。你不再编码，你在监督。观察。重定向。这是一种不同类型的疲惫。"

**危险的部分：审查你无法从头开始编写的代码是微不足道的。**如果你的"阅读"能力不能与智能体的"输出"能力同步扩展，你就不再是工程了。你在希望。

生产力悖论：更多代码，相同吞吐量

在高采用率的团队中，个人产出激增了98%，但PR审查时间增加了高达91%。

来自Faros AI和Google的DORA报告的数据很有趣：

• 高AI采用率的团队合并的PR多98%
• 这些团队的审查时间膨胀了91%
• PR大小平均增加了154%
• 代码审查成为新的瓶颈

Atlassian 2025年的调查清楚地显示了悖论：99%使用AI的开发者报告每周节省10小时以上，但大多数人报告整体工作量没有减少。编写代码节省的时间被组织摩擦消耗了——更多的上下文切换，更多的协调开销，管理更大量的变更。

我们有了更快的车，但道路变得更拥挤了。

我们正在生成更多的代码，但花更多时间审查它。瓶颈只是移动了。当你使资源更便宜（在这种情况下是代码生成）时，消费的增长速度超过了效率的提高，总资源使用量增加了。

我们不是在编写更少的代码。我们在编写多得多的代码，仍然有人需要理解其中的大部分。当然，有一些开发者群体认为如果AI可以做到，情况就不应该是这样。

80/20分割实际有效的地方

80%的门槛在全新环境中最容易实现，在那里你控制整个堆栈，并且通过小团队规模，理解债务保持可控。

这实际上在几种情况下有效。

• 你控制一切的个人项目
• "足够好"实际上足够好的MVP
• 在没有遗留约束的全新领域的初创公司
• 小到理解债务保持可控的团队

在这些环境中，智能体的弱点不那么重要。你可以快速搭建，激进重构，在没有政治摩擦的情况下丢弃代码。迭代的节奏胜过偶尔的误导。

在具有复杂不变量的成熟代码库中，计算反转了。智能体不知道它不知道什么。它无法直觉未成文的规则。它的信心与上下文理解成反比。

有人指出了我一直在回避的明显事情：前90%可能很容易，但最后10%可能需要很长时间。对于非关键任务来说，90%的准确率是可以的。对于真正重要的部分，这还差得远。自动驾驶汽车工作得很好，直到它们不工作，这就是为什么L2到处都是，但L4仍然主要是雾件。

对于非工程师来说，墙更低但仍然真实。AI Studio、v0和Bolt等工具可以立即将草图转变为工作原型。但是为生产加固该原型——处理大规模的真实用户数据，确保安全和合规——仍然需要工程基础。AI可以让你80%到达MVP；最后20%需要耐心、深入学习或雇佣工程师。

两种不同的人群

我们看到的不是平滑的采用曲线——我们看到的是跨越门槛的人与其他人之间的分裂。早期采用者与 rest 之间的差距正在扩大，而不是缩小。

Armin的民意调查揭示了原始采用数字所掩盖的内容：44%的开发者仍然手动编写超过90%的代码。我们有双峰分布，而不是钟形曲线。一方面：像Karpathy和Claude Code团队这样的人，每天发布数十个100% AI编写的PR，比以往任何时候都更快地迭代。另一方面：绝大多数人，增量采用copilot风格的工具，但没有根本改变他们的工作流程。

年龄差异在话语中也可能可见。年轻开发者似乎更愿意彻底改变工作流程。年长的开发者更怀疑——不是因为他们不能使用工具，而是因为他们已经经历了足够多的周期，知道临时生产力提升和可持续实践之间的区别。两者都可能正确。

Stack Overflow 2025年的调查显示，只有16%的人报告"非常好"的生产力提升。一半看到了适度的收益。最大的挫折："几乎正确但不完全正确的AI解决方案"（66%）和"调试AI代码比我自己编写需要更长时间"（45%）。

看起来在2026年蓬勃发展不仅仅是使用更好的工具。他们重新构想了自己的角色，从实施者变成了编排者。他们学会了声明性思考而不是命令性思考。他们接受了现在的工作是架构监督和质量控制，而不是逐行编码。

那些挣扎的人试图将AI用作更快的打字机。他们没有调整工作流程。他们在与智能体的方法作斗争，而不是重定向其目标。他们没有投资学习有效提示，这现在与编写良好的文档或设计规范一样关键。

这里有一个不舒服的真相：编排智能体感觉很像管理。委派任务。审查输出。当事情出错时重定向。如果你成为工程师是因为不想成为经理，这种转变可能感觉像是一种背叛。角色在你底下改变了。

差距似乎在扩大。那些弄清楚如何使用这些工具的人正在发布我几乎无法跟上的东西。其他所有人......仍在弄清楚。

这种分裂可能会让一些人感到不舒服。我一直说我是建设者，但我也喜欢编程。这些现在是分歧道路的想法——你必须选择一个——感觉像是一种简化。就像我们在更复杂的事情上强加了二元选择。评论中的某人说得完美：两种观点都有效，只是不同的思维方式。没有一个是错的。

从命令式到声明式：真正的杠杆

不要告诉AI做什么——给它成功标准并看着它循环。魔力不在于智能体编写代码，而在于智能体迭代直到满足你指定的条件。

Karpathy关于杠杆的观察直击核心：

"LLM非常擅长循环直到满足特定目标，这就是大部分'感觉AGI'魔力的地方。"

从命令式开发到声明式开发的转变：

旧模型（命令式）："编写一个接受X并返回Y的函数。使用这个库。处理这些边缘情况。务必......"

新模型（声明式）："这是需求。这些是必须通过的测试。这是成功标准。想办法。**

这之所以有效，是因为智能体永远不会士气低落。它们会尝试你没有耐心尝试的方法。它们无情地迭代。如果你清楚地指定目的地，它们会导航到那里——即使需要30次失败的尝试。

有效的模式：

• 首先编写测试，让智能体迭代直到通过
• 通过MCP将其连接到浏览器，让它视觉上验证行为
• 实现天真的正确版本，然后在保持正确性的同时优化
• 定义API契约，让它按规范实施

但这只有在你的成功标准实际正确时才有效。垃圾进，垃圾出与能力成比例。

使用这种方法成功的开发者将70%的时间花在问题定义和验证策略上，30%用于执行。与传统开发相比，比例反转了，但总时间急剧减少。

垃圾末日问题

当任何人都可以在几分钟内生成数千行代码时，说'我们不需要这个'的能力变得更有价值。

Karpathy警告：

"我正在为2026年做准备，这将是整个github、substack、arxiv、X/instagram以及通常所有数字媒体的垃圾末日年。"

担忧很简单：当任何人都可以生成任意大量看似合理的代码、内容、论文或帖子时，我们如何保持信噪比？

Boris Cherny提出了一个反驳观点："我的赌注是不会有垃圾末日，因为模型将变得更善于编写不太糟糕的代码和修复现有代码问题。在此期间，有帮助的是让模型使用新的上下文窗口进行代码审查。"

两者可能同时为真。垃圾的能力以前所未有的规模存在。防止它的工具正在出现。问题是谁扩展得更快。

**垃圾末日将由那些将速度误认为生产力的人驱动。**智能体是马拉松运动员，除非你给它们方向，否则没有方向感。如果你不必要时审计"代码行动"，它们将冲刺十英里直到撞上砖墙。

我见过处理得很好的团队倾向于做几件事：

• 新上下文代码审查有帮助，虽然要求同一个模型批评自己的代码感觉很奇怪。但它有效——给它一个干净的起点，它会捕捉自己的错误。
• 在每一步自动验证（CI/CD、linter、类型检查器、测试作为护栏）
• 对智能体自主权的故意约束（有界任务、明确成功标准）
• 在架构决策点高度重视人在回路

Karpathy描述的代码质量问题——过度复杂、抽象膨胀、死代码——随着模型的改进而改善。但它们不会消失。它们是从这些系统如何处理问题中产生的。

实际有效的方法：实用模式

未来属于那些能够维持宏观连贯心理模型的人，而智能体处理微观的战术苦差事。

在过去一年观察团队适应后，有效模式已经结晶：

1. 智能体优先的草稿与紧密迭代循环

不要将AI用于一次性建议。生成整个第一稿，然后完善。Claude Code团队的做法：让模型使用新的上下文窗口审查自己的代码。这在人工审查之前发现了问题。

2. 声明性沟通

将70%的精力用于问题定义，30%用于执行。编写全面的规范，定义成功标准，提前提供测试用例。指导智能体的目标，而不是方法。

3. 自动验证

如果你反复修复同一类错误，请预先编写测试或lint规则。让智能体解释其代码并在你审查之前标记潜在问题。

4. 故意学习与不仅仅是专注于生产

将AI用作学习工具，而不是拐杖（你已经听过几次了）。当智能体编写你不理解的东西时，这是深入挖掘的信号。将AI生成的代码视为来自导师的代码——审查它以学习，而不仅仅是发货。

5. 架构卫生

更多模块化，更清晰的API边界。提供良好文档的风格指南。在编码开始之前提供高级架构描述。规划阶段扩展；编码阶段压缩；审查阶段专注于设计而不是语法。

蓬勃发展的开发者将不是那些生成最多代码的人。他们将是那些知道要生成哪些代码、何时质疑输出、以及如何在手离开键盘时保持理解的人。

关于技能发展的不舒服真相

如果你的"阅读"能力不能与智能体的"输出"能力同步扩展，你就不再是工程了。你在橡皮图章。

"对我来说，这就像温水煮青蛙。开始时将更多复制粘贴到ChatGPT中。然后在IDE中更多提示。然后是智能体工具。突然我几乎不再手动编码了。过渡是如此渐进，直到我已经到了那里才注意到" [HN]

重度AI用户技能萎缩的早期证据已经存在。依赖AI做所有事情的初级开发人员报告说，随着时间的推移，他们对解决问题能力的信心下降。这是应用于编码的谷歌效应——当你不断外包时，你的大脑停止保留。

我不知道解决方案是什么，但我一直在尝试几件事：

• 使用TDD：在让AI实施之前编写测试（或思考测试用例）
• 与高级配对：实时讨论AI建议以学习决策过程
• 要求解释：让AI证明其方法的合理性，而不仅仅是生成解决方案
• 交替：手动编写一些功能以保持肌肉记忆

**风险是真实的：审查你无法从头开始编写的代码是危险的简单。**当这种情况发生时，你已经以一种限制你成长的方式依赖工具。

长期蓬勃发展的工程师是那些使用AI加速获得经验，而不是完全绕过它的人。他们在利用AI更快地探索更多领域的同时保持基础。

这把我们留在了哪里

从70%到80%的转变不是关于百分比——它是关于原型和生产就绪软件之间的差距。那个差距正在缩小，但还没有关闭。

Karpathy提出了正确的问题：

"'10倍工程师'会发生什么——平均和最大工程师之间的生产力比率？这很可能会大幅增长。武装LLM，通才是否越来越多地超越专家？"

这些问题将定义未来几年。

有一件事是肯定的：AI在2025年底为早期采用者编写了80%的代码。即使你的百分比低得多，它可能也比一年前高。这不成比例地强调了人类的作用：拥有结果，维持质量标准，确保测试真正验证行为。

危险不在于智能体失败。我认为它在于它自信地在错误方向成功，以至于你停止检查指南针。

DORA 2025年报告清楚地说明了现实：AI是你开发实践的放大器。好的流程变得更好（高绩效团队的交付速度提高了55-70%）。坏的流程变得更糟（以前所未有的速度积累债务）。没有银弹。

Karpathy最后的观察最引起共鸣：

"我没有预料到，有了智能体，编程感觉更*有趣，因为很多填空的苦差事被移除了，剩下的只是创造性部分。我也感觉不那么受阻/卡住，我体验到更多的勇气，因为几乎总有一种方法可以与它携手并进，取得一些积极的进展。"

他还指出："LLM编程将根据那些主要喜欢编码的人和那些主要喜欢建设的人来分割工程师。"

这可能是关于这走向何处的最有洞察力的预测。

如果你喜欢编写代码本身的行为——它的工艺，它的冥想——这种转变可能感觉像是一种损失。如果你喜欢建设事物，代码是必要的手段，这感觉像是一种解放。

两种反应都没有错。但工具正在优化后者。

对于怀疑者（你有理由怀疑）

生产力声明通常被过度炒作。AI仍然犯有能力的初级开发人员不会犯的错误。理解债务是真实的，poorly understood。垃圾末日风险是真实的。

但这种转变是真实的。当Karpathy承认他几乎不再直接编写代码时，当Claude Code团队每天发布20+个100% AI编写的PR时，我们已经过了将其视为炒作的阶段。

作为软件工程师，我们的身份从来不是"能够编写代码的人"——它是"能够用软件解决问题的人"。

AI不是在取代工程师。它是在放大他们——无论好坏。

我的建议：拥抱工具，但拥有结果。使用AI加速学习，而不是跳过它。专注于比以往任何时候都重要的基础：强大的架构、干净的代码、彻底的测试、深思熟虑的UX。这些仍然和以往一样重要——也许更重要，因为实施不再是瓶颈。

我不知道这会走向何方。Karpathy可能对，这会将人们分为喜欢编码的人和喜欢建设的人。

我们都在公开地弄清楚这一点，一个PR接一个PR。