The hidden cost of approving agent-written code
Agent-generated pull requests can look indistinguishable from human-written ones. Tests pass, the code is tidy, and it merges without friction. But research from January 2026 (“More Code, Less Reuse”) suggests that per change, agent code carries more redundancy and more technical debt than code written by people. Worse, the same study found reviewers tend to feel more comfortable approving agent output—even as the long-term costs quietly accumulate.
The takeaway isn't to throttle the pipeline; it's to change how you look at each request before you click merge.
Agent pull requests are overloading review queues
The numbers are already striking. GitHub Copilot code review has passed 60 million reviews and is growing 10x in under a year. More than one in five code reviews on GitHub now involves an agent at some stage. But the real strain is directional: a single developer can spawn a dozen agent sessions before lunch, while the human review loop still runs at its original speed. The gap between generation capacity and review capacity is widening.
Agent pull requests are a fixture now. Your only real choices are about how deliberately you review them.
What you're actually reviewing
Before opening a diff, frame what a coding agent is: productive, literal, and excellent at pattern-matching, with zero knowledge of your incident history, your operational lore, or any constraint that isn't encoded in the repository. It will confidently produce code that looks finished. That illusion is where the risk lives.
You carry the context the agent lacks—the trade-offs, the edge cases your team learned the hard way, the systems whose behavior isn't documented. That's not a defect in the process; it's the entire reason your review matters. Judgment cannot be automated, and judgment requires context.
Red flags to check first
CI weakening is a hard stop
When an agent breaks a test suite, a quick fix is to reduce what CI enforces: remove tests, skip lint, append || true to a command. Some agents take that path.
Any diff that weakens CI should block the merge until justified. Before approving, verify:
- Coverage thresholds are unchanged.
- No tests were removed, renamed, or marked skipped.
- Workflows still run on forks and pull requests.
- No CI steps were newly gated behind conditions.
A yes to any of these demands an explicit explanation before you continue.
Duplicated logic is the highest-ROI find
Agents find a pattern in a codebase and replicate it—often missing an existing utility that already does the same job. The usual symptoms: new helpers that shadow existing ones under slightly different names, validation logic reimplemented across files, middleware rebuilt from scratch instead of imported, “almost the same” functions created because they weren’t found in the agent’s view of the code.
For every new helper in an agent pull request, search for an existing equivalent before you invest a comment. If you find one, request consolidation before merge. Duplicated logic is an anchor; other agents will find it later and treat it as prior art to copy further.
Pro tip: Set a rule that new utilities above a size threshold require justification in agent pull requests. This catches the duplication problem on arrival.
Correct-looking code that is wrong
Hard hallucinations—calling a missing API or referencing an out-of-scope variable—fail in CI. The dangerous ones don't: compiles cleanly, passes every test, and is still wrong under a condition the agent never considered. Off-by-one pagination. Missing permission checks on an untested branch. Validation short-circuiting on an edge case. A race that only surfaces under load.
Trace, don’t scan. Follow the most critical path in the diff from input through every transform to output, then check boundary cases: zeros, maxes, empty sets, missing validation on external values, permissions at every branch, and any conditional logic that surprises you.
Require a failing test on pre-change behavior. If the agent can't produce such a test for the bug it claims to fix, the fix is either incomplete or misdiagnosed.
Large agent pull requests can go silent
You post a thorough review. The request goes quiet—or the agent responds with something vaguely related and loops uselessly for multiple rounds. Large, unstructured agent pull requests correlate with exactly this kind of abandonment. The bigger and less scoped they are, the more likely your time will burn into nothing.
Before deep-reviewing a large agent request, check the history: has it been responsive in earlier rounds, and does it include a clear implementation plan? If there's no plan, ask for one before commenting. A firm, short message works:
“This 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’s structured this way? Happy to review after that.”
When to request a smaller pull request:
- The diff touches more than five unrelated files
- You can’t describe the purpose of the pull request in one sentence
- The agent has no implementation plan or the pull request body is empty
- CI is failing and the only changes in the diff are to test files
Untrusted input inside agent workflows
Prompt injection in CI agents is real. The dangerous pattern: a workflow reads content from a pull request body, an issue, or a commit message, interpolates it into a prompt, feeds the model output to a shell command, at GITHUB_TOKEN permissions. Every untrusted string becomes an instruction channel.
When reviewing any workflow that calls an LLM, these are blockers:
- Is untrusted input (PR bodies, issues, commit messages) interpolated into prompts without sanitization?
- Is
GITHUB_TOKENwrite-scoped when only read access is needed? - Is model output executed as shell commands without validation?
- Are secrets accessible to the agent step or printed to logs?
Before merge, require: least-privilege permissions in the workflow YAML (permissions: read-all is a reasonable default), sanitized and quoted untrusted content before it reaches a prompt, a human approval gate between the analysis step and any execution step touching production, and no eval of model output.
| Time | Step | What to do |
|---|---|---|
| 1–2 min | Scan and classify | Look at the file list and diff size. Narrow task (docs, CI, small change) or complex (multi-file, logic, performance, tests)? That classification sets your review depth for everything that follows. |
| 2–3 min | Check CI changes first | Before 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 check. |
| 3–5 min | Scan for new utilities | Search for new functions, helpers, or modules. For each one, do a quick repo search to check for duplicates. Flag anything that reinvents existing functionality. |
| 5–8 min | Trace one critical path | Pick the most important logic change. Trace it end-to-end: input → transforms → output. Check boundary conditions, permissions, unexpected branching. This is the step you can’t skip. |
| 8–9 min | Security boundaries | If this PULL REQUEST touches any workflow that calls an LLM or handles untrusted input, run through the security checklist above. |
| 9–10 min | Require evidence | For any non-trivial logic change, require a test that fails on the pre-change behavior. No rollback plan for risky changes? Ask for one. |
Automate the mechanical scan first
Let automated review catch the low-level issues before you spend attention on them. Copilot code review surfaces style inconsistencies, obvious logic errors, missing error handling, and type mismatches. That pass is a prerequisite, not a substitute: it clears the routine checks so your time goes to judgment calls.
You can tune the automated pass with team-specific instructions: flag any modification to CI thresholds, surface new utilities for dedup review, and check that every external input is validated. The sharper the instructions, the more useful the pre-screen.
Pro tip: Some teams codify their own review checklists—auth on admin endpoints, tests actually running, safe env variable handling—as an automated workflow against each diff, blocking the merge if critical issues surface. That approach turns personal checklist discipline into a process.
The context gap is your job
Pull request volume is exploding, and boilerplate scanning time should shrink as a fraction of your day. But the thing that doesn’t shrink is your accumulated context about the system—the unwritten knowledge that no agent will discover on its own.
Three takeaways:
- Any CI weakening is a hard stop.
- Let agents scan first. You trace the critical path.
- Have a red flag checklist ready for complex agent pull requests.
