DEV Community

Cover image for How to Make an Agentic Loop Converge in AI Code Review
Anna
Anna

Posted on

How to Make an Agentic Loop Converge in AI Code Review

TL;DR

  • On October 15th, Anthropic's Claude Code team wrote that one pull request (PR) went through "more than fifty rounds of review and fixes overnight before its author stopped it." The agentic loop between their coding agent and their AI reviewer had no exit.
  • When the Claude Code team ran git blame on what their reviewer kept flagging, about 59% was code that had been there since the reviewer's first pass. Late rounds were mostly finding old bugs.
  • A paper by Ruihan Lin and Jiheng Zhang, revised in September, treats AI review as a capacity decision. In their calibrated study, a review-everything rule fell up to 57.6% short of the best plan when maintainers weren't the bottleneck.
  • My recipe for an agentic loop in AI code review: cap the rounds, re-review only the new diff, flag bug classes, never repeat a finding, label pre-existing code and turn repeat findings into rules.
  • Qodo builds the exit into the loop. Its Agentic Toolbox tells coding agents to run one review-and-fix pass by default, stop when another round won't make meaningful progress, and give every finding an explicit outcome.

What an Agentic Loop Looks Like in AI Code Review

An agentic loop is a model calling tools in a cycle until a task is done: act, check the result, act again. Sydney Runkle of LangChain describes a second layer in The Art of Loop Engineering (June 16th): a verification loop, where a grader checks the agent's output and sends feedback when it falls short. An AI reviewer on a pull request is that grader.

The agentic loop in AI code review has two agents in it:

  1. A coding agent writes the change and opens a PR.
  2. A code review agent reads the diff and posts findings.
  3. The coding agent fixes every finding and pushes a commit.
  4. The new commit triggers another review, until the reviewer comes back clean.

"Until the reviewer comes back clean" is the weak spot of the review loop. It assumes the AI reviewer eventually runs out of things to say. Two language models can keep each other busy all night, and nobody is awake to call time.

Why a Review Loop Between Two Agents Doesn't Stop on Its Own

Four forces keep a review loop between a coding agent and an AI reviewer running:

  • Agents fix nits. Anthropic's Claude Code team put it plainly in their October 15th post: "A person can wave off a nit in seconds. An agent fixes it, which means another commit and another round of review."
  • Each round re-reads old code. A full re-review reads the whole PR again, including lines that were there in round one.
  • Agent runs are random. Bjarni Haukur Bjarnason, André Silva and Martin Monperrus studied 60,000 agent runs for On Randomness in Agentic Evals (revised March 25th). Scores varied even at temperature 0, and runs on the same task diverged "often within the first few percent of tokens." My reading: a fresh review pass over the same code won't land on the same findings either.
  • Reviewers reject good work. In the SWE-Review benchmark data (July 7th) that Ruihan Lin and Jiheng Zhang used to calibrate their paper, the AI reviewer asked for revisions on 5.8% to 25.9% of changes that already resolved their issue, depending on the generator. Each false rejection buys another round.

Signs Your Agentic Loop Will Converge or Run All Night

Signal Loop that converges Loop that runs all night
Round limit Hard cap, then the author steps back None
What re-review reads Only the diff since the last round The whole PR, every round
Repeated findings Never posted twice Same finding, new wording
Finding scope One finding per bug class One comment per line
Code the PR didn't touch Labelled pre-existing, not blocking Treated as the author's bug
Exit condition No new blocking findings Reviewer runs out of things to say

The right-hand column of the convergence table is the default when you wire a coding agent to an AI reviewer and change nothing else.

What the 50-Round Pull Request Teaches About Review Loops

Anthropic's Claude Code team described its review flow in an October 15th post by Addy Osmani, Morgan Westlee Lunt and Qing Wang. On their PRs, every finding has to be fixed or resolved with a reason, and "often an agent picks up the fix overnight." One CLI (command-line interface) PR went through more than fifty rounds that way before its author stopped it. The post's verdict: "Review has to converge."

The git blame result is the part of the 50-round story that matters most for anyone building an agentic loop. About 59% of what the reviewer kept flagging was code that had been there since its first pass. In the Claude Code team's words, "The reviewer was rarely finding new bugs, it was finding a few more old ones each round."

