内容
毫无疑问，编码代理已经改变了软件的构建方式。过去大约三年里，代码生成器已经从花哨的自动补全工具，变成了你等待时就能帮你快速搭出整个应用的工具。具备最佳实践、常见陷阱以及软件“行话”知识的工程师，已经能够与代码共同创作，而不必再纠结于分号和未闭合的括号。
存疑的是，这种变化是否提升了生产力、是否具有成本效益，或者是否对开发者有益。
易于生成的代码给软件开发生命周期（SDLC）的后半段带来了更大压力：代码审查、DevOps/SRE、安全和基础设施。它也给开发者本身带来了更大压力。根据 Smartsheet 的研究，其企业用户的自动化强度同比增长了 55%，整体活动量增长了 46%。这意味着工作日并没有变长；只是工作变得更“密”了，因为自动化产出更多，却并没有减轻人类去判断“什么才算好”的必要。
我与 Smartsheet 的 CPTO Pratima Arora 讨论了这种工作强度升级对软件工程师意味着什么、新的 SDLC 瓶颈为何在于判断，以及我们如何开始重新配置软件构建方式，从而减轻被新生产力拖累的人们的负担。
代码便宜，代码审查就没那么便宜了
在 AI 时代之前，代码之所以昂贵，是因为工程师昂贵。他们掌握着大量关于语言、流程和范式的知识，而这些知识才能产出优质软件。这也催生了一些 糟糕的生产力衡量指标：投入工时、编写的代码行数、每天的提交数。这些指标容易衡量，看起来也像是结果的合理近似。一路走来，组织开始转向结果导向，像 DORA 这样的框架试图为这些结果量化。
这些糟糕的指标如今又卷土重来，完全不顾 古德哈特定律。不仅代理式编码者在炫耀自己的代码行数，组织也在炫耀其 由 AI 编写的新代码占比。工程师甚至可能 按 token 用量排名。带着 tokenmaxxing 的新技术极客风格，已经彻底“AI 上头”了。
除了这种衡量方式很浪费之外，Arora 还举了一个例子说明它对软件组织为何有害：“我们有一位软件工程师，产出的代码量是团队里任何人的 7 倍。她是个明星员工。不仅如此，代码质量也很高。提交和评审都很出色。但团队里另外六个人大部分时间都在审她的代码，而不是自己写代码。”
代码审查需要对整个代码库有广泛理解，尤其当审查要真正有效、真正有帮助时。最好的 代码审查 会把变更放到更大的系统背景中去看，而这要求审查者理解并保持对整个系统上下文的把握。对某次代码提交做出判断的要求，会给审查者带来很大压力。现任 Intuit 的 Carol Lee 博士 说：“本质上是要求你贡献自己的专业判断。所以会有一种压力：‘如果我把这次审查搞砸了，我就是这段代码的守门人。要是我搞砸了，可能就是我的责任。’所以压力很大。”
想想开发者有多讨厌处理遗留代码。我曾猜测，像 Rust 这样的新语言在 我们的年度调查 中更受欢迎，其中一个原因是它们常出现在绿地项目里，开发者可以从零开始写代码。Arora 说：“每当一个工程团队接手旧代码库时，他们总是想先重写，而不是修修补补。从零开始写，并且写成自己能看懂的样子，容易得多；而要看着别人的代码去判断错误到底出在哪儿，就难得多，因为那不是你写的。”
每个构建者，都是决策者
Smartsheet 的研究发现，80% 的 AI 生成内容在最终定稿前都会被编辑。这些修改都来自于对代码（或其他内容）上下文的理解。对于 AI 生成的代码，没有人写过原始代码，因此你需要收集的上下文更多。你可以查看提示词、规格说明以及你的代理所使用的其他上下文，但要据此做出判断，工作量很大。如果我们把软件工作的大部分从编码转向决策，那么每个人都会感受到 决策疲劳 的压力。
在 AI 赋能的软件工程工作流出现之前，开发者每天有相当一部分时间（具体比例取决于你问谁）都在做除写代码以外的事情。如今 AI 负责写代码，工程师就有更多时间去做其他工作。事实上，你可能已经注意到“builder”这一角色的兴起，Arora 将其定义为：“任何理解客户问题或某个痛点、脑中有想法，并且能快速原型和构建软件来测试或交付的人。”构建者的核心能力是理解上下文并做出判断。
Smartsheet 和 其他机构 都发现，这种转变并不会让开发者的生活更轻松，反而让它更紧张。开发者在审查代码、参加会议、撰写文档的同时，后台还有多个 AI 代理在运行。他们感觉自己更高效了，但事实并不总是如此。“工作时长并没有变，但工作的密度变了，对吧？”Arora 说，“我们每天要做的决策数量、我们收集信息并试图据此做出判断的程度，都变了。”
那些需要做很多决策的人，比如 总统和 CEO，之所以每天穿同样的衣服，就是为了少做一个决定。他们会围绕信息收集建立流程，利用多层专家和信任机制，希望在做出重大决策前设置多重检查和验证。判断既是一项技能，也是一套流程，而好的决定来自上下文和经验。正如玩笑所说，经验来自糟糕的决定。
资深开发者之所以资深，是因为他们积累了这些经验，建立了对代码库乃至一般代码的上下文理解，并知道小范围、外科手术式重构的价值。对于代理式编码来说，知道该提供哪些上下文变得更加关键。“我们看到，大多数资深员工会加载更多上下文，然后做更小的改动，”Arora 说，“他们最终处理的是最复杂的部分，因此对他们来说，上下文比代码行数重要得多。”
虽然我们已经知道代理输出存在波动，但人类判断不能成为最终、绝对的验证关口。随着工作强度上升，“构建者”被要求整天做决策，这些决策的可靠性可能会下降。决策疲劳的一个后果，就是你可能会做出更草率的决定。Arora 指向了 ▶ Cat Wu 的一次访谈，她是 Anthropic 旗下 Claude Code 和 Cowork 的产品负责人，她在访谈中谈到源码泄露是人为失误造成的。“即便有人类判断，有时也会因为某些环节稍微松懈而出错，”Arora 说。
如今，组织开始重新配置 SDLC，以缓解开发工作的高强度。个人与团队之间的协调，在快速代码的压力下变得更加吃力。开发者体验的新焦点，发生在代码生成之后。“不同公司成熟度不同，不同团队也处于不同成熟阶段，”Arora 说，“我们正在努力让各团队之间的工具链和系统对齐，让整体更好。”
判断测试应当是端到端的，而不是单元级的
围绕 AI 模型及其工具链的能力每天都在进步。AI 正在进入 代码审查、代码可理解性 和结果 评估，会在发现自己处于危险中时捕捉 bug 并 Wiggamatically 重写代码。与此同时，很少有组织会考虑在没有人类参与最终审批的情况下直接发布代码。“我们每天都在学习的一件事是，这些工作流和团队系统，原本是为 AI 不是日常存在的旧工作方式而建立的，”Arora 说，“随着我们提升了个人生产力，我们并没有把重点放在那些交接环节或协调流程上。”
想想开发生产力的衡量标准从代码行数和提交数，转向变更失败率和部署频率时发生了什么。整个行业从输入指标转向了输出指标，或者说结果指标。这些输出指标不再只看某个开发者在炫酷机械键盘上敲了什么，而是必须考虑整个流程——规划、写代码、CI/CD 和 DevOps。
另一个容易联想到的类比是测试。单元测试检查某个功能或提交是否完成了它承诺的事情；端到端测试则验证整个流程。判断——尤其是人类判断——或许可以成为对整体结果的验证，而不仅仅是对某些特定功能和提示进行抽查。Arora 说：“随着我们把这些低阶事务自动化，我们的[判断]会转向更高阶的问题。”
大的判断关口会出现在周期的开头和结尾。一方面，开发者需要定义需求、护栏、规格说明以及允许的依赖项；另一方面，他们需要定义成功和失败模式、安全性以及可靠性。Smartbear 的 AI 与架构副总裁 Fitz Nowlan 说：“要从意图、功能和需求的角度去思考。不要一定从 API 调用或某种特定输入输出形状这类低层术语去想。你当然可以验证这些，但当开发速度提升 10 倍时，QA 速度也必须提升 10 倍，而唯一能以火制火的方法，就是用火攻火。”
Arora 一直在团队中践行这种端到端的判断流程：“我们正在从产品经理、设计师到工程师，把整条链路都串起来，每个人都在变成构建者。整个设计系统目前已经同时集成到 Claude 和 Cursor 中。理解客户问题的设计师会先做原型和前端代码，然后交给工程师提交。”
“但我的设计师现在还不能完全提交代码。我们仍然要求工程团队审查他们的代码。未来，他们应该能够直接提交代码，但我们现在还没到那一步。”
结论
易于生成的代码，意味着更难审查的拉取请求。这些 PR 需要大量上下文和大量判断，开发者也不得不更频繁地做决策。这种强度正在导致决策疲劳和倦怠。
随着模型、执行框架和方法不断进步，AI 问题或许也需要 AI 解决方案。你会信任一个 AI 代理仅凭一份规格说明就端到端构建软件吗？你会愿意放弃对单个提交的审查，换成对最终结果的审查吗？如果软件工程师和构建者想在一个 AI 赋能的世界里高效工作，而不是把键盘一扔，转行去做手工家具匠人，我们或许需要学会对这两个问题都回答“是”。