Agent pr review

Agent PR Review

Practical workflow for reviewing agent-generated pull requests: what to look for, where issues hide, and how to catch technical debt before it ships.

---

Mental model

Before reading a single line of diff, establish what you're reviewing.

A coding agent is a productive, literal, pattern-following contributor with zero context about your incident history, your team's edge-case lore, or operational constraints that don't live in the repository. It will produce code that looks complete. That "looks complete" failure mode is dangerous.

You're the one who carries that context. The part of review that doesn't get automated is judgment, and judgment requires context only you have.

Note for PR authors

If opening an agent-generated pull request:

1. Edit the PR body before requesting review — agents love verbosity
2. Annotate the diff where context is helpful
3. Review it yourself before tagging others — signal that you've validated the agent captured your intent

Reviewing your own pull request isn't optional when agents are involved. It's basic respect for your reviewer's time.

---

Triage in priority order

Run these steps in order. Do each as quickly as the diff allows — the goal is efficient coverage, not time spent. Classification in step 1 sets review depth for everything that follows.

1. 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.
2. Check CI changes first: Before reading app code, inspect anything touching .github/workflows, test configs, coverage settings, or build scripts. Flag anything that weakens CI. Hard stop.
3. Scan for new utilities: Search for new functions, helpers, or modules. For each one, do a quick repo search for duplicates. Flag anything that reinvents existing functionality.
4. 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 step cannot be skipped.
5. Security boundaries: If the PR touches any workflow that calls an LLM or handles untrusted input, run the security checklist in references/security-workflows.md.
6. 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.

Delegable scans (optional, large PRs)

If your agent supports parallel sub-agents and the PR is large or complex, delegate steps 2, 3, and 5 using the tasks below. For small PRs, skip delegation — the overhead isn't worth it.

CI integrity scan (step 2) — Scope: Inspect .github/workflows, test configs, coverage settings, and build scripts in the PR diff. Report back: Any CI-weakening change (coverage thresholds lowered, tests removed or skipped, lint steps weakened, conditional gates added). Hard stop if found.

Duplication scan (step 3) — Scope: For each new helper, utility, or module in the diff, search the repo for existing equivalents. Report back: Duplicates needing consolidation before merge — include file paths and why they overlap.

Security scan (step 5) — Scope: If the PR touches any workflow that calls an LLM or handles untrusted input, run the checklist in references/security-workflows.md. Report back: Security blockers — prompt injection risk, excessive token permissions, unvalidated model output execution, secrets exposure.

Step 4 — tracing the critical path — stays with the main reviewer. It's judgment work and shouldn't be delegated or fragmented.

---

Red flags (blockers)

For expanded checklists on each flag, see references/red-flags.md.

1. CI gaming — hard stop

Agents fail CI. When they do, they may remove tests, skip lint, or add || true to test commands.

Any change that weakens CI is a blocker. Before approving, check:

1. Did coverage thresholds change?
2. Were any tests removed, renamed, or marked as skipped?
3. Did the workflow stop running on forks or pull requests?
4. Are any CI steps now gated behind conditions they weren't before?

Yes to any of these requires explicit justification before you continue.

2. Code reuse blindness — highest ROI check

Agents find a pattern in the codebase and replicate it, often without checking whether a utility that already does the same thing exists elsewhere.

Symptoms: new utility functions duplicating 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 "almost the same" but with different names.

For every new helper or utility, do a quick search. If you find an equivalent, require consolidation before merge — don't just leave a comment. Leaving duplicated logic means agents will find it as prior art and replicate it further.

Pro tip: Require justification for adding new utilities in agent PRs above a size threshold.

3. Hallucinated correctness

The obvious hallucination (calling an API that doesn't exist) gets caught in CI. The dangerous one is subtler: code that compiles, passes every test, and is wrong.

Examples: off-by-one errors in pagination, missing permission checks on untested branches, validation that short-circuits under edge cases, wrong behavior under race conditions at scale.

Trace it, don't 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
• Surprising conditional logic

Require a new test that fails on the pre-change behavior. If the agent can't write a test that would have caught the bug it claims to fix, the fix is incomplete or the understanding is wrong.

4. Agentic ghosting

You leave a thorough review. The PR goes quiet. Or the agent responds, misses the point, and runs in circles.

Larger PRs with no structured plan correlate strongly with agent abandonment or misalignment.

Before investing deep review on a large agent PR:

• Check the PR history — has it been responsive in previous rounds?
• Does it have a clear implementation plan, or did the agent just start writing code?

If there's no plan, request a breakdown before writing a single comment:

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.

5. Untrusted input in workflows

Prompt injection in CI agents is real. Pattern: an agent workflow reads content from a PR body, issue, or commit message → interpolates it into a prompt → sends to a model → pipes output to a shell command → runs with GITHUB_TOKEN permissions.

When reviewing any workflow that calls an LLM, these are blockers:

• Is untrusted user input (PR bodies, issue bodies, commit messages) interpolated into prompts without sanitization?
• Is GITHUB_TOKEN write-scoped when it only needs read access?
• Is model output executed as shell commands without validation?
• Are secrets accessible to the agent step or being printed to logs?

See references/security-workflows.md for required mitigations.

---

When to request a smaller PR

Request a breakdown before deep review if any of these apply:

1. The diff touches more than five unrelated files
2. You can't describe the purpose of the PR in one sentence
3. The agent has no implementation plan or the PR body is empty
4. CI is failing and the only changes in the diff are to test files

---

Let automated review run first

Use automated review for what it's good at: style inconsistencies, obvious logic errors, missing error handling, type mismatches. That frees you for judgment work.

Treat it as a prerequisite, not a replacement. Let Copilot (or your team's automated reviewer) run first. If it catches something obvious, let the author address it before you invest your review time.

Tune with custom instructions specific to your team: flag CI threshold changes, surface new utilities for deduplication review, check that every external input is validated.

---

Three takeaways

1. Any CI weakening is a hard stop.
2. Let the agents scan first. You trace the critical path.
3. Use the red flag checklist as your default on complex agent PRs.

---

Attribution

Based on Agent pull requests are everywhere. Here's how to review them. by Andrea Griffiths (GitHub Blog, May 2026).