编码代理正在给所有人带来决策疲劳

标题：编码代理正在让每个人陷入决策疲劳

URL 来源：https://stackoverflow.blog/2026/05/21/coding-agents-are-giving-everyone-decision-fatigue/

Markdown 内容： 毫无疑问，编码代理已经改变了软件的构建方式。在过去三年左右的时间里，代码生成器从花哨的自动补全发展为能够在你等待时快速生成整个应用程序的工具。具备最佳实践、陷阱和软件语言知识的工程师能够与代码协作创作，而无需手动处理分号和未闭合的括号。

但目前尚不确定这种变化是否具有生产力、成本效益或对开发者有益。

易于创建的代码给软件开发生命周期（SDLC）的后期环节带来了更大压力：代码审查、DevOps/SRE、安全性和基础设施。它也给开发者自身带来了更大压力。根据 Smartsheet 的研究，其企业用户的自动化强度同比增加了 55%，整体活动增加了 46%。这意味着工作日并没有变长，只是工作密度增加了，因为自动化虽然产生了更多成果，但并未减轻人类决定“什么是好”的需求。

我与 Smartsheet 的 CPTO Pratima Arora 讨论了这种工作强度增加对软件工程师意味着什么，为什么新的 SDLC 瓶颈是判断力，以及我们如何开始重新配置软件构建方式以减轻承担新生产力负担的人们的负担。

在 AI 之前的时代，代码很昂贵，因为工程师很昂贵。他们对产生优质软件的语言、流程和范式拥有大量知识。这导致了一些糟糕的生产力衡量标准：花费的时间、编写的代码行数、每日提交次数。这些指标容易衡量，看起来像是结果的良好近似值。在此过程中，组织开始关注成果，像 DORA 这样的方案试图量化这些成果。

这些糟糕的指标正以复仇之势回归，古德哈特定律也无济于事。不仅代理型编码器在炫耀他们的代码行统计数字，而且组织也在炫耀他们由 AI 编写的新增代码百分比。工程师可能会根据他们的 token 使用量排名。这种新技术文化带有代币最大化的氛围，并且被 AI 洗脑。

除了这是一种浪费的衡量方式外，Arora 还举了一个例子说明这对软件组织为何不好：“我们有一位软件工程师产出的代码是她团队其他人的 7 倍。她是超级明星。不仅如此，她还产出高质量的代码。检查和评审都很棒。但团队中的其他六个人却把大部分时间都花在评审她的代码上，而不是编写代码。”

代码审查需要对代码库有广泛的专业知识，特别是如果评审要有效且有帮助的话。最好的代码审查会从更大系统上下文的角度审视变更，这需要掌握并理解更大系统的上下文。这种对代码提交进行判断的要求会给评审者带来很大的压力。“你基本上被要求贡献你的专业知识，”Carol Lee 博士现在在 Intuit 工作说道。“所以存在一种‘如果我这次评审出错，我就成了这段代码的守门人。如果我搞砸了，那可能是我的错’的感觉。因此那里有很多压力。”

想想开发者多么讨厌处理遗留代码。我推测，较新的语言如 Rust 在我们的年度调查中获得更多喜爱的原因之一是它们出现在绿地项目中，开发者可以从头开始编写代码。“每当工程团队接手一个旧代码库时，他们总是想先重写它再修复它，”Arora 说。“从头开始编写代码更容易让你理解它，而查看代码并判断错误发生在何处则更难，因为你不是代码的作者。”

Smartsheet 的研究表明，80% 的 AI 生成内容在最终定稿前都会被编辑。这些修改来自于对代码（或其他内容）上下文的理解。对于 AI 生成的代码来说，没有人编写原始代码，因此你需要收集的上下文信息更多。你可以查看提示词、规范和代理使用的任何其他上下文，但这需要大量工作来做出判断。如果我们正在将大部分软件工作从编码转向做决定，那么每个人都将会感受到决策疲劳的压力。

在 AI 驱动的软件工程工作流出现之前，开发者花费了相当大的比例时间（具体数字因人而异）用于除编码之外的工作。如今 AI 编写代码后，工程师有了更多时间从事其他工作。事实上，你可能已经注意到“建造者”的兴起，Arora 将其定义为“任何理解客户问题或难题，并能快速原型设计和构建软件以测试或交付的人”。建造者的技能核心在于理解上下文和做出判断。

Smartsheet 和其他研究机构发现，这种转变并没有让开发者的生活变得更轻松，反而让他们更加忙碌。在开发者审阅代码、参加会议和撰写文档时，多个 AI 代理在后台运行。他们感觉更高效，但事实并非总是如此。“时间没有变，但工作密度变了，对吧？”阿罗拉说道。“我们一天内做出的决策数量、收集的信息量以及从中做出决策的方式都发生了改变。”

