Do not start a loop you cannot check

The check is the real prompt

A loop repeats until something says stop. If that something is weak, the loop does not fail loudly. It succeeds at the wrong thing.

Nicholas Carlini put the reason in one line while building a C compiler with parallel Claudes: the verifier must be nearly perfect, because the agent solves whatever it is given. Give it a test suite with holes and it will fill the holes, not the compiler.

So the first question for any loop is not what to ask for. It is how you will know it worked. If you cannot answer, do not start.

What a good check looks like

The research points to a few kinds, from cheapest to strongest.

• Tests or a score. The Lighthouse score at least 90 example from the Claude Code team. Fast, but only as good as what the tests cover.
• A known-good oracle. In the compiler run, GCC was the reference. Agents compared against it, which let them isolate kernel bugs in parallel instead of guessing.
• A real end-to-end run. In Justin Young's long-running harness, browser automation caught bugs that reading the code missed. The Claude Code team's advice is the same in spirit: write SKILL.md files that tell Claude how to verify, such as running the app, clicking the control and reading the console.
• A separate verifier agent with fresh context. Useful when no program can judge the result.

Grade outcomes, not paths. The evals post gives the example: check whether the reservation is in the database, not whether the agent followed the steps you imagined.

Maker and checker

Agents praise their own work. The harness post for long-running application development found that a standalone evaluator is easier to tune to be skeptical than a generator is to make self-critical. So the two jobs go to two agents: one makes, one checks.

Addy Osmani recommends the same split with a separate verifier sub-agent. The Claude Code team adds the detail that matters: the second agent has fresh context, so it has not been talked into the maker's assumptions.

The checker also needs checking

A checker is not free, and it is not correct by default. In the application harness, the evaluator out of the box approved bugs it had itself found. Making it skeptical took several rounds of tuning against human judgment.

Calibrate yours the same way. Take outputs you already know are good and bad, run the checker on them, and compare. If it passes what you would reject, fix the checker before you let it run unattended.

Be careful in the other direction too. The evals post notes that a 0% pass rate over many trials usually means a broken task, not a weak agent, and that Opus 4.5 went from 42% to 95% on CORE-Bench after grader and scaffold bugs were fixed. A broken check can make good work look bad, as easily as it can make bad work look good.

Fix the system, not the result

When a loop disappoints, the Claude Code team says to fix the system, not just the one result. If a loop produced a bad change, patching that change teaches the next run nothing. Ask which check would have caught it, add that check, and let the loop run again.

Keeping the codebase clean helps the same way, since a clean codebase is easier to verify.