# The software factory needs a faster review loop: further optimizing the path from PR to merge
**作者**: Augment Code
**日期**: 2026-08-13T19:16:14.000Z
**来源**: [https://x.com/augmentcode/status/2087981573551583307](https://x.com/augmentcode/status/2087981573551583307)
---
## TL;DR
In an AI-native engineering organization, generating code is no longer the slowest part of shipping software. Review, verification, repair, and human decision-making become the bottlenecks, and ultimately define how much faster the organization can move. Standalone AI coding tools may deliver a 30–40% speedup, but achieving a step-change in throughput requires optimizing everything that happens after the code is written.
In our [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos), we described a review system that helped our engineering organization increase code output by 3× while reducing median merge time and maintaining quality. We have since expanded that system beyond review into the full PR-to-merge loop: specialized agents handle mechanical work, verify correctness, and address feedback, while humans provide judgment and knowledge transfer, and always own the final merge decision.
This is [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it): improving the complete system that turns generated code into a verified, understood, merge-ready change rather than optimizing any single tool in isolation.
## Why an “AI code review tool” is not enough
A conventional AI code review tool like CodeRabbit or Greptile analyzes a diff and posts comments. Useful, but review is only one step. The real drag is the chain of human handoffs:
- Reconstructing intent and architecture.
- Triaging low-risk changes.
- Applying review feedback.
- Fixing CI failures and merge conflicts.
- Verifying feature behavior end to end.
- Gathering enough evidence to ship safely.
- Re-reviewing after each push.
A PR-to-merge loop keeps specialized Experts working through review, repair, verification, and decision support until a human can merge with confidence. Each Expert in the fleet owns one or more of these handoffs, turning a fragmented sequence of manual tasks into a coordinated system. The goal is to optimize the entire loop: human time, cost, quality, and merge latency, not time to first comment.
## 1. Overview: engineering the complete loop
An AI-native code review loop: agents find and fix bugs, verify changes, and evaluate policy; humans resolve judgment calls and make the final merge decision.
Our original system separated risk analysis (Risk Analyzer), line-by-line correctness review (Deep Reviewer), and human-guided design review (Pair Review). The expanded system adds repair, runtime verification, and expanded auto-approval, reducing the human bottleneck further. For an overview of Cosmos and its configurable Experts, see our [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos).
## Experts and capabilities, not one general-purpose reviewer
| Expert or capability | Responsibility |
| --- | --- |
| Risk Analyzer | Classifies risk and applies auto-approval policy |
| Deep Reviewer | Performs exhaustive, line-by-line analysis for objective correctness defects |
| Pair Reviewer | Reconstructs intent, architecture, product context, and tradeoffs |
| Memory Manager | Remember feedback from the PR and Pair Review sessions to improve future runs |
| Verifier <sup>NEW</sup> | Exercises affected behavior end-to-end in a test environment (Verifier blog) |
| PR Fixer <sup>NEW</sup> | Repairs review findings, CI failures, and merge conflicts |
| Review Dashboard <sup>NEW</sup> | Observes and summarizes expert state |
| cosmos approve <sup>NEW</sup> | Evaluates a configurable approval policy on author request |
The distinction between Deep Reviewer and Pair Reviewer is particularly important:
- Deep Reviewer asks: “Is there an objective bug in this implementation?” It runs autonomously and checks the PR against AGENTS.md or CLAUDE.md guidelines.
- Pair Reviewer asks: “Does this change make sense in the broader system, and which decisions require human judgment?” It runs interactively with the human. The human can also instruct it to monitor the PR after posting review comments and approve on their behalf once those comments are addressed.
The PR Author Expert previously did double duty: writing a PR and fixing review comments, CI failures, and other follow-up work. In the decoupled design, PR Author stops at draft PR creation and PR Fixer takes over. This gives users more control over how fixes run and supports PRs created without PR Author.
The Review Dashboard brings Expert status, reviewed commits, evidence, and available actions into one view.
2. Designing the human-in-the-loop
Human review and verification are becoming the scarce resources in AI-native engineering organizations. The goal is not to remove humans indiscriminately. It is to spend human attention only where it has the highest leverage.
Why humans remain in the loop
Agents can perform a large share of mechanical analysis and execution, but they do not have complete business and organizational context. Humans remain essential for:
- Judgment calls: Should this logic live in the frontend or backend? Is this tradeoff appropriate for the product? Is this risk acceptable now?
- Knowledge transfer: Review is one of the ways engineers build a shared understanding of architecture and product behavior.
- Ownership and accountability: Agents do not own the software after it ships; human developers and engineering organizations do. A human therefore always makes the final decision and clicks Merge. None of these experts merges a PR.
The design target is therefore:
> Agents do the mechanical work. Humans make the consequential decisions.
## The author and reviewer workflow: before and after
| Traditional workflow | Human-in-the-loop workflow |
| --- | --- |
| Manually triage every PR and identify low-risk changes | Let Risk Analyzer classify risk and apply the organization’s auto-approval policy |
| Read the PR line by line | Trust Deep Reviewer to perform exhaustive line-by-line analysis |
| Reconstruct context, intent, and architecture from the diff | Use Pair Reviewer’s briefing to understand the change and identify judgment calls |
| Manually deploy and exercise the feature | Inspect Verifier evidence: screenshots, logs, traces, and captured outputs |
| Re-review every fix from scratch | Let Pair Reviewer monitor whether authorized comments were addressed |
| Triage feedback, implement fixes, repair CI, resolve conflicts, and explain each change | Let PR Fixer—or PR Author when it owns the full lifecycle—handle the mechanical follow-up and report what changed |
| Search across comments and checks for current state | Use the Review Dashboard as the entry point |
| Manually gather review, ownership, and verification evidence before requesting approval | Invoke cosmos approve to evaluate the configured approval policy against current evidence |
| Decide whether to merge | Still decide whether to merge |
## The economic intuition of using multiple experts
Tokens that measurably reduce human time in the review bottleneck are worth the investment. When Experts turn hours of review and PR shepherding into minutes, they free scarce engineering judgment for the consequential decisions only humans can make, while also helping features reach customers faster.
One of Augment’s core commitments is helping organizations optimize costs. That means optimizing total cost per task: human effort plus token cost. It does not mean minimizing token usage at the expense of successful outcomes. A single Expert burdened with six responsibilities will do a substandard job of each and require more human intervention. Six dedicated Experts can each focus on a different part of PR review, produce higher-quality review artifacts, and drive more of the process autonomously.
## 3. Cost and quality: optimize cost per successful outcome
The cheapest model by token price is often a false economy. A missed defect, bad repair, or retry can cost more than getting the task right once. We benchmark representative work and choose the lowest-cost model that clears each Expert’s quality bar, the same [cost-per-success principle](https://www.augmentcode.com/blog/eight-models-in-eight-weeks-gpt-5-6-sol-is-now-our-default) we use across Cosmos.
Today, we use GPT-5.6 Sol for judgment-heavy work such as Risk analysis, Deep and Pair review, and code repair. Bounded, mechanically verifiable tasks such as dashboard aggregation and merge-conflict monitoring run on GPT-5.6 Luna. Models with longer cache TTLs also favor long-running agents because cached input is typically discounted at 90%.
## 4. A configurable approval path with cosmos approve
The Risk Analyzer has always been able to approve intrinsically low-risk changes under a conservative policy. We now support a second, disabled-by-default approval mode for other changes.
The PR author can comment cosmos approve to request an evaluation against an approval policy. A human still owns and performs the final merge.
Organizations define their own approval policy. Our internal policy checks:
1. Ownership: The requester is the PR author, and the author is an effective CODEOWNER for every modified file.
2. Current-head review: No unresolved Deep Reviewer findings, Pair Reviewer blockers, or unaddressed human comments.
3. No contradictory runtime evidence: The Verifier has not reported an unaddressed defect against the current commit.
## 5. Customizability is part of the architecture
We designed the fleet so teams can customize the loop with Cosmos Advisor.
- Fleet: Add, remove, or replace experts; choose the model and prompt for each responsibility.
- Operation: Configure triggers, tools, integrations, and verification environments.
- Control: Restrict who can invoke actions and which credentials, repositories, and systems each expert can access.
- Policy: Define approval rules, required checks, CODEOWNER requirements, and acceptable evidence.
## The operating model for AI-native PR Review
The lesson from our first version was that code review could not scale by asking humans to read AI-generated code faster. The lesson from this version is broader: no individual review agent can optimize the full path to merge.
A high-functioning PR-to-merge loop needs:
- Agent Specialization: Separate risk, correctness, design judgment, runtime verification, and repair.
- Minimize human checkpoints: Pull humans in for consequential judgment and knowledge transfer only.
- Evidence: Give reviewers inspectable proof rather than unsupported verdicts.
- Repair loops: Let findings flow back into implementation without waiting for manual intervention.
- Observability: Make the state of the entire fleet legible in one place.
- Cost discipline: Use the cheapest model that clears the quality bar for each responsibility.
- Configurability: Customize the loop to each organization’s unique requirements.
- Human ownership: Keep the final merge decision with the people accountable for the software.
This is [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it) applied to the PR lifecycle: optimize the system that produces a verified, understood, merge-ready change, not the amount of output produced by any single agent.
## Build your own PR-to-merge loop
Cosmos gives engineering teams the shared context, runtime controls, integrations, and human checkpoints to run agents across review, verification, repair, and the rest of the software lifecycle.
[Try Cosmos](https://cosmos.augmentcode.com/?utm_source=augment_blog&utm_medium=content&utm_content=pr_to_merge_loop)
## 相关链接
- [Augment Code](https://x.com/augmentcode)
- [@augmentcode](https://x.com/augmentcode)
- [87K](https://x.com/augmentcode/status/2087981573551583307/analytics)
- [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)
- [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)
- [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)
- [Verifier blog](https://www.augmentcode.com/blog/the-bottleneck-moved-to-verification-so-we-automated-that-too)
- [cost-per-success principle](https://www.augmentcode.com/blog/eight-models-in-eight-weeks-gpt-5-6-sol-is-now-our-default)
- [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)
- [Try Cosmos](https://cosmos.augmentcode.com/?utm_source=augment_blog&utm_medium=content&utm_content=pr_to_merge_loop)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:16 AM · Aug 14, 2026](https://x.com/augmentcode/status/2087981573551583307)
- [87.6K Views](https://x.com/augmentcode/status/2087981573551583307/analytics)
---
*导出时间: 2026/8/14 09:32:38*
---
## 中文翻译
# 软件工厂需要更快的评审循环：进一步优化从 PR 到合并的路径
**作者**: Augment Code
**日期**: 2026-08-13T19:16:14.000Z
**来源**: [https://x.com/augmentcode/status/2087981573551583307](https://x.com/augmentcode/status/2087981573551583307)
---
## TL;DR
在 AI 原生的工程组织中，生成代码已不再是交付软件最慢的环节。评审、验证、修复和人工决策成为瓶颈，并最终决定了组织能提速多少。独立的 AI 编程工具可能带来 30-40% 的加速，但实现吞吐量的阶跃式提升，需要优化代码编写之后的所有环节。
在我们[上一篇关于使用 Cosmos 解决代码评审的文章](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)中，我们描述了一个评审系统，它帮助我们的工程组织将代码产出提升了 3 倍，同时降低了合并时间中位数并保持了质量。此后，我们将该系统从评审扩展到完整的 PR 到合并循环：专门的智能体处理机械性工作、验证正确性并处理反馈，而人类则提供判断力和知识传递，并始终拥有最终的合并决策权。
这就是[循环工程](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)：优化将生成的代码转变为经过验证、被理解、可随时合并的变更的完整系统，而不是孤立地优化任何单一工具。
## 为什么“AI 代码评审工具”还不够
像 CodeRabbit 或 Greptile 这样的传统 AI 代码评审工具会分析 diff 并发表评论。这很有用，但评审只是其中一个步骤。真正的阻力在于一系列人工交接环节：
- 重建意图和架构。
- 对低风险变更进行分类。
- 应用评审反馈。
- 修复 CI 失败和合并冲突。
- 端到端验证功能行为。
- 收集足够的证据以安全发布。
- 每次推送后重新评审。
PR 到合并循环让专门的智能体持续处理评审、修复、验证和决策支持，直到人类能够有信心地合并。智能体团队中的每个智能体负责一个或多个这些交接环节，将零散的手动任务序列转变为协调的系统。目标是优化整个循环：人力时间、成本、质量和合并延迟，而不仅仅是首次评论的时间。
## 1. 概述：工程化完整的循环
一个 AI 原生的代码评审循环：智能体发现并修复错误、验证变更、评估策略；人类解决需要判断力的问题并做出最终合并决策。
我们最初的系统将风险分析（Risk Analyzer）、逐行正确性评审（Deep Reviewer）和人工引导的设计评审（Pair Review）分开。扩展后的系统增加了修复、运行时验证和扩展的自动批准，进一步减少了人工瓶颈。有关 Cosmos 及其可配置智能体的概述，请参阅我们[上一篇关于使用 Cosmos 解决代码评审的文章](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)。
## 智能体和能力，而非一个通用的评审器
| 智能体或能力 | 职责 |
| --- | --- |
| Risk Analyzer | 对风险进行分类并应用自动批准策略 |
| Deep Reviewer | 对客观正确性缺陷进行详尽、逐行的分析 |
| Pair Reviewer | 重建意图、架构、产品上下文和权衡 |
| Memory Manager | 记住 PR 和 Pair Review 会话中的反馈，以改进未来的运行 |
| Verifier <sup>新增</sup> | 在测试环境中端到端地执行受影响的行为（Verifier 博客） |
| PR Fixer <sup>新增</sup> | 修复评审发现的问题、CI 失败和合并冲突 |
| Review Dashboard <sup>新增</sup> | 观察并总结智能体状态 |
| cosmos approve <sup>新增</sup> | 根据作者请求评估可配置的批准策略 |
Deep Reviewer 和 Pair Reviewer 之间的区别尤为重要：
- Deep Reviewer 会问：“这个实现中是否存在客观的错误？”它自主运行，并根据 AGENTS.md 或 CLAUDE.md 指南检查 PR。
- Pair Reviewer 会问：“这个变更在更广泛的系统中是否合理，哪些决策需要人类判断？”它与人类交互式运行。人类还可以指示它在发布评审评论后监控 PR，并在这些评论得到处理后代表他们批准。
PR Author 智能体之前承担双重职责：编写 PR 以及修复评审评论、CI 失败和其他后续工作。在解耦的设计中，PR Author 在创建草稿 PR 后即停止，PR Fixer 接管后续工作。这使用户对修复的运行方式有更多控制权，并支持在没有 PR Author 的情况下创建的 PR。
Review Dashboard 将智能体状态、已评审的提交、证据和可用操作整合到一个视图中。
## 2. 设计人机协同
在 AI 原生的工程组织中，人工评审和验证正成为稀缺资源。目标不是不加区分地移除人类，而是将人类注意力只投入到杠杆作用最大的地方。
### 为什么人类仍留在循环中
智能体可以执行大部分机械性分析和执行工作，但它们不具备完整的业务和组织上下文。人类在以下方面仍然不可或缺：
- **判断性决策**：这个逻辑应该放在前端还是后端？这种权衡对产品是否合适？这个风险现在是否可以接受？
- **知识传递**：评审是工程师建立对架构和产品行为共同理解的途径之一。
- **所有权和问责制**：智能体在软件发布后并不拥有它；人类开发者和工程组织才拥有。因此，最终决策始终由人类做出并点击合并。这些智能体都不会合并 PR。
因此，设计目标是：
> 智能体做机械性工作。人类做重大决策。
## 作者和评审者工作流程：之前与之后
| 传统工作流程 | 人机协同工作流程 |
| --- | --- |
| 手动分类每个 PR 并识别低风险变更 | 让 Risk Analyzer 对风险进行分类并应用组织的自动批准策略 |
| 逐行阅读 PR | 信任 Deep Reviewer 进行详尽的逐行分析 |
| 从 diff 中重建上下文、意图和架构 | 使用 Pair Reviewer 的简报来理解变更并识别需要判断力的决策 |
| 手动部署并测试功能 | 检查 Verifier 的证据：截图、日志、追踪和捕获的输出 |
| 从头重新评审每个修复 | 让 Pair Reviewer 监控授权的评论是否已得到处理 |
| 分类反馈、实施修复、修复 CI、解决冲突并解释每个变更 | 让 PR Fixer——或在其拥有完整生命周期时的 PR Author——处理机械性后续工作并报告变更内容 |
| 在评论和检查中搜索当前状态 | 使用 Review Dashboard 作为入口 |
| 在请求批准前手动收集评审、所有权和验证证据 | 调用 cosmos approve 根据当前证据评估配置的批准策略 |
| 决定是否合并 | 仍然决定是否合并 |
## 使用多个智能体的经济直觉
能够显著减少评审瓶颈中人工时间的 Token 投入是值得的。当智能体将数小时的评审和 PR 管理变成几分钟时，它们释放了稀缺的工程判断力，用于只有人类才能做出的重大决策，同时也帮助功能更快地触达客户。
Augment 的核心承诺之一是帮助组织优化成本。这意味着优化每个任务的总成本：人力加上 Token 成本。这并不意味着以牺牲成功结果为代价来最小化 Token 使用量。一个承担六项职责的单一智能体，每项工作都会做得不合格，并需要更多人工干预。六个专门的智能体可以各自专注于 PR 评审的不同部分，产生更高质量的评审产物，并更自主地推动流程。
## 3. 成本与质量：优化每次成功结果的成本
按 Token 价格计算最便宜的模型往往是一种虚假的经济。一个遗漏的缺陷、一次糟糕的修复或一次重试，其成本可能超过一次性正确完成任务。我们对代表性工作进行基准测试，并为每个智能体选择能通过其质量门槛的最低成本模型，这与我们在 Cosmos 中使用的[每次成功成本原则](https://www.augmentcode.com/blog/eight-models-in-eight-weeks-gpt-5-6-sol-is-now-our-default)相同。
目前，我们在判断密集型工作中使用 GPT-5.6 Sol，例如风险分析、Deep 和 Pair 评审以及代码修复。有边界、可机械验证的任务（如仪表板聚合和合并冲突监控）则在 GPT-5.6 Luna 上运行。缓存 TTL 更长的模型也更有利于长时间运行的智能体，因为缓存的输入通常有 90% 的折扣。
## 4. 使用 cosmos approve 的可配置批准路径
Risk Analyzer 一直能够在保守策略下批准本质上低风险的变更。我们现在为其他变更支持第二种默认关闭的批准模式。
PR 作者可以评论 `cosmos approve` 来请求根据批准策略进行评估。人类仍然拥有并执行最终合并。
组织定义自己的批准策略。我们的内部策略检查：
1. **所有权**：请求者是 PR 作者，且作者是每个修改文件的有效 CODEOWNER。
2. **当前头部评审**：没有未解决的 Deep Reviewer 发现、Pair Reviewer 阻塞项或未处理的人工评论。
3. **无矛盾的运行时证据**：Verifier 未针对当前提交报告未处理的缺陷。
## 5. 可定制性是架构的一部分
我们设计了智能体团队，使团队可以通过 Cosmos Advisor 定制循环。
- **团队**：添加、移除或替换智能体；为每个职责选择模型和提示词。
- **操作**：配置触发器、工具、集成和验证环境。
- **控制**：限制谁可以调用操作，以及每个智能体可以访问哪些凭据、仓库和系统。
- **策略**：定义批准规则、必需检查、CODEOWNER 要求和可接受的证据。
## AI 原生 PR 评审的运营模式
我们从第一版中得到的教训是，代码评审无法通过要求人类更快地阅读 AI 生成的代码来扩展。这一版的教训更为广泛：没有任何单一的评审智能体可以优化通往合并的完整路径。
一个高效的 PR 到合并循环需要：
- **智能体专业化**：将风险、正确性、设计判断、运行时验证和修复分开。
- **最小化人工检查点**：仅在重大判断和知识传递时引入人类。
- **证据**：给评审者提供可检查的证明，而非无根据的结论。
- **修复循环**：让发现的问题回流到实现中，无需等待人工干预。
- **可观测性**：让整个智能体团队的状态在一个地方清晰可见。
- **成本纪律**：为每个职责使用能通过质量门槛的最便宜模型。
- **可配置性**：根据每个组织的独特需求定制循环。
- **人类所有权**：将最终合并决策权保留在对软件负责的人手中。
这就是[循环工程](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)在 PR 生命周期中的应用：优化产生经过验证、被理解、可随时合并的变更的系统，而不是任何单个智能体产生的输出量。
## 构建你自己的 PR 到合并循环
Cosmos 为工程团队提供共享上下文、运行时控制、集成和人工检查点，以便在评审、验证、修复以及软件生命周期的其余部分运行智能体。
[试用 Cosmos](https://cosmos.augmentcode.com/?utm_source=augment_blog&utm_medium=content&utm_content=pr_to_merge_loop)
## 相关链接
- [Augment Code](https://x.com/augmentcode)
- [@augmentcode](https://x.com/augmentcode)
- [87K](https://x.com/augmentcode/status/2087981573551583307/analytics)
- [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)
- [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)
- [previous post about solving code review with Cosmos](https://www.augmentcode.com/blog/solving-code-review-with-cosmos)
- [Verifier blog](https://www.augmentcode.com/blog/the-bottleneck-moved-to-verification-so-we-automated-that-too)
- [cost-per-success principle](https://www.augmentcode.com/blog/eight-models-in-eight-weeks-gpt-5-6-sol-is-now-our-default)
- [loop engineering](https://www.augmentcode.com/blog/what-is-loop-engineering-and-how-are-leading-software-engineering-teams-using-it)
- [Try Cosmos](https://cosmos.augmentcode.com/?utm_source=augment_blog&utm_medium=content&utm_content=pr_to_merge_loop)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:16 AM · Aug 14, 2026](https://x.com/augmentcode/status/2087981573551583307)
- [87.6K Views](https://x.com/augmentcode/status/2087981573551583307/analytics)
---
*导出时间: 2026/8/14 09:32:38* 
