This isn\u2019t an argument to slow down. It\u2019s an argument to be intentional. There\u2019s a difference.<\/p>\n
Agent pull requests are already saturating review bandwidth<\/p>\n
The volume is already staggering. GitHub Copilot code review has processed over 60 million reviews, growing 10x in less than a year. More than one in five code reviews on GitHub now involve an agent. That\u2019s just the automated review pass. The pull request themselves are multiplying faster than reviewers can handle.<\/p>\n
The traditional loop\u2014request review, wait for code owner, merge\u2014breaks down when one developer can kick off a dozen agent sessions before lunch. Throughput has scaled exponentially. Human review capacity hasn\u2019t. The gap is widening.<\/p>\n
You\u2019re going to review agent pull requests. The question is whether you\u2019ll catch what matters when you do.<\/p>\n
Who (or what) actually wrote this pull request<\/p>\n
Before you look at a single line of diff, you need a model for what you\u2019re reviewing.<\/p>\n
A coding agent is a productive, literal, pattern-following contributor with zero context about your incident history, your team\u2019s edge case lore, or the operational constraints that don\u2019t live in the repository. It will produce code that looks complete. But that \u201clooks complete\u201d failure mode is dangerous.<\/p>\n
You\u2019re the one who carries that context. That\u2019s not a burden. It\u2019s the actual job. The part of review that doesn\u2019t get automated is judgment, and judgment requires context only you have.<\/p>\n
One note for authors<\/p>\n
If you\u2019re opening an agent-generated pull request, edit body before you request review. Agents love verbosity. They describe what\u2019s better explored through the code itself. Annotate the diff where context is helpful. And review it yourself before tagging others, not just to check correctness, but to signal that you\u2019ve validated the agent captured your intent.<\/p>\n
Reviewing your own pull request isn\u2019t optional when agents are involved. It\u2019s basic respect for your reviewer\u2019s time.<\/p>\n
Now, back to reviewers. The pull request lands in your queue. The author did their part. Here\u2019s what to watch for.<\/p>\n
Red flags to watch for<\/p>\n
1. CI gaming<\/p>\n
Agents fail CI. When they do, they have an obvious path to get tests passing: remove the tests, skip the lint step, add || true to test commands. Some agents take it.<\/p>\n
Any change that weakens CI is a blocker. Full stop. Before approving any agent pull request, check:<\/p>\n
Did coverage thresholds change?<\/p>\n
Were any tests removed, renamed, or marked as skipped?<\/p>\n
Did the workflow stop running on forks or pull requests?<\/p>\n
Are any CI steps now gated behind conditions they weren\u2019t before?<\/p>\n
Yes, to any of those means you need an explicit justification before you continue.<\/p>\n
2. Code reuse blindness<\/p>\n
This is the highest-ROI thing you can do as a reviewer. Agents look for prior art. They\u2019ll find a pattern in the codebase and replicate it, often without checking whether a utility that already does the same thing exists somewhere else. The symptoms: new utility functions that duplicate existing ones with slightly different names, validation logic reimplemented in multiple places, middleware written from scratch that already lives in a shared module, helpers that are \u201calmost the same\u201d but with different names.<\/p>\n
The agent\u2019s local context doesn\u2019t include the full picture of what exists across your repository. You do.<\/p>\n
For every new helper or utility in an agent pull request, do a quick search. If you find an equivalent, don\u2019t leave a comment. Require consolidation before merge. The cost of leaving duplicated logic is that agents will find it as prior art and replicate it further.<\/p>\n
\ud83d\udca1Pro tip: Require justification for adding new utilities in agent pull requests above a size threshold. This catches the duplication problem early.<\/p>\n
3. Hallucinated correctness<\/p>\n
The obvious hallucination (calling an API that doesn\u2019t exist, referencing a variable out of scope) gets caught in CI. The dangerous one is subtler: code that compiles, passes every test, and is wrong.<\/p>\n
Off-by-one errors in pagination. Missing permission checks on a branch that\u2019s never hit in tests. Validation that short-circuits under an edge case the agent never considered. Wrong behavior under a race condition that only surfaces at scale.<\/p>\n
Trace it, don\u2019t just scan it. Pick the most critical path in the diff. Follow it from input through every transform to output. Check boundary conditions (zero, max, empty), missing validation on external values, permission checks on every branch, and surprising conditional logic.<\/p>\n
Require a new test that fails on the pre-change behavior. If the agent can\u2019t write a test that would have caught the bug it claims to fix, the fix is incomplete or the understanding is wrong.<\/p>\n
4. Agentic ghosting<\/p>\n
You leave a thorough review. You explain the issue, provide context, suggest a direction. The pull request goes quiet. Or the agent responds and misses the point entirely and runs in circles. You invest another round. Still nothing useful.<\/p>\n
Larger pull requests with no structured plan correlate strongly with agent abandonment or misalignment. The larger and less scoped the pull request, the more likely you\u2019re going to sink review time into something that goes nowhere.<\/p>\n
Before you invest deep review on a large agent pull request check the pull request history. Has it been responsive in previous rounds? Does it have a clear implementation plan, or did the agent just start writing code?<\/p>\n
If there\u2019s no plan, request a breakdown before you write a single comment. Copy-paste version:<\/p>\n
\u201cThis pull request is too large for me to review without a clearer implementation plan. Can you break it into smaller scoped units, or add a summary of what each part does and why it\u2019s structured this way? Happy to review after that.\u201c<\/p>\n
Firm, short, not personal. And it saves you an hour.<\/p>\n
5. Untrusted input in workflows<\/p>\n
Prompt injection in CI agents is real and underappreciated. Here\u2019s the pattern: an agent workflow reads content from a pull request body, an issue, or a commit message. That content gets interpolated into a prompt. The prompt goes to a model. The model output gets piped to a shell command. The whole thing runs with GITHUB_TOKEN permissions.<\/p>\n
When you\u2019re reviewing any workflow that calls an LLM, these are blockers:<\/p>\n
Is untrusted user input, pull requestbodies, issue bodies, commit messages, being interpolated into prompts without sanitization?<\/p>\n
Is GITHUB_TOKEN write-scoped when it only needs read access?<\/p>\n
Is model output being executed as shell commands without validation?<\/p>\n
Are secrets accessible to the agent step or being printed to logs?<\/p>\n
What to require before merge: least-privilege permissions in the workflow YAML (permissions: read-all is a reasonable default), sanitize and quote untrusted content before it touches a prompt, separate the \u201canalysis\u201d step from the \u201cexecution\u201d step with a human approval gate for anything touching production, never eval model output.<\/p>\n
Time\u00a0Step\u00a0What to do\u00a01\u20132 min\u00a0Scan and classify\u00a0Look at the file list and diff size. Narrow task (docs, CI,\u00a0small change) or complex (multi-file, logic, performance, tests)? That classification sets your review depth for everything that follows.\u00a02\u20133 min\u00a0Check CI changes first\u00a0Before reading a single line of app code, look at anything touching .github\/workflows, test configs, coverage settings, or build scripts. Flag anything that weakens CI. Stop sign\u00a0check.\u00a03\u20135 min\u00a0Scan for new utilities\u00a0Search for new functions, helpers, or modules. For each one, do a quick repo search to check for duplicates. Flag anything that reinvents existing functionality.\u00a05\u20138 min\u00a0Trace one critical path\u00a0Pick the most important logic change.\u00a0Trace it\u00a0end-to-end: input \u2192 transforms \u2192 output. Check boundary conditions, permissions, unexpected\u00a0branching. This is the step you\u00a0can\u2019t\u00a0skip.\u00a08\u20139 min\u00a0Security boundaries\u00a0If this\u00a0PULL\u00a0REQUEST touches\u00a0any workflow that calls an LLM or handles untrusted input, run through the security checklist above.\u00a09\u201310 min\u00a0Require evidence\u00a0For any non-trivial logic change, require a test that\u00a0fails on\u00a0the pre-change behavior. No rollback plan for risky changes? Ask for one.\u00a0<\/p>\n
When to request a smaller pull request:<\/p>\n
The diff touches more than five unrelated files<\/p>\n
You can\u2019t describe the purpose of the pull request in one sentence<\/p>\n
The agent has no implementation plan or the pull request body is empty<\/p>\n
CI is failing and the only changes in the diff are to test files<\/p>\n
Let Copilot review it first<\/p>\n
Use automated review for what it\u2019s good at: catching the mechanical stuff before a human has to. Copilot code review flags style inconsistencies, obvious logic errors, missing error handling, and type mismatches. It handles the low-level scan. That frees you up for the judgment work, which is where your time actually matters.<\/p>\n
Treat it as a prerequisite, not a replacement. Let Copilot run first. If it catches something obvious, let the author address it before you invest your review time.<\/p>\n
You can tune this with custom instructions specific to your team: flag anything that modifies CI thresholds, surface new utilities for deduplication review, check that every external input is validated. The more specific your instructions, the more useful the automated pass.<\/p>\n
\ud83d\udca1 Pro tip: I recently experimented with codifying my own review checklist using the Copilot SDK. Instead of remembering to run the same security checks on every pull request, I built a workflow that takes my personal checklist\u2014auth on admin endpoints, tests actually running, safe env variable handling\u2014and runs it against the diff automatically. If it finds critical issues, it blocks the merge.<\/p>\n
Judgment is the bottleneck, and that\u2019s fine<\/p>\n
The surface area of code is growing. pull request volume is growing. The time you spend scanning boilerplate should shrink.<\/p>\n
What doesn\u2019t shrink is the context you carry. The things you know about your system that aren\u2019t written down anywhere. That\u2019s what makes your review valuable, and it\u2019s the part that doesn\u2019t get automated.<\/p>\n
Three takeaways:<\/p>\n
Any CI weakening is a hard stop.<\/p>\n
Let the agents scan first. You trace the critical path.<\/p>\n
Red flag checklist as your default on complex agent pull requests.<\/p>\n
\t\tWritten by\t<\/p>\n
\t\t\t\t\t![\"Andrea](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/05\/Andrea-Griffiths_avatar_1755783168-200x200.jpeg\"){kind=avatar}
<\/p>\n
Andrea is a Senior Developer Advocate at GitHub with over a decade of experience in developer tools. She combines technical depth with a mission to make advanced technologies more accessible. After transitioning from Army service and construction management to software development, she brings a unique perspective to bridging complex engineering concepts with practical implementation. She lives in Florida with her Welsh partner, two sons, and two dogs, where she continues to drive innovation and support open source through GitHub’s global initiatives. Find her online @acolombiadev.<\/p>\n","protected":false},"excerpt":{"rendered":"You\u2019ve probably already approved one without realizing it. The tests passed. The code was clean. You merged it.…\n","protected":false},"author":2,"featured_media":31768,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[405,7537,20394,8245,20395,20396],"class_list":{"0":"post-31767","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-agentic-ai","8":"tag-ai-agents","9":"tag-artificial-intelligence-agents","10":"tag-code-review","11":"tag-github-copilot","12":"tag-pull-requests","13":"tag-tech-debt"},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/31767","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=31767"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/31767\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/31768"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=31767"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=31767"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=31767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}