--- title: "Review agent changes with independent reviewers" description: "Give reviewers a separate view of the change and feed verified findings back into a fix-and-review loop." url: https://starsling.dev/ci-playbooks/techniques/independent-agent-review canonicalUrl: https://starsling.dev/ci-playbooks/techniques/independent-agent-review --- # Review agent changes with independent reviewers Give reviewers a separate view of the change and feed verified findings back into a fix-and-review loop. ## How to choose an approach Compare the examples by repository setup, prerequisites, and risks before adopting one. Each company implemented this in its own environment; measure each change against your own baseline. - **[Anthropic](https://starsling.dev/ci-playbooks/anthropic#adversarial-review-agents)**: Use it when Agents open pull requests that one bot or one human reviews, and the agent that wrote a change also judges it. Check before adopting: A person still decides what merges. Cap the reviewers per pull request, keep the existing required checks, and read what the reviewers catch before making the job required. Adapted for GitHub Actions; compare the original system with yours. - **[DoorDash](https://starsling.dev/ci-playbooks/doordash#staged-review-agent)**: Use it when Pull requests wait on human review for issues an automated reviewer could flag first, or an existing bot reviewer posts comments authors skim past. Check before adopting: Precision keeps authors reading: post only verified findings anchored to a changed line, and measure acceptance alongside a replay benchmark. Adapted for GitHub Actions; compare the original system with yours. - **[OpenAI](https://starsling.dev/ci-playbooks/openai#agent-review-loop)**: Use it when Agent-authored pull requests wait on human review as the slowest step in the merge path. Check before adopting: The team built this around its own tooling and a repository shaped for agents. Start with changes where an agent reviewer already catches what a person would, and keep human review for decisions that need judgment. ## Apply this technique ````text Evaluate and apply this CI technique to my repository: Review agent changes with independent reviewers. Give reviewers a separate view of the change and feed verified findings back into a fix-and-review loop. Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/independent-agent-review.md Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence. Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured. Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo. Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES. Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch. Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge. ```` ## How companies used this technique Read what each company changed and follow the original sources. ### Anthropic: Review each agent change with reviewers that see only the diff **Translated to GitHub Actions** - What Anthropic built: Bun's Rust port ran about 50 dynamic workflows in Claude Code, with an implementer, two or more adversarial reviewers and a fixer in each loop. - Your GitHub Actions version: A review job that reads each agent pull request with a fresh agent and posts findings the author's agent addresses before merge. Bun's Rust port ran as about 50 dynamic workflows in Claude Code. In each loop, one implementer wrote the change, two or more adversarial reviewers tried to find reasons it did not work, and a fixer applied their feedback. The implementer never reviewed and the reviewers never implemented. Each reviewer was a second Claude in its own context window that received the diff, told to find the way the change is wrong. In GitHub Actions, the same split is a review job that reads each agent pull request with a fresh agent and posts findings the author's agent addresses before merge. Evidence: Company-reported result or observation Every line of code was reviewed by two separate adversarial reviewers (also Claude) and went through a round of fixes before committing. ([Source](https://bun.sh/blog/bun-in-rust)) Use it when: Agents open pull requests that one bot or one human reviews, and the agent that wrote a change also judges it. Before applying it: A person still decides what merges. Cap the reviewers per pull request, keep the existing required checks, and read what the reviewers catch before making the job required. GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation. [Read more in the Anthropic playbook](https://starsling.dev/ci-playbooks/anthropic#adversarial-review-agents) [Primary source](https://bun.sh/blog/bun-in-rust) ### DoorDash: Review pull requests with a scout and deep reviewers **Translated to GitHub Actions** - What DoorDash built: DoorDash's code review agent runs a lead scout, two deep reviewers and a disprove-it pass, and many reviews fire automatically when a pull request opens across 56 repositories. - Your GitHub Actions version: A workflow that runs a review agent on every pull request, reads the diff with a full clone and posts only the findings that survive a disprove-it pass. In a typical week, DoorDash's code review agent reviews more than 10,000 pull requests across 56 onboarded repositories, and many reviews fire automatically when a pull request opens. A lead scout reads the diff and lists investigation leads; two deep reviewers verify the leads with a full clone of the repository, and a disprove-it pass keeps only the findings that survive scrutiny. Review rules come from per-domain profiles mined from AGENTS.md files, past reviews, design decisions and incidents, and routing loads only the profiles a change touches. Findings post about seven minutes after a pull request opens, at about $3 per review, and 60.2% of settled high and critical findings lead to a code change before merge. DashBench, DoorDash's replay benchmark of historical pull requests, tests each change to the reviewer before it ships. Evidence: Company-reported result or observation A review costs roughly $3 on average today. ([Source](https://careersatdoordash.com/blog/doordash-built-an-ai-code-reviewer-engineers-actually-listen-to/)) 60.2% of settled high and critical findings result in the engineer changing code before merge (n=2,256) ([Source](https://careersatdoordash.com/blog/doordash-built-an-ai-code-reviewer-engineers-actually-listen-to/)) Use it when: Pull requests wait on human review for issues an automated reviewer could flag first, or an existing bot reviewer posts comments authors skim past. Before applying it: Precision keeps authors reading: post only verified findings anchored to a changed line, and measure acceptance alongside a replay benchmark. GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation. [Read more in the DoorDash playbook](https://starsling.dev/ci-playbooks/doordash#staged-review-agent) [Primary source](https://careersatdoordash.com/blog/doordash-built-an-ai-code-reviewer-engineers-actually-listen-to/) ### OpenAI: Let agents review agents until the reviewers are satisfied On OpenAI's agent-first product team, the author agent reviews its own change locally, requests further agent reviews locally and in the cloud, answers every human or agent comment, and repeats until every agent reviewer is satisfied. Humans may review a pull request and are not required to, and almost all review effort moved to agents reviewing agents. Across the five-month agent-first project, the post reports roughly 1,500 pull requests and an average throughput of 3.5 PRs per engineer per day. Evidence: Documented technique Use it when: Agent-authored pull requests wait on human review as the slowest step in the merge path. Before applying it: The team built this around its own tooling and a repository shaped for agents. Start with changes where an agent reviewer already catches what a person would, and keep human review for decisions that need judgment. [Read more in the OpenAI playbook](https://starsling.dev/ci-playbooks/openai#agent-review-loop) [Primary source](https://openai.com/index/harness-engineering/) ## CI optimization is continuous work. Apply this technique yourself, or use StarSling Runners for faster GitHub Actions and optional agent-driven optimization PRs, which teams on eligible paid plans can turn on. [Get self-improving CI](https://starsling.dev/products/runners) ## Company Playbooks ### [Anthropic](https://starsling.dev/ci-playbooks/anthropic) Run only affected tests ### [DoorDash](https://starsling.dev/ci-playbooks/doordash) Run build and test in parallel, sharded across CI agents ### [Linear](https://starsling.dev/ci-playbooks/linear) Benchmark the same job on faster hardware ### [Mastra](https://starsling.dev/ci-playbooks/mastra) StarSling runners for the slowest test workflow ### [OpenAI](https://starsling.dev/ci-playbooks/openai) Rank CI fixes by the minutes they save ### [Ramp](https://starsling.dev/ci-playbooks/ramp) Move a CPU-bound test suite to a faster CPU ### [Shopify](https://starsling.dev/ci-playbooks/shopify) Let an agent iterate against one CI metric ### [Spotify](https://starsling.dev/ci-playbooks/spotify) Build arm64 on native arm64 runners ### [Stripe](https://starsling.dev/ci-playbooks/stripe) Run only the tests a change can reach ### [Uber](https://starsling.dev/ci-playbooks/uber) Build the merge-queue speculations most likely to be needed ## Related guides Implementation guides for this technique. ### [AI code review in GitHub Actions](https://starsling.dev/ai-code-review-github-actions) How AI code review works on GitHub pull requests: where it fits beside tests and lint, choosing a model, giving it context and defining reviewers.