开发者称AI编码代理让人放弃决策，直觉随之退化

如今，coding agent 往往遵循同一套默认工作流。你给它们一个problem statement，它们返回一个围绕特定方案构建的计划。你在这个计划上反复迭代，它们来实现，然后你来审查代码。这看起来像是协作，但等你看到计划时，重要的决策早已做出：要解决什么问题，以及要走哪条可能的解决路径。你是在评估别人的答案，而不是在生成自己的答案，而这并非同一种能力。直觉是你做出决策并观察其发展后留下的沉淀。每当设计过程没有你参与，这份直觉就会减少一分。

我正在构建 rubberduck 来解决这个问题。它是一个软件 IDE，引导你走完设计流程，同时替你处理繁琐的调研工作。这篇文章要谈的，是把所有这些思考都交给 agent 后悄然出现的问题。

一个问题通常可以有多种表述方式，有些表述方式比其他方式更容易求解。深入处理一个问题，能让你更好地理解这个问题所处的更广阔背景。

在 rubberduck 的一个早期版本中，我们有两个服务：主应用和 agent 服务。主应用处理用户请求，并在需要 agent 相关工作时与 agent 服务通信，这些工作在一个隔离环境中完成。agent 服务运行在一个常开实例上，成本高于按请求计费。切换过去看起来是个轻松的选择，直到我追踪了用户合上笔记本电脑时会发生什么：请求关闭，而在按请求计费的模式下，agent 会在任务中途终止。那个昂贵的模型并不是浪费。正是它让用户可以离开，而 agent 继续工作。这里没有什么需要修复的。

如果我把这件事交给 coding agent，它会欣然把我们切换到按请求计费，而我们会等到生产环境中 agent 开始中途终止时才发现问题。正是我自己追踪了整个流程，才让我看到正确的产品选择是什么都不做。

当 coding agent 给你一个问题的解决方案时，它会隐性把你引向那个特定方案。它不会提及你本可以解决该问题的所有其他可能方式，以及它们之间的权衡。它还可能引入一些你在审查时可能注意不到的设计决策。这些决策可能导致隐蔽的 bug，或限制你未来能构建的东西。

我在 Stripe Treasury 工作时，参加过一次客户会议，客户当时在做 ACH 的资金流转，需要一种方式将一笔转账与其对应的用户进行对账。显而易见的解决方案是把 id 和其他元数据放进 ACH 的 memo 字段，但该字段太短，放不下。于是我们在会议上提出了若干解决方案，涉及构建新系统来处理对账流程。如果当时已有 coding agent，它很可能恰恰会建议这么做，而我们也会把它建出来。然而，我知道支付通道在底层是可替换的，而 wire 的消息长度要长得多，可以轻松容纳 id 和元数据。这让我们可以采用简单得多的架构，无需在我们这边新增任何基础设施。wire 的成本略高，但相对于我们所讨论的转账金额，这点成本微不足道。

那个解决方案来自我对该领域的直觉理解，而这种理解是我通过长期浸淫在代码中、解决整个技术栈上的问题而建立起来的。让 AI 替你思考的代价，未必体现在当下的 PR 上，而是体现在那样的会议中——你无法把线索连接起来，从而提出优雅的解决方案。

看着代码不断堆积是会上瘾的，因为这感觉像是在积累资产。然而，代码是负债。资产是它为你的客户解决的问题。代码库的复杂度，以及由此带来的 bug 可能性，增长速度远快于代码本身。这种增长在很大程度上是不可避免的，因为成功的软件往往会不断增加功能。即便如此，目标应该是让代码的复杂度大致与其产生的价值保持同步。否则，你可能会发现，即便有 coding agent，任何改动也开始花费更长时间。你还可能发现自己在凌晨 3 点处理故障时，试图判断在一个你已经失去真正直觉的系统里，能否信任一个由 AI 创建的 bug 修复，而它修复的是 AI 创建的代码。

软件开发中的传统契约是：PR 的作者花时间做设计、写代码，因此承担了与代码相关的大部分工作。代码审查者只是另一双愿意提供反馈的眼睛。如果代码审查者现在必须充分理解你所创建功能的背景，才能指出你设计中的每一个缺陷，那他们当初还不如自己来写代码。更可能的情况是，你的 PR 要么被直接拒绝，这会降低开发速度，要么被草率盖章通过，这会损害代码质量。

另一种答案是引入 AI 代码审查者，来管理你可以随意下 prompt 时产生的大量 PR。问题在于，AI 代码审查者不会问你，你正在解决的是不是正确的问题，或者有没有更好的方案。它的职责范围是整洁代码、性能、安全以及其他代码层面的关注点。如果 bug 或设计缺陷越过了它，演变成生产事故，它也不承担任何责任。这份责任仍然落在工程师身上。如果工程师对自己系统的运作方式没有直觉，他们该如何解读系统给出的信号？

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）