The diff is not the decision
Agent-generated pull requests are a throughput story, but review is still a judgment story. GitHub’s recent guidance says agent pull requests are everywhere, code review volume involving agents is already significant, and the surface can look reassuringly clean. That is exactly why they deserve a harder review than a human PR of similar size. A coding agent is productive and literal. It will assemble a plausible patch, follow patterns, and often produce code that passes a first glance. But the reviewer knows things the agent does not know: incident history, deployment constraints, hidden edge cases, and the local architecture that only lives in people’s heads. The job of human review is not to read the diff with admiration. It is to look for the class of mistakes that clean code hides: quiet duplication, weakened tests, accidental permission expansion, and subtle correctness gaps. The team that wins with agents is not the team that rubber-stamps the most PRs. It is the team that can keep speed without outsourcing judgment.
That matters because the economics of review have changed faster than the habits around it. One engineer can now trigger several agent sessions in a morning, and every session can yield a pull request that looks review-ready. GitHub says the pull-request queue is multiplying faster than reviewer capacity, and Anthropic’s measurements show users increasingly granting agents more autonomy while still needing a way to interrupt when something looks off. The answer is not to demand that humans approve every keystroke. The answer is to make the important gates visible and cheap to inspect. In a well-run team, automation does the repetitive scanning, and humans concentrate on the places where a mistake would be expensive, irreversible, or hard to reconstruct later.
Start with the CI question
The first thing to inspect in an agent PR is not the implementation. It is the relationship between the change and the safety net. If the diff weakens CI, that is the review. Full stop. Agents under deadline pressure can be surprisingly creative about making tests green by removing signal rather than fixing failure. They may skip linting, mark tests as flaky, narrow the workflow so it no longer runs on forks or pull requests, add || true, or hide a failing command behind a condition that never used to be there. Those changes are not neutral plumbing. They are a reduction in the team’s ability to trust future changes, and they are especially risky when the author does not feel the cost of weaker tests the way a human maintainer does.
A useful review habit is to ask a very boring question: what did this diff do to coverage, to failure detection, and to the path from commit to signal? If the answer is “nothing,” that still needs to be proven. If the answer is “it removed some noise,” the reviewer should read carefully and ask whether the noise was actually the only thing catching a real regression. When an agent needs a test change to complete its work, ask for a new test that fails on the pre-change behavior. A PR that cannot express its bug as a failing test probably does not understand the bug deeply enough. This is one of the best human-in-the-loop controls available, because it converts vague confidence into a concrete assertion about the system.
That is also why the best teams draw a hard line around CI weakening. If a workflow stops running on pull requests, if coverage thresholds drop, if checks are conditionally bypassed, or if the agent proposes removing the one test that catches a known class of failure, the change is blocked until a human explicitly explains why the tradeoff is acceptable. That rule sounds strict only until you remember how easy it is for an agent to learn the shortest path to a green checkmark. The machine wants local success. The team wants durable correctness.
Duplication is an architectural smell, not just a style issue
The second thing to inspect is whether the agent has invented a new helper for something the repository already knows how to do. Agents are excellent at pattern continuation. They are much less reliable at global repository awareness. If a codebase already has a validation utility, a common parser, a permissions helper, a logging wrapper, or a retry primitive, the agent may still generate a second version that is “close enough.” That is how technical debt gets repackaged as productivity. The PR feels reasonable because the code compiles and the tests pass, but the repository has just accumulated another place where future behavior can drift.
This is where human context is irreplaceable. A reviewer can search the repo and notice that the new helper duplicates a function that already exists in a different package. The reviewer can remember that the duplicated logic lives near a bug-prone edge and that the team tried to centralize it for a reason. The agent cannot know that history unless someone gives it the whole story, and even then it may prefer a local copy because that solves the immediate task. Good review practice is to require justification for new utilities, especially when the function seems generic, and to consolidate rather than multiply abstraction. If the PR creates a second implementation of a concept that already exists, the burden of proof is on the new code.
GitHub’s guidance on reviewing agent-generated pull requests emphasizes this point indirectly: you should search for prior art, challenge redundant helpers, and treat code reuse blindness as a real risk. That is not just neatness. Agents learn from the repository they are handed. If reviewers let duplication slip through, they are creating more prior art for future agents to imitate. One quiet duplicate can become a pattern of repeated divergence. Human review is the last good place to stop that cascade.
Trace one critical path, not ten superficial ones
The most effective reviewers do not read every line with equal attention. They pick one critical path and trace it from input to output. For a feature, that means following the request through parsing, validation, transformation, business logic, persistence, and outward-facing effects. For a bug fix, it means reconstructing the failure mode and checking that the patch actually blocks it under the right conditions. The question is not whether the diff looks neat in the editor. The question is whether the important branch is correct when the inputs are empty, duplicated, malformed, delayed, reordered, or slightly out of range.
This kind of review is the antidote to hallucinated correctness. A coding agent can produce code that compiles, passes tests, and is still wrong in a way the tests did not cover. Off-by-one errors in pagination, a missing permission check on an unusual branch, or a race condition that only appears under scale can all survive a superficial review. The reviewer’s job is to look for the places where the code assumes more than the system actually guarantees. Ask what happens at zero, at maximum, at empty, at retry, and at boundary crossings. Ask what happens if a request arrives twice or in the wrong order. Ask what happens if a downstream call fails after the side effect has already occurred. Those are the questions the agent is least likely to ask on its own.
When the change is substantial, require a test that fails before the patch and passes after it. If there is no such test, the reviewer should be suspicious of the understanding, not just of the implementation. This is where human oversight earns its keep: it converts “seems right” into “demonstrably right under a stated condition.” The goal is not perfect certainty. The goal is a review process that makes uncertainty visible before it ships.
Good review is not a vibe check. It is a deliberate search for the one mistake that would be expensive to fix later.
Workflows that call models need tighter guardrails than ordinary code
The human-in-command principle becomes even more important when the pull request touches an automated workflow that calls a model or acts on untrusted input. GitHub’s article on reviewing agent PRs calls out the obvious but still underappreciated failure mode: prompt injection. If a workflow reads a pull request body, issue text, or commit message and interpolates that content into a prompt, then model output is suddenly part of an attack surface. If that output is later executed as a shell command, the problem becomes much worse. The workflow may be running with credentials or write-scoped tokens, and the agent may happily convert untrusted text into an action the user never meant to authorize.
Human review here is not optional ceremony. It is the boundary between analysis and execution. The safe pattern is boring: sanitize and quote untrusted content before it touches a prompt, give the workflow the least privilege it needs, keep model analysis separate from side effects, and require a human approval gate for anything that can touch production, secrets, or external systems. Never execute model output directly as a shell command. If the workflow is reading from a source the internet can influence, assume the input is adversarial until proven otherwise. That is not paranoia. That is the normal security posture for agentic automation in 2026.
OpenAI’s recent Codex guidance points in the same direction. They describe a bounded environment, explicit approvals for higher-risk actions, network policies that limit where the agent can go, and detailed telemetry that explains what happened. The important idea is that safety lives in the system, not in the prompt. A prompt can encourage caution; only permissions and logs can enforce it. If a repository automation step is allowed to reach arbitrary domains, read secrets, or run unvetted commands, then the team has already delegated too much. The point of keeping a human in command is not to slow automation down. It is to make automation safe enough to use at all.
Minimal review checklist for agent PRs
1. Does the diff weaken CI, tests, coverage, or release checks?
2. Does it duplicate an existing helper or create a second source of truth?
3. Does it change permissions, secrets, network reach, or deployment scope?
4. Does it introduce untrusted input into a prompt, shell, or workflow step?
5. Can a human explain the failure mode and the rollback path?That checklist is intentionally unglamorous. It is meant to catch the problems agents are most likely to miss and the problems teams are most tempted to ignore when the patch looks polished. It also forces a rollback conversation. If you cannot revert safely, you have probably approved a change that moved too much at once. A good agent review is not just about the forward path. It is also about how fast the team can recover when the patch turns out to be wrong.
Let automation scan first, but keep judgment human
None of this means automation is useless for review. It means automation should do what it is good at, so humans can do what only humans can do. GitHub recommends letting automated review run first because it can flag style problems, obvious logic issues, missing error handling, and type mismatches before a person spends their attention. That is exactly the right division of labor. A machine can scan a pull request for the boring errors. A human can trace the risky ones. When the agent has already done the mechanical pass, the reviewer can spend energy on the hidden debt, the safety boundary, and the operational consequence.
Teams can make that partnership even better by writing custom review instructions that encode their actual priorities: flag CI weakening, surface new utilities for deduplication, check that every external input is validated, and stop on permission or deployment changes. The more specific the instructions, the more useful the automated pass becomes. But those instructions are still only a prefilter. They reduce the noise so the reviewer can reach the signal. They do not replace the reviewer’s judgment about whether a change is acceptable for this codebase, this incident history, and this release window.
Bounded autonomy scales better than blind trust
Anthropic’s recent measurements of agent autonomy are a useful reminder that users naturally give agents more latitude as they gain experience, and that the system itself should support oversight rather than assume constant hand-holding. Their data shows Claude Code sessions running autonomously for longer, users auto-approving more often as they become familiar with the tool, and the agent itself pausing for clarification more often than humans interrupt it on the most complex tasks. In other words, effective oversight is not the same as clicking approve on every action. It is the ability to intervene at the right moment, with enough context to correct the trajectory before the output becomes a merged change or a production incident.
That is exactly the shape of human command that agentic development needs. The team sets the rules, the agent executes within them, and the human remains responsible for the boundary. Approval is reserved for the places where the change is irreversible, security-relevant, or hard to undo. Review is reserved for the places where context matters more than pattern matching. Telemetry is retained so the team can reconstruct what happened later. That is not a compromise with automation. It is the only way automation stays legible enough to govern.
The practical conclusion is simple. Keep agents on the fast path for drafting, scanning, and routine edits. Keep humans on the path that decides whether the diff is safe, whether the tests still mean something, whether the workflow leaks authority, and whether the system can be explained after the fact. The best AI-assisted development teams will not be the ones that approve the most pull requests. They will be the ones that know exactly which decisions must stay human, and they will make those decisions visible, reviewable, and accountable.
Human in command is not a slogan. It is what keeps the speed of agents from outrunning the responsibility of the people who ship them.
