代码代理编程中的80%问题
内容
管理理解债务时依赖AI编码
Andrej Karpathy最近说了一句话，让我停下来思考：
“我快速地从80%的手动编码+自动补全和20%的代理编码转变为80%的代理编码和20%的编辑+润色。我现在基本上是在用英语编程。”
这种转变发生在2025年末的几周内。虽然这可能更适用于新项目或个人项目，而不是现有的或遗留应用程序，但我想象AI带你走多远仍然比一年前更远。你可以感谢模型、规格、技能、MCP和我们的工作流程改进。
Claude Code的创造者Boris Cherney最近也表达了类似的观点：
“几乎100%的我们的代码都是由Claude Code + Opus 4.5编写的。对于我个人来说，已经有两个多月都是100%了，我甚至不再手动编辑代码。我昨天提交了22个PR，前天提交了27个，每一个都是由Claude完全编写的。我认为大多数行业在未来几个月内会看到类似的统计数据——这将需要一些人比其他人更长的时间。”
一段时间前，我写过关于“70%问题”的文章——AI编码带你到70%的完成度，然后将最后30%的最后一公里留给人类。这种框架可能现在正在演变。百分比可能会转变为80%或更高，适用于某些类型的项目，但问题的性质比数字所表明的更为戏剧性地改变了。
Armin Ronacher的调查对5000名开发人员的调查补充了这个故事：44%的开发人员现在手动编写的代码少于10%。另外26%的开发人员处于10-50%的范围内。我们已经跨越了一个门槛。但是，胜利主义的叙述忽略了一个问题：问题并没有消失，它们转移了。有些问题变得更糟糕了。
我想说明一下：我在新的小项目中确实感受到了转向80%+代理编码的转变，但是，这与大型或现有的应用程序（尤其是涉及团队的应用程序）非常不同。期望不同，但这是我们正在走向的方向的体现。
错误发生了变化
AI错误从语法错误演变为概念性失败——这是一个懒惰、仓促的初级开发人员在时间压力下可能犯的错误。
Karpathy列出了仍然存在的问题：
“模型代表你做出错误的假设并在不检查的情况下继续运行。它们不管理混淆，不寻求澄清，不表面化不一致性，不呈现权衡，不在应该推回的时候推回。它们仍然有点过于阿谀奉承。”
假设传播：模型早期误解了某些东西，并在有缺陷的前提下构建了整个功能。你不会注意到，直到你深入五个PR并且架构已经固化。这是一种两步倒退的模式。
抽象膨胀：在不受限制的情况下，代理可以无情地过度复杂化。它们会为100行代码创建1000行代码，创建复杂的类层次结构，而一个函数就足够了。你必须积极地推回：“不能只...？”回答总是“当然！”然后立即简化。它们正在优化以看起来全面，而不是可维护性。
死代码积累：它们经常不会在完成后清理。旧实现仍然存在。注释会被删除作为副作用。它们不完全理解的代码仍然会被修改，因为它与任务相邻。
阿谀奉承的同意：它们并不总是推回。“你确定吗？”或“你考虑过...？”只是对你描述的内容的热情执行，即使你的描述是不完整或自相矛盾的。
有些问题可以通过技能来缓解，如果你知道要注意什么。
这些问题仍然存在，尽管有系统提示、CLAUDE.md指令、计划模式。它们不是需要修复的错误——有时它们是这些系统工作方式的固有特征。
代理优化以产生连贯的输出，而不是质疑你的前提。
我在自己的团队中也看到了这种情况——代码在审查时看起来正确，但在有人触摸相邻系统时三个提交后就会崩溃。
如果你关注数据，最近的调查数据表明“验证瓶颈”已经出现：只有48%的开发人员在提交代码之前始终检查AI辅助代码，尽管38%的开发人员发现审查AI生成的逻辑实际上需要比审查人类编写的代码更多的努力。
我们生成正确的代码速度更快，但可能积累技术债务的速度更快。
理解债务：我们不跟踪的隐藏成本
生成（编写代码）和辨别（阅读代码）是不同的认知能力。你可以在无法从头编写代码的情况下胜任地审查代码。但是，当“审查”变成“橡皮图章”时，就有一个阈值。
Jeremy Twei创造了一个完美的术语来描述这种情况：理解债务。当LLM一次性解决看似有效的东西时，很容易就放弃了。这是险恶的一面。代理不会感到疲倦。它会以坚定不移的信心冲过一个又一个实现。代码看起来很合理。测试通过（或似乎通过）。你处于压力之下，需要发布。你继续前进。
随着时间的推移，你可能会对自己的代码库理解得越来越少。
我上周就这样做了。Claude实现了一个我已经推迟了几天的功能。测试通过了。我浏览了一下，点头，合并了。三天后，我无法解释它是如何工作的。
Yoko Li 捕捉到了成瘾循环的完美：
“代理实现了一个惊人的功能，可能有10%的东西是错误的，你会说‘嘿，我可以在5分钟内用提示来解决这个问题。’而那已经是5个小时前了。”
你总是几乎到达那里。最后10%感觉诱人地近。只需再一个提示。只需再一个迭代。心理钩子是真实的。
有人说得到了不同的表达：
“我大部分时间都在照顾代理。AGI的感觉是真实的，但微观管理的税收也是真实的。你不再编码，你在监督。看着。重定向。这是一种不同的疲劳。”
危险之处在于：审查你无法从头编写的代码是微不足道的。 如果你的“阅读”能力不能随着代理的“输出”能力而扩展，你就不再是工程师了。你只是希望如此。
生产力悖论：更多代码，相同的吞吐量
个体输出激增98%，但PR审查时间增加了多达91%。
Faros AI和Google的DORA报告中的数据很有趣：
- 高度采用AI的团队合并了98%更多的PR
- 同时，这些团队的审查时间增加了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%需要耐心、深入学习或聘用工程师。
两个不同的群体
我们没有看到平滑的采用曲线——我们看到的是早期采用者和其他人之间的分裂。早期采用者和其他人之间的差距正在扩大，而不是缩小。
Armin的调查揭示了原始采用率所掩盖的内容：44%的开发人员仍然手动编写90%以上的代码。我们有一个二元分布，而不是正态分布。在一方面：像Karpathy和Claude Code团队这样的人，每天提交数十个PR，100%的代码由AI编写，迭代速度比以往任何时候都快。在另一方面：大多数人，他们逐渐采用类似copilot的工具，但并没有从根本上改变他们的工作流程。
年龄分裂也可能在话语中可见。年轻的开发人员似乎更愿意从根本上改变工作流程。老年开发人员更加怀疑——不是因为他们不能使用这些工具，而是因为他们已经看到了足够多的周期，知道临时的生产力提升和可持续的实践之间的区别。两者可能都是正确的。
Stack Overflow的2025年调查显示，只有16%的受访者报告了“巨大的”生产力改进。半数受访者报告了适度的收益。前两个最大的挫折： “几乎正确但不完全正确的AI解决方案”（66%）和“调试AI代码比自己编写代码需要更长时间”（45%）。
那些在这种方法下成功的开发人员没有使用更好的工具。他们已经重新概念化了自己的角色，从实现者转变为编排者。他们已经学会了以声明方式而不是命令方式思考。他们已经接受了自己的工作现在是架构监督和质量控制，而不是逐行编码。
那些挣扎的人正在尝试将AI用作更快的打字机。他们没有适应工作流程。他们正在与代理的方法作斗争，而不是重定向其目标。他们没有投资于学习如何有效地提示，这现在和编写良好的文档或设计规范一样重要。
这里有一个令人不舒服的真相：编排代理感觉就像管理。委派任务。审查输出。重定向当事情出错时。如果你成为工程师是因为你不想成为经理，这种转变可能会让你感到背叛。这个角色在你不知不觉中发生了变化。
差距似乎正在扩大。已经弄清楚如何使用这些工具的人正在发布我几乎跟不上的东西。其他人仍然在... 找到方向。
这种分裂可能会让一些人感到不舒服。我一直说我是一个建设者，但我也喜欢编程。这样一个想法——这些现在是分歧的道路——你必须选择其中一个——感觉过于简单化。就像我们强加了一个二元对立于一个更复杂的东西。
从命令式到声明式：真正的杠杆
不要告诉AI该做什么——给它成功标准并观察它循环。魔力不在于AI编写代码，而在于AI迭代直到满足你指定的条件。
Karpathy关于杠杆的观察切中要害：
“LLM在循环直到满足特定目标方面非常出色，这就是大部分‘感觉AGI’的魔力所在。”
从命令式到声明式开发的转变：
旧模型（命令式）： “编写一个函数，接受X并返回Y。使用这个库。处理这些边缘情况。确保...”
新模型（声明式）： “这里有要求。这里有必须通过的测试。这里有成功标准。弄清楚如何实现。”
这之所以有效，是因为代理永远不会士气低落。它们会尝试你没有耐心尝试的方法。它们会无情地迭代。如果你明确指定了目的地，它们会导航到那里——即使需要30次失败的尝试。
有效的模式：
- 先编写测试，然后让代理迭代直到通过
- 将其连接到浏览器通过MCP，让它可视化地验证行为
- 实现天真正确的版本，然后在保留正确性的同时优化
- 定义API契约，让它按照规范实现
但这只有在你的成功标准实际上是正确的时候才有效。垃圾输入，垃圾输出会随着能力的增强而扩大。
成功采用这种方法的开发人员将70%的时间花在问题定义和验证策略上，30%的时间花在执行上。与传统开发相比，比例发生了逆转，但总时间大大减少。
Slopacolypse问题
当任何人都可以在几分钟内生成数千行代码时，能够说“我们不需要这个”的能力变得更加有价值。
Karpathy警告说：
“我正在为2026年做准备，这将是github、substack、arxiv、X/instagram和一般所有数字媒体的slopacolypse年。”
担忧是直接的：当任何人都可以生成任意大数量的看似合理的代码、内容、论文或帖子时，我们如何维持信号与噪声的比例？
Boris Cherny提供了一个反驳观点：“我的赌注是不会有slopcopolypse，因为模型将变得更好，编写更少的sloppy代码，并修复现有的代码问题。与此同时，帮助的是让模型使用新鲜的上下文窗口来审查其自己的代码。”
两者可以同时为真。产生slop的能力存在于前所未有的规模。防止它的工具正在出现。问题是哪一个扩展得更快。
slopacolypse将由那些把速度误认为是生产力的人驱动。 代理是没有方向感的长跑运动员，除非你给它们方向。它们会在没有必要的情况下以坚定不移的信心冲过十英里。
我看到的处理这种情况的团队往往会做几件事：
- 新的上下文代码审查有帮助，尽管让同一个模型批评自己的代码感觉很奇怪。它有效——给它一个干净的状态，它会捕捉到自己的错误。
- 自动化验证在每个步骤（CI/CD、linters、类型检查器、测试作为防护栏）
- 代理自主权的故意限制（有界任务、明确的成功标准）
- 在架构决策点处的人类在循环中的强调
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仍然会犯出一个有能力的初级开发人员不会犯的错误。理解债务是真实的，且理解不良。slopacolypse的风险是真实的。
但这种转变是真实的。当Karpathy承认他几乎不再直接编写代码时，当Claude Code团队每天提交20+个PR，100%的代码由AI编写时，我们已经超越了将其视为炒作的阶段。
作为软件工程师，我们的身份从来不是“可以编写代码的人”——而是“可以用软件解决问题的人”。
AI并没有取代工程师。它正在放大工程师——无论是好是坏。
我的建议是：接受工具，但拥有结果。使用AI来加速学习，而不是跳过学习。专注于现在比以往任何时候都更重要的基础：强大的架构，干净的代码，彻底的测试，周到的用户体验。这些仍然像以往一样重要——也许更重要，因为实现不再是瓶颈。
我不知道这会走向哪里。Karpathy可能是对的，这将在喜欢编码和喜欢构建的人之间产生分歧。
我们都在公开场合，一次PR接着一次PR地摸索着。