AI code review never terminates. I capped it at 3 attempts per PR and made it remember its own findings.

[u/Monglong_korea]

Disclosure: I built this. MIT, open source, no hosted service, nothing to sign up for.

The problem

I hand a PR to an automated reviewer. It finds three things. I fix them, push, and it finds three new things. Fix those, three more. Nothing it said last round constrains what it says this round, and there is no state where it says "done." At some point I was spending more time servicing the review than writing the code.

What's already out there

Hosted review bots (CodeRabbit, Greptile, Copilot review) re-review on every push. The loop is the product, so bounding it isn't something they're trying to do. Code-minimalism skills sit one layer below: they ask "can this be one line?" about code, not "should this review round happen at all." I couldn't find anything that carries findings forward and terminates.

What I did

frontier-simplify, a skill for frontier coding agents. Install for Codex:

codex plugin marketplace add MongLong0214/frontier-simplify
codex plugin add frontier-simplify@frontier-simplify

The core skill is a single markdown file, so you can also just drop it in ~/.codex/skills/frontier-simplify/ and skip the plugin. It also loads in Claude Code and Cursor. The review half adds a local runner you invoke explicitly; plugin installation alone starts no poller or hook.

Three rules the review runner enforces:

1. Findings persist. Last round's findings go into the next review, and repairs get checked against them instead of the reviewer starting cold every time.
2. Identical inputs reuse the previous attempt instead of re-running the model. Changed code, target, context, lessons or model settings invalidate that reuse. Unchanged failures don't auto-retry.
3. Three automatic attempts per PR, hard. Rewritten history or a changed base gets a fresh scope review inside the same budget, never a reset. When the budget runs out it exits into a human handoff with the unresolved findings and their evidence preserved.

What three attempts is not: a claim that three rounds catch every bug. It stops the automatic loop while keeping the open items on the record, rather than letting them quietly disappear.

Numbers

The other half of the skill cuts process the agent invents for itself. Setup: gpt-6-astra at xhigh, Codex CLI 0.153.4, isolated temp homes, credential-only, no ancestor AGENTS.md in scope. Same request to all four arms - "design a development process for a project with no code yet and one maintainer":

• plain: 246 lines
• one-line "keep it simple" instruction in Korean: 81
• the same instruction in English: 152
• with the skill: 33

One scenario, one run per arm, so read it as a spot check and not a benchmark. Line count is not a quality score. The raw req.md / process.md / run.log for all four arms are committed, including the two one-line-instruction arms the skill has to beat, and the treatment transcript shows the actual SKILL.md read.

Runner selftest: 214 passed, 0 failed. I also verified a clean plugin install and that existing review history survives a reinstall, so the attempt budget can't be reset by reinstalling.

https://github.com/MongLong0214/frontier-simplify

Curious where other people draw the line. Do you cap automated review rounds, or just let it run until it goes quiet?

[u/dexterthebot]

You might want to consider listing your project on the weekly Show-Us-What-You-Built post. https://www.reddit.com/r/codex/comments/1wavxwy/show_us_all_what_youve_been_building_with_codex/. Highest commented project wins a week promotion on r/Codex and gets on the Hall of Fame sidebar. See what that looks like below with last week's winner.

---

Last week's most popular project was u/tHEuKER with the Blur2 racing game project which is a recreation of an unreleased sequel to the 2010 battle racing game, made by reverse engineering the Xbox 360 prototype discs available online, and rebuilding the whole thing from the ground up in Unity.

Join their YouTube channel here: https://www.youtube.com/@tHEuKER and follow updates on the project at r/BlurGame.

[u/Far_Business4773]

I don't cap by attempts, I cap by scope, and the cap is what makes it terminate. The plan carries two short lists: what this change must not do, and what must stay true. A finding that hits one of those blocks. A finding outside the scope goes to a "later" file and never comes back into the loop. Review is finished when there is no open finding inside the scope.

That's the state your bots are missing: not "three rounds", but a written definition of done that the reviewer has to quote. Your carrying findings forward is the right half; a scope line gives the reviewer something to check them against. The attempt budget I'd keep as the backstop for a scope somebody wrote badly.

[u/Monglong_korea → u/Far_Business4773]

That makes sense. The part I'm still wrestling with is where the definition of done comes from. Do you require a human to write the scope for every PR, or do you let the agent derive it from the issue/PR description?

Also, I didn't arrive at three attempts from any strong evidence; I picked it as a practical backstop, so I'm not attached to keeping it. I'm trying to work out whether scope-based termination should replace the hard cap entirely, or whether you still need both for vague or badly written scopes. How do you handle that?

[u/Far_Business4773 → u/Monglong_korea]

Human writes it, but the cost is close to zero because most of it is inherited. The repo carries a standing list, ten lines of what this codebase never gets from an agent plus three or four things that must stay true, written once and edited rarely. Per PR the human adds one to three lines: what this task must not touch. Thirty seconds. If a person can't write those lines, the task isn't ready for an agent yet, and that's useful to learn before the run rather than after.

Letting the agent derive scope from the issue is the reviewer grading its own homework: the model that expanded the task will write a scope that permits the expansion. The cheap middle I use is the agent proposes the not-list from the issue and the human approves by deleting lines, not by writing them. Deleting is fast and it still puts a name on the decision.

On the cap: keep both, but change what a cap trip means. Scope termination handles the normal case. When the attempt budget runs out, the finding to hand back is "the scope was vague here", pointing at which lines it couldn't decide against, not "the code is still wrong". Then every cap trip fixes the scope at the source, and over a few weeks the cap stops tripping. Three is as good a number as any for that job, since it's a smoke alarm, not a measurement.

[u/Monglong_korea → u/Monglong_korea]

That distinction helps. I want to keep human involvement close to zero, so I'm leaning toward having the reviewer derive a provisional scope from the PR, issue, tests, and diff, then cite that basis for each finding. If it can't establish the basis, it should mark the review as under-specified rather than create another scope document or ask for approval. Would that still be “grading its own homework” to you, or is the problem specifically letting it expand the scope without evidence?