Your AI Reviewer Needs a Scope Limit

Repeated review can uncover defects that were already present before the pull request began. A pull request is a proposed code change submitted for review. If every discovery becomes a required edit inside that proposal, its purpose keeps changing while the author tries to finish it.

Developers Digest's account of the Claude Code team's review process describes an author and reviewer getting stuck in repeated repairs. Looking back through the code's history showed that many findings concerned older code. The article describes limiting review rounds, narrowing later passes to subsequent edits and avoiding repeated reports of the same finding.

That's a useful distinction for anyone buying agent-run delivery. Finding a real bug doesn't automatically make it part of the current assignment. The report deserves investigation, but someone still has to decide whether the proposed change depends on fixing it. Without that decision, a reviewer can become an unplanned project manager.

The first review should establish whether the proposed behavior is correct, what the change affects and which findings must be resolved before it can proceed. Record the starting version of the code alongside the reviewed version. That gives later reviewers a stable comparison instead of a moving target.

For each finding, ask what fails, what evidence shows the failure and how it relates to the change. Distinguish a newly introduced defect, an existing defect exposed by the new behavior and an unrelated problem discovered nearby. The distinction determines where the repair belongs; it doesn't determine whether the bug matters.

Gunner Technology recommends recording whether each finding belongs in this change and what happens next. A reviewer can propose it; an accountable owner settles disputed scope. Our post Code Review Needs a Named Job explains why each review needs a specific decision. Here the decision is whether this defect must be fixed for this change to ship.

Later rounds should check whether the requested repairs worked and whether those repairs introduced problems of their own. Review the new edits in their surrounding context, including callers and dependencies where needed. Narrowing the question doesn't mean hiding the rest of the system from the reviewer.

Consider a hypothetical export change. The initial review finds that a new filter drops records the requirement says to include. The author repairs it. A later pass should verify the filter and its consequences. If that pass also discovers an old display defect on an unrelated settings page, put the discovery through triage rather than automatically adding a settings rewrite to the export work.

Keep required checks running across the affected system. Continuous integration, or CI, is the automated build and verification process run when code changes. A narrower review assignment doesn't justify dropping a required CI check. Nor should a reviewer repeat a resolved finding without explaining what new evidence makes the earlier resolution insufficient.

An existing bug should block the change when the new behavior relies on it, makes its consequences worse or violates a release condition that still applies. Age isn't permission to ship. A defect in shared access control may be old and still make a new export unsafe.

Route an unrelated finding to an owned issue with the reproduction, affected behavior and reason it sits outside this pull request. If it presents an urgent security problem, use the authorized incident route. Moving a finding out of the current review must leave a visible destination and someone responsible for the next decision.

Don't let the authoring agent dismiss a blocker by labeling it pre-existing. Preserve the evidence and require the authority appropriate to that consequence. People decide what gets built and judge whether the returned work is right. Agents can investigate and repair within that decision; they shouldn't negotiate away its conditions.

Pause the repair loop and ask whether to change the approach, split the work or reject the attempt. A round cap limits further attempts; it doesn't turn unresolved findings into approval. Keep the release blocked wherever required evidence or decisions remain missing.

The workflow should preserve the remaining findings, attempted repairs and reason the work still isn't ready. Send the owner a concrete choice instead of a transcript. Our post Done Is a Factory Decision covers the broader stopping rule. For review, make sure opening a replacement session cannot quietly restart the same repair budget.

Start with a recurring change in a repository you own. Track why work returns for repair and whether later findings concern the proposal or unrelated code. The article describes a process used in a particular team; it doesn't establish the right limit for yours. Choose that limit deliberately, then make the factory stop when it reaches it.