Run a Pre-Review AI Pass on Your Own PR

Tier: Foundation · Workflow area: Code Review

Teams like Shopify formalized this as an automated "first reviewer" pattern; you can get most of the benefit with any assistant today.

When to use

• •
  Every non-trivial PR, right before you click "request review".
• •
  Especially: PRs to unfamiliar codebases, PRs after long sessions (your blind spots are largest), and PRs containing AI-generated code.

Skip for one-line changes and mechanical bumps where review is a formality.

Prerequisites

• •
  Your full diff, retrievable locally: git diff main...HEAD (or the PR's Files Changed view).
• •
  Any assistant: GitHub Copilot code review (assign Copilot as reviewer on the PR), Claude Code in the repo, Copilot Chat, or CodeRabbit.
• •
  10–15 minutes of budget — the pass must be cheaper than the review round it saves.

The workflow

1. 1.

   Generate the diff and self-review context.

   Copy

   git diff main...HEAD > /tmp/pr.diff
   git log main...HEAD --oneline
   

2. 2.

   Run the adversarial pass. Feed the diff with a prompt that asks for review findings, not praise:

   Copy

   Act as a strict senior reviewer on this diff. The intent of the change:
   [1-2 sentences]. Report ONLY:
   1. Bugs or behavior changes beyond the stated intent
   2. Debug leftovers: prints, commented code, TODO, dead flags, stray files
   3. Missing or weakened tests for changed logic (name the uncovered path)
   4. Error-handling gaps: swallowed exceptions, unchecked returns, missing
      timeouts on new I/O
   5. Naming/API choices a reviewer would question, with the question they'd ask
   Format: file:line — finding — severity (blocker/should-fix/nit).
   No compliments, no summaries of what the code does.
   

3. 3.

   Triage findings like review comments. Fix blockers and should-fixes; consciously reject bad nits (models over-flag style). For each rejected finding, know why — if you cannot articulate why it is wrong, it probably is not.

4. 4.

   Attack your own tests. Second prompt, same session:

   Copy

   Now look only at the tests in this diff. For each changed behavior, tell me
   which test would fail if I reverted that behavior. List changed behaviors
   with NO such test. Flag any assertion that is weaker than it looks
   (assertTrue on non-empty, broad exception catches, snapshot-everything).
   

   This is the highest-yield step: untested changed behavior is the #1 thing human reviewers catch late.

5. 5.

   Generate the PR description last, from the final diff.

   Copy

   Write a PR description from this diff: (1) what & why in 3 sentences,
   (2) notable decisions and alternatives rejected, (3) how it was tested
   (I will fill in evidence), (4) risks and rollout notes. Do not invent
   test evidence — leave TODO markers where I must attach proof.
   

   Attach real evidence at the TODOs (test output, screenshots, benchmark numbers) — an invented "Tested manually" line destroys reviewer trust permanently.

6. 6.

   Request human review. In the PR, note that an AI pre-pass ran — it tells reviewers the nit layer is already handled and focuses them on design.

Tool variants

• GitHub Copilot code review: assign Copilot as a reviewer directly on the PR — zero setup, comments appear inline; then do steps 4–5 in chat.
• Claude Code: run the whole flow in-repo (review my branch against main as a strict reviewer...); it can also execute the test-gap check by actually running the suite.
• CodeRabbit (free for OSS): automatic on PR open; use its findings as step 2 output and continue from step 3.

Verification

• •
  Zero debug leftovers (grep -nE "console\.log|print\(|debugger|TODO" $(git diff main...HEAD --name-only) is clean or intentional).
• •
  Every changed behavior maps to a test that would fail on revert — or the gap is called out in the PR description.
• •
  The PR description's test-evidence section contains real artifacts, not placeholders.
• •
  Human reviewers' comments on this PR are about design, not nits — that is the measurable win.

Pitfalls

• Running the pass too early. Pre-review on a half-done branch wastes the findings; run it once, at the end.
• Accepting all findings. AI reviewers over-flag; blindly fixing every nit churns the diff and can introduce bugs. Triage with the same skepticism you give human nits.
• Letting the AI write the description before the pass. Describe the final diff, or the description drifts from the code.
• Cargo-culting severity. Models mislabel severity both ways; a "nit" about an unchecked error return may be your only real blocker.

Restricted-environment variant

• Client-code restrictionsrun the pass with the sanctioned enterprise tool only (Copilot Business with no-training flag, or a client-tenant Bedrock/Azure OpenAI route). If none exists, run a local model over the diff — pre-review prompts work acceptably on Qwen-Coder-class local models because the diff is small and self-contained.
• Minimum-footprint optionpaste only the diff (not the repo) — a diff plus intent statement is usually policy-safer than repository access, but confirm with the client's data policy first.
• No sanctioned tool at allthe grep-based leftover checks and revert-test reasoning work with no AI at all; keep them as a manual checklist.

Success criteria

• •
  The pass takes ≤15 minutes and becomes a habit on every substantive PR.
• •
  Review round-trips drop: fewer than half your PRs get a second "fix nits" round.
• •
  Reviewers stop finding debug leftovers and missing-test gaps in your PRs at all.