The cheapest review comment to answer is the one nobody had to write. If a run opens a pull request the instant the model stops typing, every broken test, every leaked key and every convention slip becomes a human's problem — and reviewing machine output is already less rewarding than reviewing a colleague's.
So a run does not finish when the code is written. It finishes when it has tried to find its own faults.
Does it actually run?
First the project's verify command — whatever you already use, a test suite, a build, a linter, a shell script. If it fails, the failure text goes back to the agent as the next instruction, and it tries again. The default is two attempts.
This is the only gate that can fail the run outright. A change that does not build is not a pull request, it is a distraction, and shipping it teaches your team to stop trusting the queue.
Would a reviewer push back?
Then the diff goes back to the model as a critic, with the project's own conventions in front of it. Findings come back graded. Blocking ones are fed in as fixes and the diff is verified again; anything merely worth mentioning is collected.
What happens when the critic will not be satisfied is the interesting part. After the fix attempts are used up, the run does not loop and it does not silently drop the objection — the unresolved blockers are written into the pull request body, labelled as unresolved. A verified, working change should not be stranded because two model passes disagreed, but you should be told they did.
Did it commit a secret?
Next, a scan. We do not ship our own scanner; we run the ones your repository already has. If gitleaks is on the machine it runs. So do semgrep, pip-audit where there is a requirements file, and npm audit at high severity where there is a lockfile. Absent tools are skipped rather than faked.
Findings feed back the same way, and the same rule applies at the end: what could not be fixed is stated in the pull request rather than quietly dropped.
Does the documentation still match?
Optional, and off unless you turn it on. When enabled, the docs and changelog update in the same pull request as the change. A follow-up documentation PR is one nobody merges.
The part that matters
None of these gates make the model better. They make its output cheaper to review, which is a different and more useful property. The question worth asking a tool in this category is not whether it can write the change — most can, some of the time — but what it does between writing the change and putting it in front of you.
If the answer is "nothing", you have not automated the work. You have moved it to the reviewer.