代理式编程是一个陷阱

# 智能体编码是一个陷阱 | Lars Faye 来源: https://larsfaye.com/articles/agentic-coding-is-a-trap > “AI 负责编写代码，而人类在回路中担任编排者” 这是目前行业内被大肆炒作的观点：传统编程已近乎消亡，规范驱动开发（SDD）才是未来。你生成一个计划，然后脱离编写代码的过程。智能体更懂行，能处理所有实现细节。你作为“专家”，提供“良好的品味”，审查输出结果，并不断引导智能体执行你精心制定的计划。 目前的工作流程形态各异，但总体上是一个这样的过程：某人定义项目需求（同时在微观和宏观层面），生成计划，然后反复拉动老虎机拉杆 (https://blog.quent.in/blog/2026/03/09/one-more-prompt-the-dopamine-trap-of-agentic-coding/)，通过多次迭代，甚至使用*多个*智能体实例，直到完成为止。在此过程中，“编排者”与被生成及提交的代码之间的距离越来越远。 编码智能体很有帮助，也很强大，但已经有一些可量化的权衡需要讨论： - 为了缓解 AI 非确定性带来的模糊性增加，周围系统的复杂性也随之增加。 - 广大人群的技能萎缩。 - 个人和整个团队面临供应商锁定（Claude Code 的停机事件已导致整个团队停滞不前）。 - 访问工具的成本波动且不断上升。员工的成本是固定的；代币（tokens）则是一个不断变化的目标。 成功使用这种编码智能体方法取决于一个相当关键的要素：只有具备批判性思维、且习惯于在架构层面操作的熟练开发者，才能在问题出现*之前*，在数千行生成的代码中发现潜在问题。 然而，命运弄人，已被证明受到 AI 工具负面影响（https://margaretstorey.com/blog/2026/02/18/cognitive-debt-revisited/）的，恰恰是个人的批判性思维能力和认知清晰度。 ## 不仅仅是另一种“抽象” (https://larsfaye.com/articles/agentic-coding-is-a-trap#not-just-another-abstraction) 社区中常见的一个说法是，程序员只是在“向上移动堆栈”，进入一种不同类型的抽象。这些工具是否真的首先是一种抽象层，尚未有定论；更高的模糊性并不等同于更高水平的抽象。 不过，即便将这一点搁置一边，程序员确实倾向于对新语言和新编程方式持谨慎态度。当 FORTRAN 发布时，程序员也曾对它持怀疑态度。他们当时有类似的论点：它可能会引入更多的 bug 和不稳定性，直接编写汇编语言更高效。后来，关于编译器集成是否给过程引入了太多“魔法”的讨论也接踵而至。这些都是关于如果拥抱这些新技术，*可能*会失去什么的规范性论证，源于恐惧。 与今天发生的情况不同的是，那些先前的恐惧是推测性和理论性的。在 AI 工具存在的短短几年里，我们已经看到了显著的影响。这不仅仅是*初级开发者*，甚至包括那些拥有十年（或更多）经验的人： 初级开发者面临更陡峭的攀升之路，因为我们截断了他们直接操作代码的能力，取而代之的是审查生成的代码。审查代码固然重要，但在最好的情况下，它最多只占学习过程的 50%。如果没有直接操作代码所带来的摩擦和挑战，他们的学习能力将严重受损。 研究这种现象需要时间，因此收集轶事证据对于实时了解情况非常重要。但这一现象也得到了研究，并有众多 (https://www.media.mit.edu/publications/your-brain-on-chatgpt/)报告 (https://www.404media.co/microsoft-study-finds-ai-makes-human-cognition-atrophied-and-unprepared-3/)证实这确实是一个真实的现象。 ### 这次真的不一样。 (https://larsfaye.com/articles/agentic-coding-is-a-trap#it-actually-is-different-this-time) 当 C++ 开发者转向 Java 或 Python 时，他们没有抱怨头脑昏沉。当系统管理员转向 AWS 时，他们也没有觉得自己失去了理解网络的能力。 高级工程师随着职位转向管理角色并减少编码实践，逐渐失去编码敏锐度变得“生疏”，这并非新现象。这是专业知识发展的自然进程：一位拥有**数十年**编码、摩擦和经验积累的工程师，有时间和精力来巩固这些技能和智慧。当工作变得不那么关注语法，而更关注更高层级的架构决策时，他们可以应用这些智慧。这样的人不仅极其罕见，而且如果我们大家都放弃了编写、解决问题和调试所带来的摩擦，我们将无法迎来下一波高级工程师。 目前发生的情况是一种趋势：那些从未拥有这种长期性、或导致深刻理解所需的 30 多年摩擦的开发者，正被推向需要相同技能来管理 AI 智能体的高层工作流，而这些技能是高级工程师花了几十年才获得的。 然而，高级工程师也无法幸免。Simon Willison (https://simonwillison.net/2026/Feb/15/cognitive-debt/)，一位拥有近 30 年经验的开发者，报告说自己没有*“对应用程序能做什么以及它们如何工作形成坚定的心理模型，这意味着每增加一个功能，推理起来都变得更加困难”* ## “熟练”编排者的问题 (https://larsfaye.com/articles/agentic-coding-is-a-trap#the-skilled-orchestrator-problem) 在 Anthropic 最近的一项研究 (https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic#and-less-hands-on-practice) 中，埋藏着一个令人惊讶的坦诚时刻，谈到定期使用编码智能体的风险时： > 编码技能萎缩令人担忧的一个原因是“监督悖论”……有效使用 Claude 需要监督，而监督 Claude 恰恰需要那些*可能*因过度使用 AI 而萎缩的编码技能。 LinkedIn 软件工程总监 Sandor Nyako (https://www.businessinsider.com/leaders-worry-about-skill-atrophy-due-to-ai-adoption-2025-10#8786254a-3fe1-4407-98a2-7c2eaac66b6f)，负责管理 50 名工程师，已注意到这种情况在整个组织中蔓延，并要求团队不要在*“需要批判性思维或解决问题”*的任务中使用它们。 > “要成长技能，人们需要经历困难。他们需要培养思考问题的肌肉，”他说。“如果一个人没有批判性思维，他如何质疑 AI 的准确性？” 还有一个问题是，什么构成“过度使用”。我们已经有证据，无论是*数据驱动*的 (https://www.anthropic.com/research/AI-assistance-coding-skills) 还是*轶事*的 (https://www.youtube.com/watch?v=pzkwn3hu1Cc)，表明这些技能可能会迅速萎缩和消散（在某些情况下甚至在几个月内）。 这是许多 AI 支持者自相矛盾的地方：使用编码智能体实际上正在削弱有效管理编码智能体所需的技能。 ## LLM 加速了错误的部分。 (https://larsfaye.com/articles/agentic-coding-is-a-trap#llms-accelerate-the-wrong-parts) 与当前宣扬的主流叙事相反，我们并不一定*需要*更快地编写代码。尤其是那些我们不完全理解的代码，特别是一大批我们在合理时间内无法审查的代码。 ### 在 AI 之前，一位（优秀）开发者的优先级列表可能如下： (https://larsfaye.com/articles/agentic-coding-is-a-trap#before-ai-a-good-developers-priority-list-might-look-like) - 理解代码及其与代码库的关系 - 代码是否符合文档记录和高效标准 - 用尽可能少的代码行实现目标（同时保持可读性） - 周转时间 ### 智能体编码，以及一般的 LLM，*完全颠倒了这个列表*。 (https://larsfaye.com/articles/agentic-coding-is-a-trap#agentic-coding-and-llms-in-general-completely-invert-this-list) 它们的功能和使用往往侧重于通过增加在指定时间内可以生成的代码量来提高速度。速度是高能力自然产生的副产品。当速度被强制要求时，它总是导致准确性降低。这些工具的集成往往不太关注深入的理解或简洁性。 它们可以这样使用吗？是的，只要下定决心，当然可以。 它们是这样吗？不，并不是；强制性的规定和对组织内代币使用的*炒作 (https://www.pymnts.com/artificial-intelligence-2/2026/ai-adoption-is-being-measured-in-tokens-but-the-metric-falls-short-experts-say/)* 证明了这一点。 ## 编码 === 规划 (https://larsfaye.com/articles/agentic-coding-is-a-trap#coding-planning) 开发者之间存在一个未被充分强调的分歧：*我们中的一些人通过代码进行更好地规划和思考*。在代码中思考和操作不仅仅是无意义的苦差事；它迫使你在技术层面上思考问题，涉及从安全、性能、用户体验到可维护性的各个方面。 在最近一次讨论“规范驱动开发”的*采访 (https://youtu.be/IGsbARhERqc?t=501)* 中，OpenCode 的创建者 Dax *（别忘了，这是一个开源编码智能体）* 被引用说： > “当处理新事物或具有挑战性的事物时，我敲代码的过程是我弄清楚我们到底应该做什么的过程。我很难只是坐在那里，写出一个巨大的规范，详细说明功能应该如何工作。我喜欢写出类型。我喜欢写出一些函数如何协同工作。我喜欢玩弄文件夹结构，看看不同的概念应该是什么。我认为大多数人——大多数程序员——一直以来都是这样做的。我个人真的看不到停止这样做的理由，因为这就是我弄清楚该做什么的方式。” 你*说*的往往不是你*想*表达的，LLM 会用假设（或幻觉）来填补模糊性，这导致：**更多**审查，**更多**智能体修订，**更多**代币消耗，以及**更多**与被创建内容的脱节。反之，你可以为你写过的最美丽、无歧义、结构完美的提示词惊叹，LLM 仍然可能输出一个幻觉方法，因为它从根本上来说是一个下一个代币预测引擎，而不是编译器。你不能用一个概率系统取代一个确定性系统，并期望零模糊性。 即使是*最*热衷于 AI 的高级开发者 (https://www.youtube.com/watch?v=cv6rwHTGT5w) 也开始将这种脱节视为一个迫在眉睫且日益严重的问题。 ## “供应商锁定” (https://larsfaye.com/articles/agentic-coding-is-a-trap#vendor-lock-in) 当我在不久前发生的 Claude 停机期间浏览 LinkedIn 时，我注意到许多帖子 (https://www.linkedin.com/pulse/claudes-outages-show-dark-side-ai-productivity-total-system-lam-osbjc/) 强调某些开发者和工程团队陷入了停滞。他们的工作流程，他们自己的编码能力，*已经*达到很大程度上依赖这些供应商的地步。过去只需要键盘和文本编辑器就能执行的一项技能，突然需要订阅 AI 模型提供商的服务。 向前推演这种模式并非不合理，我们可能会创造一个行业，在那里你*需要*为代币消耗付费，才能完成过去依靠自己批判性思维和解决问题能力就能完成的事情。这将类似于一种“供应商锁定”，但是针对整个行业的技能集（我相信模型提供商们正*欣喜地搓手 (https://giphy.com/gifs/giphyqa-g0JP0HG6zF0o8)* 期待这一刻）。财务上和智力上的“撤梯子”随时可能发生，而本地 LLM 远未准备好扩展以吸收这种级别的使用量。因此，虽然我*并非特指特定模型提供商的供应商*，但这一术语仍然与我们看到的过度依赖这些系统的现象间接相关。 这并非理论推测；*它正在被报道 (https://www.youtube.com/watch?v=5HaQnIPrfKk)*。甚至模型提供商 themselves 也在揭露这一点。另一项 Anthropic 研究 (https://www.anthropic.com/research/AI-assistance-coding-skills) 显示调试技能出现了急剧的**47% 下降**： > “在工作场所——尤其是在软件工程领域——激进地引入 AI 必然伴随着权衡……开发者可能会依赖 AI 来快速交付结果，以牺牲建立关键技能为代价——最显著的是，在事情出错时调试的能力。” ### 你无法预测你的代币成本。 (https://larsfaye.com/articles/agentic-coding-is-a-trap#you-cant-predict-your-token-cost) 模型提供商得到了*大量补贴 (https://www.theverge.com/ai-artificial-intelligence/917380/ai-monetization-anthropic-openai-token-economics-revenue)*，模型本身建立在流沙之上。每个新模型的发布都遵循相同的模式：高基准，随后是炒作，随后是使用现实，所有人都抱怨它们被“削弱”了，并且消耗 2-3 倍的代币来完成同样的工作。 你*知道*你的员工成本是多少；你*完全不知道*你的代币成本每天、每月、每年会是多少。如果你的整个团队默认使用智能体编码，你的费用账户将需要保持高度灵活。正如 Primeagen 最近所说：*“当你使用这些完全智能体的工作流时，模型提供商本质上拥有了你”。 (https://www.youtube.com/watch?v=_vB0PDzaa7I&t=3299s)* 当然，有一种方法可以避免所有这些。LLM 是一项强大的技术进步，当负责任地使用它们时，它们可以成为学习和提升技能的绝佳工具。它们使我能够更深入和广泛地探索概念和技术，扩展理解能力，并探索那些过去实验起来更费力且耗时更多的新想法。我认为，这才是它们将为行业带来最长期价值的地方。 ## 我的方法：降低 AI 的角色 (https://larsfaye.com/articles/agentic-coding-is-a-trap#my-approach-demote-ais-role) 我当然不提倡手动敲代码。程序员一直在寻找*创建*代码而无需*编写*代码的方法。这就是为什么我们首先有 Emmet (https://code.visualstudio.com/docs/languages/emmet)、自动补全和代码片段。甚至 COBOL 的设计也是通过使用诸如 `MOVE` 和 `WRITE` 等“类英语”单词，用更少的书写来封装更多的指令。jQuery 的座右铭是“写更少，做更多” (https://brand.jquery.org/logos/)。LLM 只是这一系列代码生成工具中的又一成员。 不过，我所倡导的是将 LLM 和编码智能体作为辅助过程利用。一种不会为了生产力而在祭坛上牺牲个人技能的方式。你可以扭转局面，依靠它们来构思过程的规划部分，同时在实现过程中保持积极参与，按需委托给它们。你可以利用生产力的提升，并减轻理解债务。 ### 我的日常工作流： (https://larsfaye.com/articles/agentic