The loop terminates on one condition: the reviewer finds nothing [1]. So the reviewer's standard of proof, not the issue text, sets how much code gets written. Findings become fixes, fixes are new code, and new code is new surface for the next round of findings [6]. The only damping term in that circuit is whatever the reviewer declines to say.
Scope narrowing came first, by hand: do not cover unrealistic manual state tampering, inputs that are never generated in practice, or defense in depth that assumes an attacker [8]. That is a denylist, and its coverage is exactly the length of the list, which is why the author calls it a symptom fix [9]. Every new category of speculative concern needs a new clause.
The replacement changes the reviewer's output obligation rather than its topic list. Each finding has to arrive with a concrete failure scenario written as input or state, execution path, failed result [15]. In the author's phrasing, the reviewer must write down how you would operate the app to hit the problem [21]. Consider the finding about an attacker writing an invalid due date straight into the database [4]. The state it needs comes from writing to the database, so there is no first field to fill in by operating the app. It dies at the form check without anyone having to ban the topic [12]. Defense in depth against someone who already has write access to your database describes a different system, which is close to the author's own objection [5]. Vague findings go the same way, since "I am worried about this" has no execution path [16].
Semi-formal reasoning, from a March 2026 paper by Ugare and Chandra, keeps the reasoning in natural language but forces it into a five-part certificate: function trace table, data flow analysis, evidence-backed semantic properties, alternative hypothesis check, and a conclusion drawn only from the first four [10][11]. The post reports the abstract's numbers as patch equivalence accuracy rising from 78 to 88 percent, and 93 percent on patches generated by agents [13]. Read that as a claim about someone else's task. Patch equivalence is a decision about two versions of code; a review finding is a generated assertion about one. On the paper's task the error rate falls from 22 percent to 12 percent, so a bit under half the errors go away [20], and the agent-patch figure is the one nearest this workload, since every patch in the loop is agent-written [1]. For the number to carry you would have to be judging equivalence and running all five parts, and this setup does neither [14].
What kept the full certificate out is a constraint unrelated to accuracy: the author reads every review result by hand, and five sections per finding is too much to read [14]. That is the real budget line in a human-in-the-loop setup. Output length is paid on every iteration by the one reader who cannot be parallelised. A single prompt line that removes an entire class of finding is cheap against that budget; a certificate template is not.
The transferable part is narrow. Write the reviewer's definition yourself, because an agent asked for a perfect reviewer produces the most thorough one available, and thoroughness lands as implementation size [7]. Then make each finding carry a witness. The post itself was drafted by an agent working to the author's structure and rewritten by hand [18], which is a fair description of the arrangement it recommends.
