--- title: "Run an agent review on pull requests" description: "Use an agent to review changes and surface findings before human approval, retaining the team’s review and quality controls." url: https://starsling.dev/ci-playbooks/techniques/automated-pr-review canonicalUrl: https://starsling.dev/ci-playbooks/techniques/automated-pr-review --- # Run an agent review on pull requests Use an agent to review changes and surface findings before human approval, retaining the team’s review and quality controls. ## 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. - **[Linear](https://starsling.dev/ci-playbooks/linear#agent-reviews-every-pr)**: Use it when Pull requests wait for human review, and most of a reviewer's time goes to bugs and logic that an automated reviewer can check. Check before adopting: The human approval stays the merge gate, the agent's review is the first read, and the required checks stay as they are. - **[Ramp](https://starsling.dev/ci-playbooks/ramp#review-bot-on-agent)**: Use it when Reviewers repeat the same checks on many pull requests, and the repository can run an agent on each pull request. Check before adopting: The bot reviews with the memories and skill files it is given, so keep them current as the team learns what to look for. Adapted for GitHub Actions; compare the original system with yours. - **[Uber](https://starsling.dev/ci-playbooks/uber#ai-review-in-ci)**: Use it when Reviewers are overloaded by the volume of code from AI-assisted development, and a human first pass is the slowest part of landing a change. Check before adopting: Precision keeps authors reading. Tune thresholds per assistant and language from developer ratings, and prune comment categories that attract poor ratings. Adapted for GitHub Actions; compare the original system with yours. ## Apply this technique ````text Evaluate and apply this CI technique to my repository: Run an agent review on pull requests. Use an agent to review changes and surface findings before human approval, retaining the team’s review and quality controls. Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/automated-pr-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. ### Linear: Have a coding agent review every pull request before a human approves At Linear, a coding agent takes a crack at reviewing every pull request, and Linear has leaned on Codex for this for the past couple of months. A human engineer then makes the final approval. With agents covering most line-by-line checks, reviewers spend their time on whether the change fits the system and solves the problem the customer reported. Evidence: Documented technique Use it when: Pull requests wait for human review, and most of a reviewer's time goes to bugs and logic that an automated reviewer can check. Before applying it: The human approval stays the merge gate, the agent's review is the first read, and the required checks stay as they are. [Read more in the Linear playbook](https://starsling.dev/ci-playbooks/linear#agent-reviews-every-pr) [Primary source](https://linear.app/now/how-we-use-linear-agent-at-linear) ### Ramp: Build the review bot on the same agent that writes the code **Translated to GitHub Actions** - What Ramp built: Ramp's code review bot is built on Inspect, its background agents API that also writes pull requests. - Your GitHub Actions version: A review agent that reads each pull request with memories of what your team wants reviewed and skill files written by the teams that own the code. In an August 2026 talk, Ramp's engineers described their own code review bot, built on Inspect, the background agents API that also writes pull requests. The bot pulls from memories of things Ramp especially wants reviewed, and certain teams write their own skill files that look for certain things, which codifies what they have built up over the years. Evidence: Company-reported result or observation 2026: Ramp's review bot runs on the same background agents API as its coding agent, and teams write skill files for what it checks. ([Source](https://claude.com/customers/ramp-boris-office-hours)) Use it when: Reviewers repeat the same checks on many pull requests, and the repository can run an agent on each pull request. Before applying it: The bot reviews with the memories and skill files it is given, so keep them current as the team learns what to look for. GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation. [Read more in the Ramp playbook](https://starsling.dev/ci-playbooks/ramp#review-bot-on-agent) [Primary source](https://claude.com/customers/ramp-boris-office-hours) ### Uber: Run an AI reviewer on every commit and post the comments that pass a quality filter **Translated to GitHub Actions** - What Uber built: Uber's uReview reviews every commit across its six monorepos, with quality and category filters on its comments. - Your GitHub Actions version: An AI review job on every commit that posts only the comments that pass a quality filter. Uber's uReview reviews every commit as part of CI across its six monorepos. It breaks review into comment generation by specialized assistants, quality filtering with a confidence score for each comment, merging of near-duplicate comments, and a category filter that suppresses comment types with low developer value. Comments post inline with Useful and Not Useful ratings, and Uber re-runs the reviewer five times on the final commit to check whether each comment was addressed. Evidence: Company-reported result or observation Uber reports that engineers who interact with uReview mark 75% of its comments as useful, and over 65% of its posted comments are addressed. ([Source](https://www.uber.com/us/en/blog/ureview/)) Uber estimates approximately 1,500 hours saved weekly, equivalent to nearly 39 developer years annually. ([Source](https://www.uber.com/us/en/blog/ureview/)) Use it when: Reviewers are overloaded by the volume of code from AI-assisted development, and a human first pass is the slowest part of landing a change. Before applying it: Precision keeps authors reading. Tune thresholds per assistant and language from developer ratings, and prune comment categories that attract poor ratings. GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation. [Read more in the Uber playbook](https://starsling.dev/ci-playbooks/uber#ai-review-in-ci) [Primary source](https://www.uber.com/us/en/blog/ureview/) ## 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. ### [How to run automated code review in GitHub Actions](https://starsling.dev/automated-code-review) How to run automated code review as a GitHub Actions job using your own model, repo-native review skills and team-defined reviewers.