Original Reddit post

I think AI code review has a stopping-condition problem I’ve been using a workflow where one agent builds and another agent reviews. At first it felt obviously safer: Claude builds → reviewer finds something → Claude fixes it → reviewer runs again. The problem is that a good reviewer can almost always find something else . Another edge case. A test that could be stronger. A contradiction in the spec. A cleaner abstraction. Something that wasn’t verified against the actual code. And the annoying part is that many of those findings are real. So “keep reviewing until nothing else is wrong” seems like an almost infinite specification. I don’t think “maximum 2 review rounds” solves it either. That just replaces an infinite stopping condition with an arbitrary one. What I’m experimenting with instead is defining the stopping condition before the review. For example, before accepting a change I might define: B1: acceptance criteria are satisfied B2: existing behavior X has not regressed B3: the change cannot corrupt persisted state B4: the relevant failure path is recoverable Then, for each one: What evidence would actually be sufficient? What source has authority over that property? What observation would prove the claim false? That also changes how I treat findings. If the reviewer finds a naming issue or another possible defensive test, that may be worth fixing — but it doesn’t automatically reopen the decision. I’m separating findings into roughly: BLOCKER Falsifies or leaves unsupported something required for the current decision. BACKLOG / YELLOW A legitimate improvement that doesn’t currently block the decision. So GREEN no longer means: “Nothing else can be improved.” It means: “The claims required for this decision have sufficient evidence and there’s no unresolved material evidence contradicting them.” One other thing I’m becoming increasingly suspicious of: letting the same agent modify both the implementation and the tests and then treating a green test suite as independent evidence. I’m starting to preserve some baseline evidence before the change — old tests, acceptance criteria, fixtures, known invariants, commit state — and then checking the new implementation against evidence it wasn’t allowed to redefine. I’m still testing this approach, so I’m interested in where it breaks. For people doing Claude Code + Codex/Gemini/another reviewer: What is your actual stopping condition? Not “when the reviewer says it’s good.” What specifically makes you decide that another review round is no longer worth doing? submitted by /u/piratastuertos

Originally posted by u/piratastuertos on r/ClaudeCode