Code Review Loops: Five Claude Code Patterns That Keep PRs Moving

Code review is the stage of the pipeline that most reliably goes idle. You open a PR, reviewers respond on their own schedule, CI fails twenty minutes after you've moved on, and a change that took an hour to write spends two days in limbo. None of the waiting is engineering work — it's watching. And watching is exactly what an agent loop is for.

A code review loop is a bounded, repeating instruction to Claude Code (or Codex) that watches a review surface — PR comments, CI status, a diff — acts on what it finds, verifies the result, and repeats until a concrete exit condition is met. The exit condition is what separates a review loop from a runaway agent: "loop until all checks pass" is a loop; "keep reviewing" is a hazard.

The review category is one of the most active corners of this directory right now, so here are five real, copyable patterns — from a beginner babysitter to an adversarial two-model gauntlet — plus the safety rails that decide whether you'd trust any of them unattended.

1. Address review comments, fix CI

Address review comments, fix CI is the entry point for review loops, and the most-copied loop in the category. The instruction: check your PR for new review comments and CI failures, address them, then loop every five minutes until everything passes.

What makes it work as a loop rather than a chore is the cadence plus the exit: the agent polls on a fixed interval, does real work when there's work to do (push a fix, reply to a comment, re-run a check), and stops when the PR is green and the comment queue is empty. It's a beginner-difficulty loop because every action is scoped to one PR you already own — the blast radius is a branch, not a codebase.

Use it when: you have an open PR, reviewers in another timezone, and better things to do than refresh the page.

2. Audit code diffs, ship clean

Audit code diffs, ship clean inverts the direction: instead of responding to human review, the agent runs the review. After each step of work, it reviews the step's own diff and iterates — stopping at zero findings or after three rounds, whichever comes first.

That "three rounds" cap is the design lesson. Self-review loops have a known failure mode: the reviewer and the writer are the same model, so findings asymptotically approach nitpicks and the loop polishes forever. A hard round cap converts "review until perfect" (undefined) into "review until clean or three passes" (bounded). If findings remain after round three, that's a signal a human should look — not a reason for round four.

Use it when: you're generating multi-step changes and want each increment audited before the next one stacks on top of it.

3. Claude ships, Codex reviews

Claude ships, Codex reviews fixes self-review's blind spot by splitting the roles across models: Claude opens the PR, an independent Codex pass reviews it, Claude fixes every blocking finding, and the cycle repeats until the review comes back clean.

The checker that isn't the writer is the oldest idea in review, and it applies to agents with extra force: a model reviewing its own output shares its own assumptions. A second model with a different training lineage catches a different class of problems — and because the loop only exits on a clean adversarial pass, "done" means something stronger than the author's opinion.

This is an advanced loop: two agents, two toolchains, and findings that must be classified as blocking or non-blocking before the fix pass. Start here only after a single-model review loop already works for you.

Use it when: the change is high-stakes enough that one model's sign-off isn't sufficient, and you can afford two agents on the job.

4. The nested perfect loop

The nested perfect loop is review-loop structure taken seriously: a loop wrapping a goal wrapping a review. Every thirty minutes, the outer loop wakes; the goal drives all PR review comments to resolved via /review; an inner cap of ten turns per pass bounds each attempt.

The nesting matters because each layer holds a different kind of limit. The outer schedule bounds how often the loop runs, the goal defines the verified end state (comments resolved — checkable, not vibes), and the per-pass turn cap bounds how hard any single attempt can grind. Three limits, three different failure modes covered. Compare that to Map codebase with review prompt, which runs a review prompt repeatedly with no iteration cap at all — a structure this directory's safety grading marks down precisely because the only thing stopping it is the completion promise resolving.

Use it when: a PR accumulates review comments over hours and you want steady, bounded pressure toward "all resolved" instead of one long unbounded session.

5. Codex iterative repair: review findings as machine-readable input

Codex Iterative Repair Loop (JSON-Schema Review → Repair) is OpenAI's first-party recipe for the same problem, and it contributes one idea worth stealing regardless of which model you run: the review pass emits findings in a machine-readable schema, and the repair pass is fed those findings verbatim. The loop alternates review and repair until validation passes.

Structured findings close the gap where review loops usually leak — the handoff. A prose review ("this function looks fragile") forces the repair pass to re-interpret; a schema'd finding (file, line, rule, severity, required fix) makes the repair pass mechanical and the loop's progress measurable. If you build only one thing into a custom review loop, make it this: findings as data, not prose.

Use it when: you're wiring review and repair into a script or CI job and need each iteration's output to be parseable, diffable, and auditable.

The safety rails are the actual product

Every loop above touches code that ships, which means the harness matters more than the prompt. The review category's recurring rails:

• A verifiable exit condition. "All checks green," "zero findings," "comments resolved" — states a machine can confirm. If the exit is the agent's own judgment, it isn't an exit.
• Iteration and cadence caps. Three rounds, ten turns per pass, every five minutes. Caps turn worst cases from "unbounded spend overnight" into "one bounded pass that reports failure."
• A reviewer that isn't the author. Whether that's a second model, a JSON-schema'd review pass, or a human on the other end of the PR — independence is what makes the sign-off information.
• Scoped write access. The best review loops write to one branch and one PR thread. Nothing above merges, deploys, or force-pushes on its own — and none of them should.

Every loop in this directory carries a safety grade for exactly these reasons — the review category page shows the full set, graded, so you can judge the rails before you copy the prompt.

Pick one, bound it, run it

The path into review loops is the same as any loop: start with the beginner pattern that matches your actual bottleneck. If your PRs stall on comment-and-CI churn, run Address review comments, fix CI on your next PR and let it babysit the thread. If your bottleneck is trusting your own agent's output, add Audit code diffs, ship clean behind it. Graduate to the adversarial and nested patterns when a single loop stops being enough.

When you're ready to design your own, the harness builder turns a review-loop idea into a bounded, gated prompt with the exit condition and caps built in — and if your loop needs to send review summaries or PR notifications by email, ConnectMyEmail gives agents a safe, gated way to do it.

Review is watching plus judgment. Delegate the watching; keep the judgment.