Context
An RLCR code-review loop ran 8 rounds fixing ~15 correctness bugs in a type-system refactoring. The review quality was excellent (zero false positives), but the session lacked convergence mechanics — the same design tension resurfaced across 3 rounds, and cascading regressions inflated round count. Estimated 2-3 rounds could have been saved.
Suggestions
1. Add a recurring-issue escalation rule
Pattern: The same architectural tension produced findings in 3 consecutive rounds with different point fixes each time (whack-a-mole).
Improvement: If the same conceptual issue appears in 2 consecutive rounds, pause implementation and require a mini-design document addressing the root cause before proceeding. Converts whack-a-mole into a deliberate design decision earlier.
2. Implement a cumulative issue ledger
Pattern: Reviews evaluated code fresh each round without tracking total issues found/fixed/remaining. No convergence signal existed.
Improvement: Maintain a running ledger updated after each round: issues found (with round), issues resolved (with round), issues open. Provides a convergence signal (ledger shrinking = converging) and visibility into progress.
3. Add a "fix impact radius" check before committing
Pattern: In multiple rounds, a fix for one issue introduced a new regression caught in the next review.
Improvement: After implementing a fix, require the implementer to enumerate affected code paths. The reviewer can focus on those paths first, catching cascading regressions within the same round.
4. Define a diminishing-returns exit criterion
Pattern: 8 rounds without formal convergence. Transition to finalization was a manual decision, not a methodological trigger.
Improvement: Define exit criteria such as: "P3-or-lower for 2 consecutive rounds → finalize" or "open issues not decreased in 3 rounds → escalate to human."
5. Distinguish "newly introduced" from "previously latent" issues
Pattern: Some findings were regressions from the current fix; others were pre-existing issues now examined. These were not distinguished.
Improvement: Have the reviewer tag findings as "regression from this round" vs. "pre-existing, now examined." This helps prioritize and provides signal about iteration stability.
6. Enable plan tracking for scope control
Pattern: plan_tracked: false meant no mechanism to distinguish planned work from opportunistic review findings. Scope grew organically.
Improvement: When a plan exists, track plan items vs. out-of-scope findings. Out-of-scope findings below P1 should be logged for future work rather than addressed immediately, bounding round count.
Overall Assessment
The methodology's review quality is excellent. The weakness is convergence mechanics: detecting stagnation patterns, bounding scope, and defining exit conditions. Sessions with these improvements would likely converge in 2-3 fewer rounds.
Context
An RLCR code-review loop ran 8 rounds fixing ~15 correctness bugs in a type-system refactoring. The review quality was excellent (zero false positives), but the session lacked convergence mechanics — the same design tension resurfaced across 3 rounds, and cascading regressions inflated round count. Estimated 2-3 rounds could have been saved.
Suggestions
1. Add a recurring-issue escalation rule
Pattern: The same architectural tension produced findings in 3 consecutive rounds with different point fixes each time (whack-a-mole).
Improvement: If the same conceptual issue appears in 2 consecutive rounds, pause implementation and require a mini-design document addressing the root cause before proceeding. Converts whack-a-mole into a deliberate design decision earlier.
2. Implement a cumulative issue ledger
Pattern: Reviews evaluated code fresh each round without tracking total issues found/fixed/remaining. No convergence signal existed.
Improvement: Maintain a running ledger updated after each round: issues found (with round), issues resolved (with round), issues open. Provides a convergence signal (ledger shrinking = converging) and visibility into progress.
3. Add a "fix impact radius" check before committing
Pattern: In multiple rounds, a fix for one issue introduced a new regression caught in the next review.
Improvement: After implementing a fix, require the implementer to enumerate affected code paths. The reviewer can focus on those paths first, catching cascading regressions within the same round.
4. Define a diminishing-returns exit criterion
Pattern: 8 rounds without formal convergence. Transition to finalization was a manual decision, not a methodological trigger.
Improvement: Define exit criteria such as: "P3-or-lower for 2 consecutive rounds → finalize" or "open issues not decreased in 3 rounds → escalate to human."
5. Distinguish "newly introduced" from "previously latent" issues
Pattern: Some findings were regressions from the current fix; others were pre-existing issues now examined. These were not distinguished.
Improvement: Have the reviewer tag findings as "regression from this round" vs. "pre-existing, now examined." This helps prioritize and provides signal about iteration stability.
6. Enable plan tracking for scope control
Pattern:
plan_tracked: falsemeant no mechanism to distinguish planned work from opportunistic review findings. Scope grew organically.Improvement: When a plan exists, track plan items vs. out-of-scope findings. Out-of-scope findings below P1 should be logged for future work rather than addressed immediately, bounding round count.
Overall Assessment
The methodology's review quality is excellent. The weakness is convergence mechanics: detecting stagnation patterns, bounding scope, and defining exit conditions. Sessions with these improvements would likely converge in 2-3 fewer rounds.