Review AI-written pull requests against an acceptance contract
A reviewer's method from r/ExperiencedDevs: a short scope contract at the top of the PR, the diff checked against it first, no extra behavior, plus Copilot code review as a first pass.
Tools used
- GitHubPull requests and CI
- GitHub Copilot code reviewAutomated first-pass PR reviewer
- Claude CodeCoding agent that reads, edits and tests the repo
Step navigator
PRs that carry a scope contract, a review that checks behavior before style, and a clear rule for cutting extra behavior.
Developers who review PRs produced by Claude Code, Codex, Cursor or Copilot, whether their own or a teammate's.
Before you start
AI-written code tends to compile and pass tests while still missing what was meant. In an r/ExperiencedDevs thread on exactly that problem, one reviewer described a contract-first review, and another said they anchor every review to a short written "what should not change" summary. This guide turns those descriptions into a repeatable review.
Step-by-step instructions
Put a short contract at the top of the PR
In the PR description, write what is in scope, what is explicitly out of scope, and 3 to 5 acceptance checks in plain language. This is the reviewer's own description of what consistently helped.
Where this comes from: u/Illustrious_Echo3222 in r/ExperiencedDevs: "How do you review your code against the original plan or requirement?".
Why this works
Without a contract, the reviewer has nothing objective to compare the diff against.
Check behavior against the contract before reading the implementation
Read the contract, then check the diff's behavior against it before you judge elegance or tests. Another commenter in the thread does the same: they check behavior against the written summary "before I look at elegance or tests".
Where this comes from: u/workflowsidechat in r/ExperiencedDevs: "How do you review your code against the original plan or requirement?".
Why this works
The most expensive AI mistake is the right code for the wrong problem.
Push requirements into tests, and ask for screenshots for UI
Where possible, encode the acceptance checks as tests, including a couple of high-level "this flow should do X and never do Y" checks. For UI changes, ask for screenshots or a short demo video, because "reading JSX doesn't catch the design drift."
Where this comes from: u/Illustrious_Echo3222 in r/ExperiencedDevs: "How do you review your code against the original plan or requirement?".
Add tests that encode these acceptance checks: <paste checks>. For the UI change, take before/after screenshots of <page>.
Why this works
Tests and screenshots turn your contract into something a machine and a reviewer can check.
Run Copilot code review as a first pass
On the PR, under Reviewers, click Request next to Copilot (or run gh pr edit <number> --add-reviewer @copilot). Copilot leaves comments labeled High, Medium or Low. By default it does not approve or block. Add review guidance to .github/copilot-instructions.md or AGENTS.md. Treat it like the review bots in other teams' workflows: a first pass, not the final say.
Where this comes from: u/metaphorm (review bots + human final review) in r/ExperiencedDevs: "Claude Autonomous Coding: Discussion".
Why this works
It catches obvious issues quickly so your human review can focus on intent.
Cut or split anything not in the contract
Be strict about "no extra behavior". If the PR adds things that are not in the contract, they get cut or split into another PR. The reviewer warns that otherwise "the codebase slowly turns into a pile of almost right features."
Where this comes from: u/Illustrious_Echo3222 in r/ExperiencedDevs: "How do you review your code against the original plan or requirement?".
Why this works
Agents love adding helpful extras; each one is unreviewed scope.
Check that new code reuses existing patterns
If the change touches architecture, look for a short note on how it reuses existing patterns rather than inventing new ones. The same reviewer says this is "where AI tends to quietly fork abstractions." Ask the agent to explain which existing modules it reused, then confirm in the code.
Where this comes from: u/Illustrious_Echo3222 in r/ExperiencedDevs: "How do you review your code against the original plan or requirement?".
Which existing modules or patterns did this change reuse, and where did it introduce a new abstraction? List file paths.
Why this works
Duplicate abstractions are hard to spot later and expensive to merge back together.
End of guide · Reviewed Oct 26, 2026
Pro tips3
- Keep the contract to a handful of lines. If it needs a page, the PR is too big.
- Copilot may repeat comments on re-review even after you resolve them (GitHub notes this). Don't treat repeats as new findings.
- Copilot code review also reads CLAUDE.md and AGENTS.md from the head branch.
Common mistakes3
- Approving because CI is green.
- Letting "while I was there" changes ride along.
- Asking the same agent that wrote the code to grade it in the same session.
FAQ2
Does Copilot's review count as an approval?
What if I'm the only developer?
Related field guides.
CodingPlan in Obsidian, build with Claude Code: the PRD-to-tasks loop
How practitioners on r/hermesagent run projects: requirements and task lists in an Obsidian vault, small tasks handed to a coding agent, every diff reviewed by a human.
CodingKeep agent PRs small: one concern per branch
A developer's setup from r/ExperiencedDevs: the agent plans a feature into small chunks, writes the approved plan to the repo, and ships one stacked PR per concern.
CodingShip a feature with a coding agent: spec, tests first, then review the diff
The loop experienced developers describe on r/ExperiencedDevs: write the spec, plan the smallest steps, have tests written from the spec, implement, then review against the spec before anything merges.