Agentic loop in AI code review: about 59 percent of what the reviewer kept flagging was code that had been there since its first pass

The stacked bar shows what the reviewer's repeat flags were made of in the 50-round story. The big block, about 59%, points at code the reviewer had already read in round one, which was never part of any later fix.

The Claude Code team admitted they had "gotten used to running several rounds by default, since each pass catches something new." Their fix had four parts:

  • A round cap. After three rounds, the reviewer asks the author to step back and reconsider the approach.
  • Diff-only re-review after the first few passes.
  • Bug classes. The reviewer flags the class of bug, so the author fixes every instance in one go.
  • No repeats of findings already posted.

The Claude Code team now tracks rounds-to-pass alongside recall, and their written priority is "catching real bugs first and cutting review rounds second." I like that order. A review loop that converges in one round but misses the bug hasn't saved anyone time.

Why More AI Review Rounds Can Cost More Than They Catch

Ruihan Lin and Jiheng Zhang, researchers at the Hong Kong University of Science and Technology, model the path from coding agent to human approval as a queue in "When to Screen, When to Bypass: LLM-Judges in Resource-Scarce AI-Human Workflow", first posted March 14th and revised September 16th. Their headline: "AI review is a capacity decision as much as an accuracy decision."

Ruihan Lin and Jiheng Zhang split AI reviewer mistakes into two kinds, and each one bills a different resource. A false acceptance passes a defective change and costs maintainer time later. A false rejection sends a merge-ready change back and costs another coding-agent run.

The Lin and Zhang calibrated study puts numbers on the trade-off. A rule that reviews everything fell up to 57.6% short of the best plan when maintainers weren't scarce, and adaptive routing beat both "always review" and "never review" on 62.7% of the capacity grid. The paper even finds a phase where "an informative reviewer is deliberately left idle because its rework displaces new work."

Agentic loop economics: as human reviewer capacity grows, the best share of AI review moves from full review to throttled review to bypass

The phase chart shows the four regimes in Ruihan Lin and Jiheng Zhang's single-category model as maintainer capacity grows: full review, reviewer saturation, deliberate throttling and bypass. In the throttling phase a good reviewer gets held back, because its false rejections eat coding-agent time. The paper studies routing, not round caps, but my reading for review loops is simple: every extra review round has a price, even a round that finds something.

Human attention is the other bill an overnight review loop runs up. For Qodo's code quality report, Censuswide surveyed 500 U.S. developers at organizations already using AI meaningfully in the software development lifecycle (August 2026), and 36.4% said reviewing AI-generated code takes the same time but more cognitive effort. Fifty rounds of agent chatter is a lot to read with your morning coffee.

6 Rules to Make an Agentic Loop Converge in Code Review

These are the six rules I'd write into any agentic loop where an AI reviewer talks to a coding agent. Rules 1 to 4 come from the Claude Code team's fix. Rules 5 and 6 are my additions.

1. Cap the Rounds, Then Make the Author Step Back

Give the review loop a hard number. The Claude Code team uses three rounds, and that's where I'd start. At the cap, the question changes from "what's wrong with this line?" to "is this the right approach?" Send the PR to a person with a summary of what's open and where agent and reviewer disagree.

2. Re-Review Only the New Diff After the First Passes

The first one or two review rounds should read the whole PR with repository context. After that, the reviewer reads only the commits since its last review, plus the code they touch. Diff-only re-review goes straight at the 59% problem: code the reviewer already read stops coming back as fresh work.

3. Flag the Class of Bug, Not One Line

Four comments about four missing timeouts become four fixes, four commits and four more reviews. One finding that says "outbound HTTP calls in these 4 handlers have no timeout" becomes one commit. Ask your code review agent to group findings by bug class and list every location.

4. Never Repeat a Finding, and Remember Decisions

Give every finding a stable ID and keep a ledger of what the reviewer already posted. When the author resolves a finding with a reason, such as "intended, see architecture decision record ADR-12," the next round should read that reason and stay quiet. Without a ledger, the same finding comes back in new words and the coding agent "fixes" it again.

