@yibie: Chrome DevTools 的创建者 Addy Osmani：代码质量的重心从 code review 挪到了 harness——人读不完 agent 产出的代码，质量现在由约束来兜底。 《Agentic 代码质量》 Agentic …

Chrome DevTools 的创建者 Addy Osmani：代码质量的重心从 code review 挪到了 harness——人读不完 agent 产出的代码，质量现在由约束来兜底。 《Agentic 代码质量》 Agentic 代码质量 作者：Addy Osmani（Google 工程负责人，Chrome DevTools 的创建者） 在人类历史的大部分时间里，我们都是靠 code review 来评估代码质量：有人读你写的代码，确认它干净、考虑周全、速度快、好懂、测试充分。对 agent 来说，这套办法没法规模化——代码实在太多，没有人读得完。结果就是，越来越多的质量检查必须挪到 agent 周围的 harness、环境和操作系统里去完成。我自己仍然读代码、做 review，但我非常刻意地选择：哪些地方我愿意让约束来充当检查。 软件质量，现在取决于你为 agent 设下的约束。 配图：Guillermo Rauch 的清单。 如果你不读代码——不管是亲自读，还是通过 agent 式的追问——下面这些至少有一条成立： • 你是初学者 • 这软件是一次性的 • 你在做原型 • 你没有用户、没有收入 • 你在背上债务和风险 • 你的问题很基础 顺便说一句，这些都没问题。但现实是，模型还没到"完全自主"的阶段。 Guillermo 这张清单，是判断"你能不能承受不读代码"的好测试。注意，每一个"是"，其实都是在说代价有多低——没有用户、一次性代码、原型。一旦代价上来了，就必须有东西去读代码。如果不是你亲自读每一个 diff，那就得是约束来读。 约束定义了系统被允许做什么：把测试和确定性约束，扔向 agent 的每一个提案。正是靠设置和维护这些约束，我们才建起这样的循环：可靠地交付高质量的生产软件，哪怕 agent 每天制造几十万乃至几百万次变更。 我们把这些约束叫做质量闸门（quality gates），它们有很多种形态。 它们包括常规的单元测试、属性测试和验收测试。它们包括变异测试（mutation testing）：生成代码的各种变体，跑同一套测试，确保没有人把我们会漏掉的 bug 偷偷塞进来。它们包括围绕代码质量的指标，比如圈复杂度（cyclomatic complexity）和行长度，这些指标帮助代码保持可读。 配图：Uncle Bob Martin 的原话。 我比你们年纪大得多，60 年代末就开始写代码了。我现在的策略是：完全不读我的 agent 写的任何代码。这是唯一能让我享受到它们生产力的方式。我做的事正相反：用极端的约束把 agent 包围起来。单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，还有一大堆别的。最终，我对它们产出的代码有非常高的信心，因为它们必须跑过我所有约束和测试组成的闯关通道（gauntlet）。 两个人可以在"要不要读代码"上意见相左，却对机制达成一致。Guillermo 读。Bob 一行都不读。他们俩描述的都是同一条闯关通道，区别只在于通道里是否坐着一个人类。（我不认同 Bob 的其他观点） 约束还在另一个环节很重要：系统会接受哪些提案、并把它们应用成代码变更。当一个变更提案从运行 agent 的解释器，经过 agent 控制器，一路走到生产环境时，我们已经在它身上做过足够多的检查，足以确信它发布是安全的，而且它造成的影响被牢牢限制在 agent 的职责范围内。 agent 可以提案任何东西。你的约束决定一个提案是否足够安全、正确、范围可控、有用，值得你和你的团队把它发上线。 这个模型给出的东西很多，但漏掉的也很多，而这些遗漏值得今天认真想一想。其中一个问题是自主性（autonomy）：agent 也许能把意图执行得很好，但一旦信息缺失、或者它想做的事是模糊的，就可能失败。这既适用于任务本身，也适用于任务被 harness、环境和其他组件参数化的方式。 人类发布不了好代码的很多原因，agent 一样会遇到：扛不住脚本驱动压力的脆弱环境、不确定性的构建、缺失的权限、孱弱的测试。这倒逼我们去建设一个更好的环境：给 agent 可信的反馈，允许低破坏性的失败模式，让成功可以一步步积累起来。 我们想要的环境是：agent 能干真活，能拿到它信得过的反馈，失败了也不会造成多大破坏。 另一个重要问题是信任。我们不能把意图轻信地交给某个东西，哪怕它像现代 agent 一样聪明、一样健壮，却不检查正确性。我们从信任出发，但信任必须靠实力挣来。 有些约束在工作开始之前塑造工作。有些在 agent 干活时给它反馈。还有些决定它的产出到底能不能跨过生产环境的边界。 给一个系统套上验证结构，建模方式有一大堆。 配图：自主性阶梯。 自主性是通过验证循环挣来的，不是模型赐予的。 • 常规、已被验证过的变更（这类活以前见过）→ agent 独自推进 → 发布 → 高自主性 • 不平凡的变更（真有爆炸半径）→ 自动检查 + 定向 review → review 之后发布 → 有条件自主 • 新颖、高风险、证据薄弱的变更 → 由人来决定（认证、权限、资金、迁移、不可逆操作）→ 人类决策 自主性是任务、证据和 harness 的属性，不是模型名声的属性，也不是一项永久设定。证明一项变更属于常规操作，它就会往上走。新颖、风险和弱证据，早早就会撞上阻力。持续的成功换来更多自主性。 我的经验是：为约束配一套更广、但刻意挑选过的检查，而不是只靠单元测试。思路是每个检查有各自独立的职责，从类型安全和性能，一直到后期的安全扫描。你也可以定义自己的约束，包括 ESLint 这类 lint 工具能够执行的架构规则。这些工具大多有内置钩子，出问题时可以把 agent 或人类拉进来。 就目前而言，agent 产出的是有用的东西还是一堆废料，差别很大程度上仍然来自运营这套循环的团队的功力。 AI 给了我们海量的代码生成和速度，但这也意味着，让人去 review 每一次变更变得越来越难。你必须反过来，刻意规划人的注意力投向哪里。如果你往一个本来以机器速度运转的系统里塞进一道人工检查，就别奇怪生产力会受影响。人的注意力稀缺而宝贵，我们应该主动把它导向那些最微妙、最需要判断力的问题。下游的人类只应该在自动护栏失效时才被拉进来。 未来的"code review"会变得非常不一样 正确性是一个重要维度，但你还会关心别的：可维护性、性能、安全、效率和可理解性。正如正确性可以分解成许多种信号，质量的其他部分也一样。而且重要的不只是我们设了多少约束，更重要的是它们是否足够有挑战性，够得着我们给质量和生产就绪度划的那条线。 软件质量不是一个单一指标。把它想成一组信号，对你和你的团队来说，每个信号的重要程度各不相同。 配图：约束轮盘。把约束设在你的 agent 周围： • 可理解性：review、可回答性 • 成本效率：token/算力预算 • 可维护性：覆盖率、复杂度 • 正确性：单元、属性、变异测试 • 安全：SAST、依赖、密钥 • 性能：性能预算、负载 • 可访问性：axe、对比度、键盘 agent → 发布：出口闸门，代码多到读不完，反向压力，抵制坏工作。 反向压力（back-pressure）可以通过很多工具实现：编译器拒绝非法代码、测试失败、安全策略拦截坏实践、CI 拒绝部署。理想情况下，它应该贯穿整个循环，而不是在所有工作结束之后才补上一次审查。 配图：Dex Horthy 画的同一个循环的地图，出自《为什么软件工厂会失败》（Why Software Factories Fail）。图中绿色的框是他的论点：眼下，人类 review 应该回到循环里，而不是被循环取代。图里的流程大致是：用户反馈进入监控和生产，化成待办流进 issue 系统，由编排把任务交给沙箱里的 agent 构建，产物经过 CI/CD 检查、单元测试、静态扫描、安全检查和 agentic code review，最终交回给人类 review 代码，再走发布。 约束和反向压力，让 agent 在坏工作变成问题之前就抓住它 如果变更量大到工具消化不过来、约束施加不上去，会发生什么？我们最终会堆出一条队列，依赖一套以人类速度运转的验证系统。要规模化，我们就要尽量把检查压进整个验证循环，而不是等到最后。如果我们能在自动检查内部完成扩展，就能提升整个交付系统的速度和吞吐。如果验证循环里没有空间了，我们有几件事要做。 第一，扩展验证系统，制造更多容量去约束和顶回涌进来的变更。第二，降低 agent 生成新变更的速度，让验证跟得上工作量。第三，降低我们的质量门槛，让验证不用顶得那么狠。从规模化的角度看，这几件事我们都要做好准备。同时，我们也不该忽略：在某些方向上松绑，反而能干更多活。也许我们可以靠成群的 agent 开发者或自动化软件工厂，来提升 agent 生成变更的速度，让它们直接产出变更，而不是等我们一个一个 review。 而在有些地方，我们也许想给它们更多自由，只要在别的地方收得更紧。在最在乎的地方收紧约束，就能在不牺牲质量的前提下最大化吞吐。这些决策过程里有大量选项。最明显的是：我们不得不在质量的不同维度之间做取舍。正如我们反复强调的，安全非常重要，但我们也曾不得不在"交付安全"和"按时交付产品"之间做取舍。这条光谱的一端是创新导向，另一端是质量导向。在某个点上，我们必须选择自己站在这条光谱的哪里。 我们想把环境和系统给出的清晰反馈，送回给 agent 或团队，让人们把精力放在更主观的事情上：品味、意图和架构。如果我们能帮人类待在约束的安全区间之内，就不必让他们费劲去查哪里出了问题。 软件质量不只是正确性。软件质量还意味着可维护性、好性能、安全、效率，以及易于理解。所有帮我们达到这些标准、让生产持续运转的约束，都会在我们的交付流水线里制造反向压力。 我们需要刻意地决定：哪里施加强约束，哪里移除或放松约束。在同时服务于这两个目标的地方施加强约束。如果它们连其中一个目标都服务不了，就别留着。随时准备按情况抬高或降低标准。还要记住：正是软件系统不同位置上的这些约束，让软件质量变得可以强制执行。 我们应该在约束最能发挥这双重作用的地方施加强约束，并考虑移除或放松那些哪个目标都服务不好的约束。我们也应该随时准备按需要上下移动质量门槛。实际上，正是软件系统各个位置上的这些约束，给了质量它的牙齿。很多情况下，我们可以靠部署新工具、或加强已有工具，来制造更多反向压力和更多约束。所有这些都可以用来顶回大部分变更请求。我们要把它们建到整条流水线里去。 配图：软件工厂。意图进来，agent 实现，证据决定什么能发布。 • 意图：issue、规格、目标 • 塑形（工作开始前）：拆成有边界的子任务、风险边界、意图+上下文 • 反馈（agent 干活时）：沙箱+可复现构建、测试、类型、诊断、机械式反向压力 • 边界（能跨进生产吗）：验收+QA、安全扫描、发布闸门（CI） • 生产：持续监控 人类只 review 例外：弱证据、新颖、风险，会升级到他这里。约束为工作划界；agent 自己迭代；一次通过的测试只是一个声明，不是裁决；每起事故都会留下一个新的测试、监控或策略。有些约束塑造工作，有些在工作过程中给反馈，还有些决定它能不能跨进生产。生成和验证必须一起扩展。快速拒绝坏工作，并为剩下的东西背书，这就是优势。 我们不想等到流水线的末尾，才由 CI 系统告诉我们：不修问题就不许部署。我们要尽可能早地、通过每一条可能的通路，用上这些信号。这套系统里最终的约束，是我们给自己套上的那个：为构建和运营这套系统所做的一切决策和行动负责。但和其他所有约束一样，我们需要深思熟虑地取舍：我们想让自己的判断力发挥多大的约束作用、多大的反向压力，以及是否让它充当最终检查。 质量，就藏在我们给 agent 设下的约束里。所以，当你在为自己的应用思考质量时，接过这道题，拿出你自己的约束驱动方案。 说到质量——agent 正在写你的代码。Sonar 给你质量闸门，让代码可以发布。它对每一次提交跑同一套完整检查：深度跨文件分析、一张风险分布地图、一道把每个人类和 agent 都拉到同一标准的质量闸门。 本文被 Pangram 4 评为 100% 人类撰写。 原文：https://x.com/i/article/2087205551038230528… #AgenticCoding #CodeQuality #AIEngineering