AI Coding Agents
Code Review
Reviewing agent-generated pull requests at scale
September 24, 2026 - 2 minute read
Agent-generated pull requests can increase change volume faster than a team increases review capacity. The answer is not to lower the review bar. Teams need a review path that makes small changes cheap to verify and routes risky changes to the people who understand their consequences.
The pull request remains the control point. GitHub's pull request review model separates comments, approvals, and change requests. Agent-authored work should pass through the same protected workflow as human-authored work, with a clearly identified author and visible test evidence.
Make agent-generated pull requests reviewable
Start with scope. One pull request should express one coherent change and avoid unrelated cleanup. The description should connect the original request to the files changed, explain any surprising decision, list checks that actually ran, and disclose checks that remain pending. Reviewers should not have to infer whether a missing test was intentional.
Large generated diffs deserve the same skepticism as large human diffs. Split mechanical changes from behavioral changes when they can be reviewed independently. Keep generated files with the source change that produced them, but call them out so reviewers can focus on the source. If an agent cannot explain why a file changed, the pull request is not ready.
Provide reproduction evidence for bug fixes and before-and-after evidence for user-facing changes. Keep logs concise and attach the artifact that supports the claim. A green summary without the command, environment, or observed behavior gives reviewers little to verify.
Automate review for agent-generated pull requests
Linters, type checks, unit tests, security scans, and policy checks should run before a human opens the diff. Factory's automated code review triggers on pull request changes, analyzes the diff and existing comments, and posts inline findings for correctness and security issues. The workflow skips draft pull requests by default to avoid reviewing work that is still moving.
Automated review should prioritize actionable defects rather than style preferences. Configure repository-specific guidance for architecture rules and known failure modes. Keep a limit on comment volume so one important race condition does not disappear beneath minor suggestions. A clean automated review supports human judgment, but it does not replace ownership or approval.
Route risk to the right reviewer
Use ownership rules to identify the teams responsible for sensitive paths. GitHub CODEOWNERS can request those reviewers automatically, while branch protection can require approvals and passing status checks. Apply stricter requirements to authentication, billing, deployment, and data migration paths.
Reviewers should examine behavior, boundaries, and rollback plans. Ask whether tests cover the acceptance criteria, whether permissions became broader, whether a migration preserves compatibility, and whether operational evidence exists for a production-facing change. Sample generated changes over time to find recurring defects and turn those findings into tests or review guidance.
Track review wait time, change-request rate, escaped defects, and revert rate by task class. Do not reward raw pull request volume. A sustainable workflow safely reduces repeated reviewer effort while preserving the evidence needed to trust each merge.
