编码提升巨大，交付提升不大，短板在审查

软件开发工厂可以在极少人工干预的情况下，将意图转化为经过测试的代码。代理拾取排队的工作，编写并测试实现，响应检查结果，并为发布做好准备。只要有足够的沙箱、工具、评估器和重试机制，大部分软件生产过程都可以自主运行。

通过检查会增强对所覆盖行为的信心，但接下来是更难的决策。代码可能按规格工作，但仍然可能引入糟糕的边界、意外的依赖，或者超出变更价值本身的风险。

审查关卡是团队不仅决定代码是否有效，而且决定它是否应该成为系统一部分的地方。

StrongDM 描述了一种软件工厂模式：人们定义意图、场景和约束，然后代理生成并验证实现，而不需要传统的人工代码审查。这种方法将更多责任放在了验证框架上。

对于构建长期存续系统的团队，有一条实用的设计规则：审查深度应跟随出错成本。

或者，正如 Vercel 首席执行官 Guillermo Rauch 所说：在 X 上阅读全文。

这并不是说每次变更都需要人工逐行阅读代码。常规的、边界紧凑的变更可以通过自动化检查推进。但影响安全、架构、客户数据或公共接口的变更仍然需要可见的审查关卡。

这是一个软件工厂工作流：自动化推进变更，而人工审查的深度随风险和影响范围增加。

编码收益在发布途中逐渐缩小

编码代理带来的生产力提升是真实的，但随着工作向生产环境推进，这些提升会缩小。

2026 年的工作论文《编写代码 vs. 交付代码》研究了超过 10 万名 GitHub 开发者。它发现，在连续几代 AI 工具下，编码活动有巨大提升，而项目和已完成发布的提升较小。作者将这种模式描述为一个“短板问题”：审查、集成、测试和发布中的人工工作制约着生产链条。

更多代码进入流程，而审查、集成和发布仍然需要时间和技术判断。

一个提议的答案是审查关卡的更深层自动化。在《为什么软件工厂会失败》中，Dex Horthy 认为，测试和代理循环更倾向于奖励即时正确性，而不是长期可维护性。

测试可以在几分钟内确认一个已定义的行为有效。糟糕的边界、不必要的耦合或“霰弹式修改”的成本，可能在几个月后才浮出水面——当下一次变更变得比本应更难时。

这种延迟成本很难表达为一个快速的奖励信号。一个模型今天可以获得通过结果，却让明天的工作更昂贵。像 SlopCodeBench 这样的长周期基准测试，正开始衡量代理在一系列检查点中接收需求时的表现。

构建通过是有用的证据。可维护性还取决于变更如何塑造未来的工作。

验证框架能衡量团队知道如何检查的内容

框架工程至关重要。代理需要受限的工具、可复现的环境、清晰的停止条件和可靠的反馈。

Addy Osmani 关于代理代码质量的文章有力地论证了，软件质量越来越取决于代理周围的约束。

这些约束应贯穿整个交付过程。

类型系统和编译器拒绝无效状态。
单元测试、集成测试、属性测试和变异测试挑战行为。
代码检查器和安全扫描器捕获已知类别的故障。
沙箱将故障限制在可控范围内。
CI 和策略关卡强制执行硬性要求。

这些检查能快速捕获可衡量的故障，并减少到达审查者的工作量。

其他问题则跨越系统的更大部分。测试只能报告一个断言是否通过。审查一个认证变更，可能需要理解它如何影响库存搜索、聊天、数据存储以及差异之外的一个 API 客户端。代码检查器可以强制执行既定的架构规则。决定该规则是否适合新的产品需求，需要产品和工程上下文。

自动化检查提供证据，而审查流程将这些证据与变更的后果联系起来。

审查深度应跟随出错成本

基于风险的审查为团队提供了指导人工注意力的具体规则。

随着代理产生更多变更，审查者通过监督更广泛的流程，并对那些错误代价最高的决策负直接责任，从而获得更大的杠杆作用。

一个范围狭窄的依赖更新，如果覆盖确定，可能只需要很少的人工关注。而涉及认证、计费、数据保留或公共 API 的变更值得更深入的审查。变更的作者可以是开发者或代理。变更的范围和后果决定了审查路径。

在关于代理代码审查的文章中，Osmani 将这一过程描述为把人从“在循环内”移到“在循环上”。人们监督系统、抽样其输出，并将注意力集中在那些犯错代价高昂的决策上。

Horthy 从另一个方向得出了类似的结论。人的判断更早地进入产品审查、架构和程序设计。实现以更小的垂直切片推进，这些切片更容易验证和调整方向。

独立审查让团队获得基于代码库上下文和组织规则的第二次阅读。它可以浮现证据并识别出值得更密切注意的工作，同时将发布决定留给团队。

审查者需要一条从系统视图到代码的路径

常规摘要压缩了一项变更，但仅靠压缩不足以完成审查。审查者需要一种方法来验证摘要的内容。

审查者需要两个相互关联的视图：
一个系统视图，展示变更的意图、行为、依赖、风险和潜在影响。
一个代码视图，展示支持说明的相关发现、文件和确切代码行。

系统视图让审查者免于从文件树中重构变更。两个视图之间的可追溯性让他们可以对照实现来检验每一个声明。

审查者可以从一个确切的代码发现移动到更广泛的系统上下文，然后再返回，从而同时理解证据和影响范围。

一个大型拉取请求展示了这种审查模型在实践中需要什么。下面的 Change Stack 和 Blast Radius 演示展示了审查者如何从变更范围开始，直接进入支持代码。

观看 Change Stack 和 Blast Radius 演示：

Change Stack 和 Blast Radius 的实际应用

该演示从一个涉及约 35 个文件、2000 行代码的拉取请求开始。原始 diff 包含 FastAPI 后端、身份验证、SQLite 和 Qdrant 存储、AI 图像处理、聊天、测试和审查配置。

Change Stack 将文件级 diff 重新组织成语义层，涵盖 API 契约和启动、身份验证和持久化、AI 处理和搜索、聊天和 API 验证、审查控制。这些层为审查者提供了一种基于行为和依赖而非按字母顺序排列的文件的阅读顺序。

审查者可以选择数据库初始化摘要，跳转到插入具有明文凭据和配置数据的默认管理员的代码，并检查附加到该范围的关键发现。

Blast Radius 将视图扩展到受影响的系统。在演示中，它展示了五个直接变更的区域，并识别出一个可能受影响的前端 API 客户端，尽管拉取请求没有改动该客户端。

一个涉及不可信用户名的安全发现，可以从 FastAPI 入口点开始，经过身份验证和持久化，一直追踪到 SQLite、Qdrant、搜索和聊天。

该图让审查者了解变更如何在系统中传播。审查者可以对照代码检验该模型，并决定该实现是否合适。

审查时间可以用于测试所提议的账户、质疑假设，并判断设计是否合理。

一个团队可以信任的审查关卡

当审查关卡的深度与变更的后果相匹配时，它才能赢得信任。常规工作可以凭借自动化证据快速推进，而影响重大的变更需要足够的上下文和可追溯性，让审查者了解其中利害，并检查每个声明背后的代码。

随着代理承担更多实现工作，团队需要在变更发布之前有一个独立的视图。审查者应该能够看到其影响可能触及多远，并沿着每条发现回到他们可以检查的代码。

然后，团队可以基于这些证据做出最终决定，而不是花费审查时间从头重构变更。