The cost of saying yes has changed

过去，小功能请求中最昂贵的部分是编写代码。现在，通常最昂贵的是关于是否要编写代码的会议。

这是一个真正的转变，它悄然颠覆了许多工程直觉。工程师们早期就学到，大多数“小请求”其实并不小：它们需要测试、发布计划、有人需要思考边界情况并在发布后负责行为。如果改动了系统错误的部分，两个小时的改动可能变成两周的干扰。所以我们会反对：这真的需要吗？它应该包含在这个版本中吗？它会改变我们已经达成的协议吗？我不会放弃这种直觉。

但这建立在一个正在悄然瓦解的假设之上，即编写代码第一个版本是昂贵的步骤。对于某一类特定的改动，这已经不再成立。如果你能区分这些改动与其他改动，就可以将“这在范围内吗？”这个问题，替换成一个只需30分钟就能回答的问题，而不是持续两天的争论。

讨论的代价往往高于补丁

这是我经常看到的模式。有人请求一个微小改动，例如在设置页面上显示后端已存在的last_active_at时间戳。团队在讨论线程中花费了40分钟。有人表示这听起来有风险，有人回忆起两年前相关的迁移工作，有人提到截止日期。最终我们得出“大概需要一两天，可能更久”的结论，但信心不足，主要是因为没有人实际尝试过。

当尝试本身是昂贵的步骤时，这个过程是有道理的。你必须暂停当前工作，将上下文加载到脑海中，手动进行修改，编写测试，然后发现二阶、三阶的后果。当第一次尝试变得廉价时，捍卫边界可能比跨越它付出的代价更高。

代理人在讨论线程升温所需的时间内就能生成第一个补丁。这并非免费，也绝非自动正确。但它的成本足够低，以至于明智的做法通常是停止猜测，直接查看真实的代码差异。

第一个补丁是成本检查，而非产品

错误在于将生成的补丁视为交付物。它不是。它只是一个探测工具。它将抽象的范围争论转化为可以检验的具体证据：

• 它是否触及你预期的文件，还是蔓延到五个包？
• 测试是否显而易见，还是改动难以被测试？
• 是否保留了现有的抽象层？
• 是否悄无声息地需要新的产品决策？
• 六个月后，你是否愿意负责这个行为？

这些问题比“这感觉像范围蔓延吗？”更好，因为现在你可以基于证据而非直觉进行争论。如果last_active_at字段返回一个四行代码差异并附带通过的测试，直接发布即可。争论才是昂贵的部分。然而，如果同样的请求返回结果涉及认证中间件，你就学会了这个请求从未真正微小。不仅如此，你仅用30分钟就学到了这一点，而不是两天。

这并不是让AI做决定。而是利用AI让人类判断变得更便宜、更明智。

编写成本低不等于拥有成本低

以下是翻译后的 Markdown 内容：

这里的关键在于，这是人工智能时代最重要的区分点。变更的成本并不因为生成代码的成本低而降低，只有当人类能够自信地审查并拥有结果时，变更才是低成本的。

一个技术上通过但无人愿意拥有的千行代码差异，其实并不是低成本的变更。这属于延迟成本。因此在这种情况下，判断的分界线不是“代理能否写出这段代码”，而是“人类能否验证它”。

• 在后端已存在的显示字段通常变更成本较低。
• 无论代码差异多么整洁，修改授权行为的成本通常较高。
• 对一个经过良好测试的辅助函数进行重构通常成本较低。
• 修改数据保留语义的成本通常较高。

即使代码本身很简单，仍然有许多变更值得坚决拒绝。这包括任何改变产品契约、制造支持负担，或涉及隐私、计费或合规性的变更。AI 降低了生成候选方案的成本，但对拥有一个方案的成本没有任何影响。

将范围纪律更紧密地贴近证据

传统上，范围纪律发生在实现之前，因为实现是需要保护的昂贵部分。现在，部分范围纪律可以转移到审查环节。这并不意味着跳过规划，而是要明确哪些规划真正能带来回报。

在重新讨论一个小变更之前，要求一个受约束的尝试。这些约束才是整个尝试的核心。

生成最小的补丁。将其置于现有的功能标志之后。不要改变公共契约。添加或更新测试。列出你修改的每个文件，并指出任何潜在风险。

如果代理无法在这些约束条件下生成一个干净的补丁，说明请求的规模比你想象的要大，而且在任何人承诺之前，你已经知道它会带来真实的拥有成本。如果它能生成，这也说明了一些问题。无论哪种情况，你都把“这在范围内吗？”替换成了“这需要付出什么代价？我们愿意支付吗？”

新技能是定价不确定性

在人工智能辅助的世界里，最优秀的工程师不会是那些对所有请求都说“是”的人，也不会是那些本能地说“不”的人。他们将是那些能快速评估不确定性的工程师。他们知道何时请求是披着实现外衣的产品决策，何时审查比编写更困难，以及何时变更足够小，以至于最快且负责任的回答就是直接尝试。

最后一个观点是真正全新的。过去“尝试看看”意味着要让开发人员从其他工作中抽身。现在，对于某些类型的任务，这意味着给代理一个有界的任务，并利用结果做出更好的判断。减少猜测的时间，增加监督的时间。减少将实现视为黑箱的时间，增加评估具体成果的时间。

范围蔓延仍然是现实。但“不，因为任何新代码都太昂贵了”这个论点，相比两年前已经弱得多。生成代码的成本已经下降，但理解、审查和拥有代码的成本却没有下降。因此，值得提出的问题已经从“这是否更耗时？”转变为“真正的成本在哪里？”有时，对于一个小而有界变更，真正的成本仅仅是去发现它。

说“是”的成本已经改变。说“不”的成本也应随之改变。

作者

Dalia 是 GitHub Copilot Agent Control Plane 团队的软件工程师，负责为 Copilot 用户构建子代理治理层。

相关文章

/

在 GitHub 上探索更多内容

文档中心

掌握 GitHub 所需的一切资源，尽在一处。

前往文档中心

GitHub

在 GitHub 上构建未来，这里是来自世界各地的开发者可以构建任何事物的平台。

立即开始构建

客户案例

了解使用 GitHub 构建产品的公司和工程团队。

了解更多

GitHub Universe 2026

10月28-29日，加入我们在旧金山或在线参加 GitHub Universe，这是我们的年度开发者盛会，汇聚全球开发者、代理和代码。

立即注册