人们之所以会做出大量决策（比如总统和 CEO）每天穿同样的衣服，是因为少了一个决策。他们会围绕信息收集建立流程，利用多层专家和信任机制，在做出重要决定之前尽可能地增加多重检查和验证。判断是一种技能，也是一种流程，而好的决策来自于上下文和经验。正如笑话所说，经验来自糟糕的决策。

资深开发者之所以被称为“资深”，是因为他们拥有丰富的经验，了解代码库和代码本身的整体上下文，并理解小而精准的重构的价值。对于代理编程而言，知道提供哪些上下文变得尤为重要。“我们看到大多数资深开发者会在上下文中加载更多内容，然后做出较小的更改，”阿罗拉说。“他们最终处理的是最复杂的部分，因此需要更多的上下文，而不是代码行数。”

尽管我们知道代理输出存在变异性，但人类判断不能成为唯一可靠的验证手段。随着工作强度的增加，“构建者”被要求全天不断做决定，这些决策的可靠性可能会下降。决策疲劳的一个副作用就是你可能做出更草率的决策。阿罗拉引用了与 Claude Code 和 Anthropic 的 Cowork 产品负责人 Cat Wu 的一次访谈，她谈到了源代码泄露是由于人为错误导致的。“即使有主观判断，有时也会出错，因为我们某些环节可能会变得有些松懈，”阿罗拉说道。

现在，组织正在重新配置软件开发生命周期（SDLC），以减轻开发工作的强度。个体与团队之间的协调在快速编码的压力下变得困难重重。开发者体验的新焦点出现在代码生成之后。“不同公司处于不同的成熟度阶段，不同团队也是如此，”阿罗拉说。“我们正在努力统一工具和系统，使团队之间的协作更加顺畅。”

AI 模型及其相关工具正日益完善。AI 正逐步进入代码审查、代码可读性和响应评估领域，在发现潜在问题时自动修复代码，甚至可以自动重写。然而，很少有组织会在没有人工最终审批的情况下发布代码。“我们每天学到的是，工作流和团队的系统设置仍然适用于过去的人工方式，那时 AI 并不是日常的一部分，”阿罗拉说。“虽然我们提升了个人生产力，但我们并没有关注交接环节或团队间的协调。”

回想一下当开发效率的概念从代码行数和提交次数转向变更失败率和部署频率时所发生的变化。整个行业从输入指标转向了输出（或结果）指标。这些输出指标不再只关注开发者在精美机械键盘上做了什么，而是必须考虑整个流程——规划、编码、CI/CD 和 DevOps。

另一个让人联想到的对比是测试。单元测试用于验证某个功能或提交是否完成了它承诺的任务；端到端测试则验证整个流程。判断——尤其是人类判断——可能会成为对整体结果的验证，而不只是对特定功能和提示的抽查。“随着我们自动化了一些低阶任务，我们的判断力将转向更高阶的问题，”阿罗拉说道。

关键的判断节点将在流程的起点和终点。一方面，开发者需要定义需求、约束条件、规范和允许的依赖项；另一方面，他们还需要定义成功与失败模式、安全性和可靠性。“要用意图、功能和需求来思考，”Smartbear 公司 AI 和架构副总裁 Fitz Nowlan说道。“不要一定从 API 调用或特定输入输出格式这样的底层角度去思考。当然你可以验证这些，但随着开发速度提升十倍，质量保证的速度也必须提升十倍，而对抗火焰的唯一方法就是用火来灭火。”

阿罗拉已经在她的团队中应用了端到端的判断流程：“我们正在审视从产品经理、设计师和工程师整个链条上的工作，每个人都成为了构建者。目前整个设计系统已经集成在 Claude 和 Cursor 中。设计师理解客户问题后会构建原型和前端代码，然后交给工程师进行代码审查并合并。

“但目前我们的设计师还不能直接提交代码。我们仍需工程人员审核他们的代码。未来他们应该能够直接提交，但我们还没到那一步。”

自动生成的代码意味着更难审查的拉取请求。这些PR需要大量的上下文和判断力，开发者不得不更频繁地做出决策。这非常耗费精力，导致决策疲劳和倦怠。

随着模型、工具和技巧的不断改进，AI相关的问题可能需要AI解决方案。你会信任一个AI代理仅根据单一规范就端到端地构建软件吗？你能否接受用对最终结果的审查来换取对单个提交的审查？如果软件工程师和构建者要在AI赋能的世界中有效工作，而不至于放下键盘成为手工家具制造者，我们可能必须习惯于对这两个问题都回答“是”。