← All articles

A findings ledger that stops a review loop from adding new blockers

The Guildwise HQ team · 2 November 2026 · 6 min read

• How-to
• LLM ops

A review loop that sends a change back each round with a new, narrower issue usually has two gaps. The first is memory: the loop does not keep a clear record of what has already been raised, fixed and checked. The second is the rule for what may block a change. If every comment can hold the change, a reviewer can always find something smaller to block on.

This article covers a practical fix: a findings ledger, a rule for what can block after the first round, and an end condition for the loop. The rules below are a proposal for a small team, not a published standard. Each one is tied to a public source where one exists.

Why the loop keeps finding smaller issues

A review loop has no natural end. Each round, the reviewer reads the change again and may find something it did not flag before. If nothing is recorded as settled, earlier points are easy to reopen, and new points are easy to add as blockers.

Google's engineering practices describe a different standard for approval. The reviewer's main job is to keep the overall code health of the codebase improving. The reviewer should approve once a change clearly improves code health, even if it is not perfect. The same guidance says this does not justify approving a change that makes the system worse. Both halves of that standard matter for an automated loop. The loop should not stop at a change that is still harmful, and it should not hold a change for a point that does not affect health.

Step 1: Record every finding in a ledger

Give each finding a record. The minimum fields are:

• an ID that does not change between rounds
• the round in which the finding was first raised
• a short label that says whether it is a defect, a question, a suggestion or a style point
• a blocking flag
• a state: open, fixed and verified, withdrawn, or deferred to a follow-up

A worked example from a hypothetical change, using the same fields:

F3 is a regression caused by the fix for F1. That is a legitimate reason to block. F4 is an improvement idea, and it should not hold the change. Without the ledger, F4 can be promoted to a blocker in round three, and F1 can be raised again in round four with no record that it was fixed.

Step 2: Limit what can block after round one

After the first round, a new blocking finding should fall into one of three groups:

• a defect in lines the author changed since the last round
• a regression introduced by a fix to an earlier finding
• a reopened ledger item, with evidence

Anything else is recorded as non-blocking and added to the follow-up list. A reviewer who wants to block on a new point should show that it is a defect in this change, not only that it is new.

The rule does not stop reviewers from raising real problems. It makes narrowing visible. If a loop keeps producing blockers that fit none of the three groups, the ledger shows it within a round or two, and the team can review the reviewer's instructions rather than the code.

Step 3: Reopen items only with evidence

A closed item reopens only when the reviewer cites its ID and states what the fix still gets wrong. Closed items stay in the ledger. Deleting them brings back the memory gap that drives the loop.

GitHub's documentation on reviewing proposed changes describes how reviews and requests for changes are recorded on a pull request. A ledger can mirror that record, so a person reading the pull request can see the same history the automated loop used. Keep the ledger and the pull request thread consistent. When a finding is closed, record the commit that fixed it.

Step 4: Set an end condition

Self-Refine is a published method in which a language model writes an output, critiques it, and revises it using its own feedback. The paper describes an iterative refinement loop across several tasks. Its loop is useful for drafting, but it leaves the stop rule to the implementer. For review, the stop rule matters more, because an unbounded loop keeps producing findings.

A workable rule set for the review loop:

1. The loop ends when no blocking item is open.
2. If blocking items are still open after a fixed number of rounds, a named person decides. The options are to merge with follow-ups, split the change, or stop.
3. The decision and its reason are written into the ledger.

The round limit is a setting to tune. Three rounds is a starting point chosen for this example, not a figure from any source. Pick a number, use it for a month, and check how many changes reached the limit and why.

Step 5: Keep the change small and the reviewer grounded

Two other settings reduce the rate of narrow issues.

First, keep changes small. The engineering practices book from Google names keeping changes small as one of the most important practices for keeping code review fast. A smaller change gives the loop fewer places to find a new issue, and each round covers less code.

Second, give the reviewer the context it needs. A reviewer that does not know the project's conventions or the reason for the change is more likely to raise points that are outside the scope of the change. Practical steps:

• Give the reviewer the project's contribution rules and the design notes for the change.
• Ask each finding to name the lines it relies on. A finding that depends on code outside the diff should say so and explain why the outside code matters.
• Sample a few rounds each week and check whether the blockers were real defects. Use the sample to adjust the reviewer's instructions, not to add more rules to the loop.

A short checklist

• Each finding has a stable ID, a round, a label, a state and a blocking flag.
• After round one, new blockers must be in one of the three groups.
• Closed items reopen only with an ID and evidence.
• The loop has a round limit and a named decision owner.
• Changes are kept small enough that one round covers a reviewable amount of code.

The loop does not need to be perfect. It needs a record that both the reviewer and the author can read, and a rule that says when the change is done.

Key takeaways

• A review loop keeps producing narrow issues when nothing records what is settled and any comment can block.
• A findings ledger with stable IDs, labels, states and a blocking flag gives every round the same memory.
• After round one, only defects in new lines, regressions from fixes, or evidenced reopenings should block.
• Set a stop rule with a round limit and a named decision owner, and record the decision in the ledger.

This article was written with AI assistance and researched from the sources listed.

Sources

1. Google Engineering Practices: Code Review Developer Guide
2. Google Engineering Practices: The Standard of Code Review
3. Software Engineering at Google: Code Review
4. Self-Refine: Iterative Refinement with Self-Feedback
5. Reviewing proposed changes in a pull request

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.