Markus Eisele 实测智能体编码：按验证难度与学习价值决定委托多少代码

O'Reilly Radar· Markus Eisele·2026-10-29 18:54· 1 小时前AI 评分58

廉价的代码，昂贵的信心

AI 导读

IBM 工程师 Markus Eisele 以内部工具 Task Viewer 为例，分享自己委托编码智能体实现并验证结果的经验。

正文 · 原文

最近我用一个编码智能体构建了 Task Viewer，这是我们在 IBM 内部使用的、面向 IBM Bob 的小型社区辅助工具。它是 Bob 的一个便捷插件，不承担关键的生产角色。尽管它在内部帮助了一些用户，但对我来说，这是一个真实项目实验，用来弄清楚我能把多少实现工作委托出去。委托多少还取决于执行任务的人还需要学习什么。熟悉该应用的人可能已经知道如何检查结果，而正在学习该系统的开发者可能需要亲自完成部分实现，才能建立起这种理解。

即使我把所有编码都交给智能体，我对自己提出的基本要求仍是手动检查功能和设计。我想亲自使用这个应用，看看它的行为是否符合我的预期。当我真的需要查找某些内容时，设计是否合理？信息的呈现方式是否让我能够跟上？即使应用很小、实现工作大部分已委托出去，这些问题仍然需要我花时间处理。

对于 Task Viewer，我还编写了大量 UI 测试，以检查数据是否正确显示。这让我能够在应用发生变化时重复部分检查。不过，关于计算还有一个单独的问题。在屏幕上正确的位置看到一个数字，并不能告诉我这个数字是否正确。我针对底层数据运行 SQL 查询来核对计算，回溯到应用本应表示的记录。

这个看似普通的步骤涉及相当多的理解。要检查一项计算，你需要知道结果应该意味着什么，以及哪些记录应该对它有所贡献。你需要有一些预期，用来与应用显示的内容进行比较。幸运的是，团队帮助我发现了数据中我无法自行推导甚至解释的关系。

对于这个特定应用，我既能检查它的行为，也能检查它背后的数据，而且当我自己的理解不完整时，有人可以求助。它有限的角色也给了我试验的空间，而不必把结果纳入生产系统。建立这种信心需要时间，因为我必须检查行为、确定数字应该意味着什么，并解决我自己无法回答的问题。对我来说，所有这些都属于评估我能委托多少编码工作的范畴。

这就是为什么我发现“智能体帮我完成了 80%”这类描述越来越难以解读。我理解这种说法背后的感受。你有了能运行的东西，大部分界面已经存在，看起来剩余的工作应该是较小的部分。但基于错误记录的计算可能看起来完全合理，直到你找到检查它的方法。在纠正任何东西之前，你必须发现你的理解与应用行为在哪里出现分歧。智能体也可能有助于这项调查，尽管它已经生成的代码量几乎不能告诉你这需要多长时间。

DORA 对 1,110 份来自 Google 软件工程师的回复所做的分析描述了代码生成过程中节省的部分时间被用于审计和验证，同时也带来了生产力收益。我自己实现的应用程序我也会去检查，因此任何比较都需要包含达到我们准备采用的结果所需的时间。否则，我们可以通过把人工版本中省略的检查计入其中，让智能体开发显得异常昂贵；或者在智能体声称完成时停止计时，让它显得异常便宜。

其中一些投入可以让后续变更更容易被接受。一旦某个 UI 测试覆盖了重要的行为，它就能在应用程序变化时持续发挥作用；而针对一小组记录校验过的计算可以变成回归测试。我在之前关于适量规格说明的文章中写过这一点。把预期转化为可执行的检查，可以让我们复用其中投入的部分思考。不过，我们仍然必须确立这个预期。如果应用程序及其测试共享了同一个错误理解，那么更频繁地运行测试只会不断确认同一个错误。

对于 Task Viewer 而言，这些预期取决于数据中的关系，而同事帮助我理解了这些关系。我知道如何运行查询，但在判断它应该返回什么之前，我仍然需要他们的解释。只看我花在检查上的时间，会忽略他们在这些对话中带来的知识，就像只看生成的代码会忽略我的检查一样。我们接受一项变更所需的信心，可能取决于多个人对系统不同部分的理解。

当某人仍在学习其中某一部分时，实现本身可能就是他们开始理解它的方式。沿着一个值从数据库追踪到屏幕，会让他们有理由去问为什么选择某些记录，以及应用程序如何使用它们。如果智能体替他们完成了整条路径，他们可能得到一个可用的功能，却没有自己回答那些问题。同样的任务，对经验丰富的工程师来说可能是合理的委派，对另一个人来说则可能是重要的学习机会。