5. Label Pre-Existing Code Instead of Blocking on It

Bugs in lines the PR didn't touch are real, but they don't belong to this PR. Label them pre-existing, file them and keep them out of the exit condition. If that pile gets big, my bug triage guide for AI review findings covers how I'd sort it.

6. Move Repeat Findings Into Rules and Lint

When the AI reviewer flags the same thing across many PRs, fix it at the source. The Claude Code team does that with a skill, a lint rule or an update to their instruction files. Deterministic checks go in lint, and conventions go in rules the coding agent loads before it writes code.

Liz Fong-Jones, Technical Fellow at Honeycomb, said on The Agentic Review podcast (September 30th) that "it's a waste of your human's time to be acting as human linters," and that "part of code review is toil." A coding agent re-fixing the same convention every round is toil with a token bill.

Loading rules up front matters because coding agents don't always follow standards on their own. In Qodo's code quality report, only 34.6% of the 500 surveyed U.S. developers said agents always follow organizational standards. I wrote more on that in how AI code review enforces coding standards.

A Review Loop Policy You Can Copy

Here's the six-rule review loop policy as config. The YAML isn't any tool's format; treat it as a spec for whoever wires your coding agent to your AI reviewer.

# review-loop.yaml: stop rules for an agent-to-agent review loop
review_loop:
  max_rounds: 3                    # rule 1: hard cap
  on_cap: summarize_and_ask_human  # what's open, what was tried, disagreements
  full_review_rounds: 2            # rule 2: rounds 1-2 read the whole PR
  later_rounds_read: diff_since_last_review
  findings:
    group_by_bug_class: true       # rule 3: one finding, every location
    skip_already_posted: true      # rule 4: stable IDs in a ledger
    respect_resolved_reasons: true
    preexisting_code: label_only   # rule 5: file it, don't block on it
  exit_when:
    - no_new_blocking_findings
    - same_findings_as_last_round  # no progress, so stop
  propose_rule_after_repeats: 3    # rule 6: seen on 3+ PRs, make it a rule
Enter fullscreen mode Exit fullscreen mode

Agentic loop flowchart for AI code review: each round checks the cap, new blocking findings and progress before the coding agent fixes again

The flowchart shows the three exits every review loop needs: the round cap, "no new blocking findings" and "no progress since last round." Only one path goes back to the coding agent, and it passes all three checks first.

How to Measure Whether Your Review Loop Converges

Rounds-to-pass is the first number to watch, next to recall, because a loop that converges by missing bugs is just a quiet loop. Here's the dashboard I'd build for an agentic loop in AI code review:

Metric What it tells you Healthy direction Where to get it
Rounds-to-pass How long agent and reviewer argue per PR Down, mostly 1 to 2 Review events per PR
Cap hits per week PRs where the approach is the problem Low, each read by a person Loop logs
Repeat-finding rate Findings posted again in a later round Near zero Ledger with stable IDs
Findings on pre-existing lines Reviewer re-mining old code Down after diff-only re-review git blame on flagged lines
Dismissed as wrong or intentional Reviewer noise Down as rules improve Resolution reasons
Recall on known bugs Whether the cap hides real misses Flat or up Replay of past incident PRs

The "dismissed as wrong or intentional" row in the review loop dashboard is the cheapest noise signal you have. Anthropic's Claude Code team sorts every reviewer comment by how the person on the PR responded: fixed, wrong, intentional or didn't matter. With two agents in the loop, the coding agent's skip reasons give you the same data.

Gil Elbaz, co-founder and Chief AI Officer at Onyx Security, raised the cost of agents talking to agents on The Agentic Review (July 22nd). Gil Elbaz asked whether many agents talking to each other nonstop pays off, and answered: "Maybe. But maybe there needs to be certain rules in place and guardrails in place around that as well." Itamar Friedman, co-founder and CEO of Qodo, replied: "We call it bot gossip."

Where Qodo Fits in a Converging Review Loop

Qodo is the AI code review platform I'd put inside any agentic loop, because Qodo treats convergence as part of review. The Qodo Agentic Toolbox brings Qodo review, rules and codebase context into the coding agent you already use, through a CLI, MCP (Model Context Protocol), plugins for Claude Code and Codex, and Kiro Power.

