O'Reilly Radar 的一篇文章指出，随着智能体写代码变得廉价，人工评审成了瓶颈，因此主张把“证据”作为接受智能体生成代码的前提条件。作者建议在实现前先就需要的行为和预期的“影响范围”（blast radius）达成一致，再用这些证据发现偏离，并决定 diff 中哪些部分需要人工逐行检查。文章用一个虚构的退款服务为例：超过 100 欧元的退款需先获授权，智能体却顺手在共享支付客户端里加了超时重试，说明小改动也可能带来大范围影响，甚至出现重复退款。文中建议采用双向追溯（引用 NASA 的软件工程指南），检查代码被破坏时测试是否真的失败（引用 Google 的代码评审指南），按潜在影响决定评审深度，并为每个 pull request 保留一份简短评审记录，把约定行为、证据、额外行为和未决问题对应起来。文章还引用一项 2026 年关于 LLM 需求符合性判断的研究，发现模型会拒绝正确实现、接受有缺陷的实现。