Shen 和 Tamkin 关于 AI 如何影响技能形成的研究报告了一项随机实验，52 名开发者学习一个不熟悉的 Python 库。接受 AI 辅助的参与者在即时理解评估中得分较低。但研究人员也观察到，那些保持主动参与 AI 的参与者学习效果更好，尽管这一观察并不能确定哪种使用 AI 的方式带来了更好的学习。一个简短的练习无法告诉我们工程师在数年间如何发展，但它给了我们理由，在评估某人从任务中获得什么时，不只关注分配的功能是否完成。

我们可以在智能体开始之前就自主性做出决定，约定哪些部分它应自行完成，哪些部分应由开发者尝试。有时限制自主性的原因是我们还没有令人信服的方式来检查结果。有时我们可以相当容易地检查结果，但我们希望执行任务的人培养特定技能。在第二种情况下，即使智能体可以产出可接受的代码，有意将部分实现留给开发者也可能是正确的选择。

正确的选择或许可以通过提出这些问题来做出：团队需要付出多少努力才能确认这一结果对其预期用途是正确的？而这位开发者通过完成这部分任务需要学到什么？一个功能对同事来说可能很容易验证，因为他们已经了解这个应用，而实现它的人仍然需要先了解它如何运作，才能对未来的变更负责。我们不需要把每一次例行变更都变成练习，但我们可以选择那些能让某人有机会培养他们日后还会需要的理解的任务。

表1适用于某个特定任务或任务的一部分，以及某位特定的开发者。“易于验证”意味着我们有可靠的方式来评估其预期用途的正确性。如果我们不确定测试应该断言什么，那么一个通过的测试套件并不能解决这个问题。当检查很困难，或者我们还不知道如何检查时，第一步是在了解该领域的人的帮助下缩小不确定性。把整个任务交回给缺乏经验的开发者，会让这种不确定性悬而未决。

设想一位新员工在一个小型 Java 应用的问题列表中添加“仅显示未关闭问题”过滤器。智能体可以生成请求参数、查询条件以及对界面的更改。对于已经了解该应用的人来说，这可能是一种合理的委派。而正在学习该系统的人还需要弄清楚哪些状态算作未关闭、应用在何处选择记录，以及团队期望如何测试这一更改。与同事讨论这些问题，是学习如何为这个应用做贡献的一部分。

对于这项任务，开发者可以先沿着应用跟踪现有的请求，并在让智能体实现过滤器之前编写第一个测试。假设列表一次显示二十个问题，而测试数据包含二十个已关闭问题，后面跟着五个未关闭问题。选择“仅显示未关闭问题”应显示那五个。如果应用先加载二十个问题，然后在浏览器中过滤它们，屏幕将会是空的。与同事一起弄清这一差异，让开发者有机会理解过滤和分页发生在哪里。智能体可以帮助处理不熟悉的框架代码，而开发者则调查为什么预期的问题缺失了。

一旦开发者能够解释该行为，并有一个能捕捉错误的测试，智能体就可以处理更多周边实现工作。之后一个按负责人筛选的需求，给了他们运用所学内容的机会。他们能否判断哪些问题应该出现，以及现有测试是否覆盖了筛选条件的组合？他们在评审期间的说明，为团队决定下一次变更可以委托多少提供了依据。第一次任务也让新员工获得了询问需求以及与其他开发者讨论变更的经验。

经验丰富的工程师也有充分理由在陌生领域限制智能体的自主权。尽管我写查询很熟练，我在 Task Viewer 的数据上仍然需要帮助。当任务把我们带入系统中我们尚不理解的某一部分时，重新考虑该移交多少是合理的。团队可以通过改进测试和分享成员所知来让验证更容易。它也可以选择在验证变得容易之后保留一个学习机会，因为另一个人在未来变更中会需要那份理解。

被要求通过任务来学习的开发者需要时间在应用中追踪行为，并需要有人与之讨论。如果我们认同这一目的，却只根据功能出现得多快来评判结果，就会让他们难以为自己保留学习步骤。我们还可能把更多检查留给同一些经验丰富的同事，同时给其他人更少机会去发展分享所需的知识。

在开始之前，开发者与支持他们的同事可以就以下事项达成一致：智能体将处理什么、开发者将做什么以及为什么、以及在后续任务中什么情况会证明改变这种分工是合理的。对于状态筛选这个例子，这意味着留出时间让开发者追踪请求并编写第一个测试，然后由智能体实现筛选。随着这种理解的发展，他们可以在相关变更上重新审视分工。

在 Task Viewer 上，我可以委托大部分编码工作，因为我有办法检查结果，也有同事能在我理解不完整的地方提供帮助。我希望在我们要求智能体做更多事情时，继续创造这些条件。更好的检查可以减少接受变更所需的精力，而花在学习上的时间可以帮助另一位开发者具备做出那种判断的能力。有时这意味着有意把第一个测试和调查留给一个人，即使智能体可以完成它们。当我们期望那个人对下一次变更负责时，给他们理解这一次变更的机会，应属于我们关于委托多少的决策。

来源：O'Reilly Radar · oreilly.com