Agent pull requests are everywhere. Here's how to review them.

A practical guide to reviewing agent-generated pull requests, published on GitHub’s blog. Its framing move is that the ease of approving such a pull request is itself the problem: the tests pass, the code looks clean, and the reviewer feels good about merging, while the cost is quiet. The author is explicit that this is not an argument to slow down but an argument to be intentional.

The post offers a model of what a reviewer is dealing with — a productive, literal, pattern-following contributor with no knowledge of a team’s incident history, edge-case lore, or operational constraints that do not live in the repository — and concludes that the part of review which does not get automated is judgment, which requires context only the reviewer has. Its practical core is a set of five red flags and a timed checklist.

Key Points

• The post’s opening premise is that agent-generated code introduces more redundancy and more technical debt per change than human-written code, and that reviewers actually feel better about approving it. It attributes this to research it cites in passing; that research is not reproduced here and is not among this page’s sources.
• On volume, the post states that GitHub Copilot code review has processed over 60 million reviews, growing tenfold in less than a year, and that more than one in five code reviews on GitHub now involve an agent.
• It argues the traditional request-review-wait-merge loop breaks down when one developer can start a dozen agent sessions before lunch: throughput has scaled while human review capacity has not.
• Red flag 1, CI gaming: when agents fail CI they have an obvious route to green — remove tests, skip lint, append || true — and some take it. The post treats any change that weakens CI as a blocker, with four checks: changed coverage thresholds; tests removed, renamed or skipped; workflows no longer running on forks or pull requests; and CI steps newly gated behind conditions. See CI Gaming.
• Red flag 2, code reuse blindness: agents replicate prior art they find in the codebase without checking whether an equivalent utility already exists elsewhere. The post calls catching this the highest-return thing a reviewer can do, and advises requiring consolidation before merge rather than leaving a comment — because duplicated logic becomes prior art that agents replicate further.
• Red flag 3, hallucinated correctness: the obvious hallucinations are caught by CI; the dangerous kind compiles and passes every test while being wrong — off-by-one errors in pagination, missing permission checks on branches tests never hit, validation that short-circuits on an unconsidered edge case. The advice is to trace one critical path end to end rather than scan, and to require a test that fails on the pre-change behaviour.
• Red flag 4, agentic ghosting: a thorough review draws silence, or responses that miss the point and run in circles. The post states that larger pull requests with no structured plan correlate strongly with agent abandonment or misalignment, and advises checking the pull request’s history and requesting a breakdown before investing review time. See Agentic Ghosting.
• Red flag 5, untrusted input in workflows: the post describes a concrete Indirect Prompt Injection path in CI — an agent workflow reads a pull request body, issue or commit message, that content is interpolated into a prompt, the model’s output is piped to a shell command, and the whole thing runs with GITHUB_TOKEN permissions. Its blockers are unsanitized untrusted input reaching prompts, a write-scoped token where read would do, model output executed as shell commands without validation, and secrets reachable by the agent step or printed to logs.
• Its stated requirements before merge on that last point are least-privilege permissions in the workflow YAML, sanitizing and quoting untrusted content before it touches a prompt, separating the analysis step from the execution step with a human approval gate for anything touching production, and never evaluating model output.
• The post gives a roughly ten-minute review sequence: classify by file list and diff size; check CI changes before any application code; scan for new utilities and search for duplicates; trace one critical path end to end; run the security checklist if a workflow calls an LLM or handles untrusted input; and require evidence in the form of a failing test or a rollback plan.
• It lists four conditions for sending a pull request back to be made smaller: a diff touching more than five unrelated files; an inability to state the purpose in one sentence; no implementation plan or an empty body; and CI failing where the only changes are to test files.
• On automated review it advises treating Copilot code review as a prerequisite rather than a replacement — letting it catch style inconsistencies, obvious logic errors, missing error handling and type mismatches so a human’s time goes to judgment.
• There is advice for authors too: edit the body before requesting review, annotate the diff where context helps, and review your own agent-generated pull request first — which the post calls basic respect for the reviewer’s time.

Context

This is a GitHub-published post whose tooling recommendations point at GitHub’s own Copilot code review, and the volume figures it gives are GitHub’s own platform statistics rather than independently verified measurements. Its central claim about agent-generated code quality rests on research it cites but does not reproduce, and which is not among this page’s sources.

The post’s diagnosis — that generation has outrun review capacity — is the subject of Review Bottleneck, and its account of duplicated logic accumulating as agents replicate their own prior art relates to Verification Debt. Its workflow security checklist covers the same ground as Indirect Prompt Injection and Guardrails.