As of October 2026, the Qodo Agentic Toolbox ships a default template for your AGENTS.md or CLAUDE.md file, and the template reads like a review loop policy:

  • "Perform one review-and-fix pass by default."
  • "Continue with another round when it is useful to validate meaningful fixes or when the user requests it, within an agreed limit."
  • "Evaluate every finding against the code and intent; fix only findings that are sound and in scope."
  • Finish when the findings are addressed or another round wouldn't make meaningful progress, "and report what remains."

Qodo's local pre-PR review, the shift-left code review step of the loop, takes the coding session's context along with the diff: intent, key decisions and links to the ticket or design. Qodo's docs name a use for that context that matches the never-repeat rule: "Record deliberate decisions so the reviewer does not re-flag them as issues."

Qodo's Review Resolver skill closes the loop on the PR side. The coding agent resolves only the findings you scope, by severity, category or a single finding, and every Qodo finding ends as fixed, skipped with a reason or reported without changes. Nothing is silently ignored.

Qodo also turns repeat findings into rules. Qodo's Rule Miner learns rules from review comments developers accepted and acted on, and dismissed suggestions weaken an active rule's signal over time. Qodo's rule analytics show how often each rule passes, gets violated or gets merged anyway, so noisy rules show up before they feed another loop.

Itamar Friedman, co-founder and CEO of Qodo, said on The Agentic Review with Liz Fong-Jones: "maybe we will almost completely rely on AI code review agents, AI quality agents, to work together with the coding agent in tandem." Qodo's loop defaults give that tandem a stop condition. For review across many agent PRs, see my piece on reviewing 15 agent PRs as one work package and Qodo's guide to agentic workflows.

Conclusion: Give Every Agentic Loop an Exit

A coding agent and an AI reviewer will happily trade commits until morning. The 50-round PR from Anthropic's Claude Code team shows the pattern, and the git blame result shows the cause: late rounds mostly dig up old code.

Write the exit before you wire the agentic loop. Cap rounds at three, re-review only the new diff, group findings by bug class, keep a ledger, label pre-existing code and turn repeat findings into rules. Then watch rounds-to-pass next to recall. For the human side, Qodo's code review best practices and its guide to AI PR review are good next reads.

What's the highest round count you've seen between your coding agent and your reviewer? Tell me in the comments.

FAQ About Agentic Loops and AI Code Review

What is an agentic loop in AI code review?

An agentic loop in AI code review is the cycle where a coding agent writes a change, an AI reviewer posts findings, the agent fixes them and the reviewer checks again. The loop ends on a stop condition such as a round cap or no new blocking findings. Qodo's Agentic Toolbox runs one review-and-fix pass by default and stops when another round wouldn't make meaningful progress.

How many review rounds should a code review agent run?

A code review agent should run one or two full rounds and stop at a hard cap, such as three. Anthropic's Claude Code team caps at three rounds, then asks the author to step back. Qodo's default template allows extra rounds only within an agreed limit and reports what remains.

What is loop engineering?

Loop engineering is the practice of designing the loops around an AI agent: the agent loop, verification loops with a grader, event triggers and stop conditions. A review loop between a coding agent and an AI reviewer is a verification loop. Qodo acts as that grader, and every Qodo finding ends as fixed, skipped with a reason or reported.

How can AI code review avoid generic noise?

AI code review avoids generic noise with repository-specific context, team rules and a memory of decisions already made. Qodo reviews with your codebase context and Review Standards, and its pre-PR review records deliberate decisions so they aren't flagged again.

Could AI review findings create another bottleneck for the team?

AI review findings create a bottleneck when every finding triggers a new commit and a new round, or when findings pile up for a person in the morning. Round caps and diff-only re-review tie the finding count to new code. Qodo gives every finding an explicit outcome, so a person reads a short summary instead of a long thread.

How do we manage human review capacity when agents write most of the code?

Manage human review capacity by letting the agentic loop handle routine findings and sending people the PRs that hit the cap or touch risky code. Qodo runs review before and after the PR exists, so human time goes to design calls.

Top comments (0)