A convergence gate loops review and fix until critical and high-severity findings hit zero, turning the ship decision into evidence instead of a guess.
Most code review happens once. A pull request goes up, a human or an AI assistant reads the diff, leaves some comments, and either approves it or asks for changes. The author addresses what feels most urgent, pushes an update, and the review ends there, not because every issue got resolved but because the review cycle has a natural stopping point: everyone moves on to the next thing.
A convergence gate replaces that stopping point with a condition. Instead of reviewing once and shipping on approval, you review, fix what the review found, review again, and repeat until the count of critical and high-severity findings reaches zero. The loop itself is simple, but it changes what the shipping decision actually rests on: it turns "this looks okay" into "the evidence shows this is clean," which is a much harder bar to fake.
What a Single Review Actually Misses
A single review is a snapshot of what one reviewer noticed given the time available. Human reviewers under deadline pressure tend to focus on the first few files, the diff's headline change, and whatever looks unfamiliar. AI code review has a version of the same problem: a model reading a large diff in one pass surfaces the most obvious issues (a missing null check, an unhandled error path) and quietly under-covers whatever it processed later or in less detail. Either way, a single pass produces a list of findings, not a guarantee that the list is complete. Treating that list as "the review," and shipping once it's addressed, conflates finding issues with finding all the issues that matter.
The Convergence Gate: Loop Until Critical Hits Zero
A convergence gate treats review as a process with a defined end state, not a single event. After the first review, you fix what was flagged and run review again, this time against the updated diff. If new critical or high findings show up (sometimes a fix introduces one), you fix those too, then review again. You keep looping until a review pass comes back with zero criticals and zero highs. That's convergence: not "someone looked at it," but "review kept running until there was nothing severe left to find."
The point of the loop isn't more review for its own sake. It's a stopping rule that can't be talked past: you don't get to decide the code is done, the absence of critical findings decides it.
Severity Classification Drives the Loop
The loop only works if severity is classified consistently, because severity is the only thing the loop checks. A finding tagged "critical" (data loss, an auth bypass, a crash on the main path) has to mean that every time, or the gate becomes meaningless: reviewers who want to ship faster will quietly downgrade findings to clear the bar, and cautious reviewers will inflate everything to "high" and stall the loop indefinitely. A workable scheme needs a small number of tiers with concrete, checkable definitions:
- Critical: breaks correctness, security, or data integrity on a path real users hit (auth bypass, data loss, an unhandled exception on the happy path)
- High: wrong behavior under common but non-default conditions, missing error handling on external calls, or a security gap with a narrow but real blast radius
- Medium: correctness issues confined to edge cases, or design problems that will cause pain later but don't break anything today
- Low: style, naming, minor duplication, anything a linter or a later pass can catch
Keeping the Loop From Running Forever
Only critical and high findings block the gate; medium and low findings get logged and ship with the change, which is what keeps the loop from turning into an argument about formatting. The obvious risk with "loop until zero" is that it never hits zero: a reviewer keeps finding new things, or fixes for one finding introduce another, and the cycle runs indefinitely. Two disciplines keep that from happening. First, fix the severity bar before the loop starts, not mid-loop when the count won't drop. If "critical" quietly expands to include a naming preference on iteration four, the gate stops measuring anything real. Second, fix the scope too: the gate reviews the diff for the feature being shipped, not the surrounding code the diff happens to touch. A gate that keeps widening its own scope will never converge, because there is always more code to have opinions about.
Cap iterations in practice, not just in principle. If a diff needs more than three or four review-fix cycles to reach zero criticals, the diff is usually too large. Split it and re-scope, rather than trusting a sixth pass to finally converge.
Review-Once vs the Convergence Gate
| Dimension | Review-once | Convergence gate |
|---|---|---|
| Stopping condition | Reviewer approves, or the deadline arrives | Critical and high findings hit zero |
| What "done" means | Nobody objected in the time they had | A defined bar was checked and cleared |
| Fixes for new issues | Often deferred to a follow-up ticket | Re-reviewed before shipping, not after |
| Failure mode | Severe issues slip through under time pressure | Loop can stall without a fixed scope and bar |
| Ship decision basis | Reviewer confidence, largely subjective | A finding count, checkable by anyone |
Shipping as a Decision About Evidence, Not Vibes
Review-once ships on a feeling: the reviewer read the diff, nothing jumped out, so it's probably fine. That feeling is real information, but it isn't evidence, and it doesn't hold up well in a postmortem ("it looked okay" is not a defense). A convergence gate replaces the feeling with a number: zero critical findings on the last pass, plus a record of what was found and fixed on the way there. Anyone, a teammate, an auditor, a future version of the team debugging an incident, can look at that record and see what was actually checked, not just trust that it was. This matters more as more of the review loop runs on AI agents rather than people, where each iteration should hand the reviewer a fresh diff and a fixed severity bar, not a fuzzy memory of what the last iteration's argument was about.
What the loop doesn't solve is continuity between separate work sessions on the same codebase, where an assistant with no memory of prior decisions re-litigates settled ground. That's a different problem, and tools built for it, like MemX, a private, persistent memory layer for AI, address it by keeping project context stable across sessions instead of inside a single review loop.
Where the Gate Fits in the Larger Process
A convergence gate is only as good as what feeds it. It needs a spec to review the diff against, otherwise "correct" has no reference point, and it works best with more than one independent reviewer checking the same diff for different failure classes, since a single reviewer, human or AI, tends to have blind spots that repeat across iterations. TLM Forge wires a convergence gate into that larger process: a spec audit before code gets written, multi-agent code review against both the plan and the diff, and an adversarial pass in the spirit of red-teaming your AI code that specifically hunts for the failure modes a friendly reviewer tends to miss. The full sequence is laid out on the how it works page.
Frequently asked questions
01What counts as a critical finding in a convergence gate?
Anything that breaks correctness, security, or data integrity on a path real users or systems actually exercise: an auth check that can be bypassed, data that can be lost or corrupted, an unhandled exception on the main flow. The exact definition should be written down before review starts, not decided finding by finding, or the gate stops being a fixed bar.
02Doesn't looping until zero criticals just delay shipping indefinitely?
Only if the severity bar or the scope is allowed to drift mid-loop. With a fixed bar and a diff scoped to one feature, most changes converge in two or three review-fix cycles. If a diff consistently needs many more, that's a signal the diff is too large or the spec was too vague, not that the gate itself is the bottleneck.
03Can a convergence gate work with a single reviewer instead of multiple agents?
Yes, the loop mechanic (review, fix, re-review until zero criticals) doesn't require multiple reviewers. But a single reviewer, human or AI, tends to have consistent blind spots that repeat on every iteration. Independent reviewers checking for different failure classes catch more on the first pass and converge faster overall.