# How to Make an Agentic Loop Converge in AI Code Review > Source: > Published: 2026-10-19 14:09:52+00:00 `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. 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](https://www.langchain.com/blog/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: "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. Four forces keep a review loop between a coding agent and an AI reviewer running: | 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. 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." 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: 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. 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"](https://arxiv.org/abs/2603.13870), 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." 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](https://www.qodo.ai/state-of-ai-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](https://www.qodo.ai/glossary/what-is-ai-generated-code-validation/) takes the same time but more cognitive effort. Fifty rounds of agent chatter is a lot to read with your morning coffee. 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. 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. The first one or two review rounds should read the whole PR with [repository context](https://www.qodo.ai/glossary/what-is-full-codebase-context-vs-diff-only-review/). 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. 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. 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. 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](https://dev.to/uss/how-id-run-bug-triage-on-40-defect-reports-before-a-release-lessons-from-postgres-19-4ib5) covers how I'd sort it. 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](https://www.qodo.ai/podcasts/is-ai-making-you-an-average-engineer/) (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](https://www.qodo.ai/state-of-ai-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](https://dev.to/uss/how-ai-code-review-enforces-coding-standards-in-complex-codebases-54lg). 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 ``` 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. 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](https://www.qodo.ai/podcasts/why-ai-control-is-the-new-security-standard/) (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." 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](https://docs.qodo.ai/agentic-toolbox/agentic-toolbox-overview) 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](https://www.qodo.ai/glossary/what-is-agents-md-file/) or CLAUDE.md file, and the template reads like a review loop policy: Qodo's [local pre-PR review](https://www.qodo.ai/glossary/what-is-pre-pr-and-local-code-review/), the [shift-left code review](https://www.qodo.ai/blog/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](https://docs.qodo.ai/governance/rule-enforcement/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](https://dev.to/uss/your-agent-opened-15-prs-how-to-review-ai-generated-code-as-one-work-package-5h6m) and Qodo's guide to [agentic workflows](https://www.qodo.ai/blog/agentic-workflows-in-ai-development/). 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](https://www.qodo.ai/blog/code-review-best-practices/) and its guide to [AI PR review](https://www.qodo.ai/blog/ai-pull-request-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. 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. 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. 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. 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. 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. 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.