A Loop Needs a Done-Check

"Loop engineering" went around this month. Peter Steinberger posted that people should stop prompting coding agents and design loops that prompt them instead. Boris Cherny, who leads Claude Code, is quoted in Cole Medin's video saying "I write loops and the loops do the work."

Two videos in my notes take the phrase apart. Nate Herk makes it plain for people who do not write code. Cole Medin says what it costs. Read together they leave a small idea: a loop is a trigger, an action and a stop condition, and two of those are easy.

The trigger is a schedule or an event. The action is whatever the agent already does. The stop condition is where the engineering is.

Three parts, one hard one

Herk describes every loop as the same cycle. The agent reasons about the next step, acts with a tool, observes what happened, and asks whether it is done. If the answer is no, it goes around again. He defines the practice as "replacing yourself as the person who prompts the agent."

His sharpest point is that the observe step is the part doing the work. A loop reads its own output where a single prompt assumes the output was fine. From that he gets two questions to answer before building anything: what does done mean, and how will the agent check it. His examples of a usable answer are passing tests, or a word limit plus a required mention. His example of an unusable one is an instruction to make the output good.

It matches how I think about a state machine on an embedded target. A state with no exit condition is a bug.

Four ways to check

Herk's slide sorts verification into four kinds.

Kind	Who decides	Example
Functional	A machine, yes or no	Tests pass, output parses
Visual	The agent looks at a render	Screenshot of a page it built
Judgment	A rubric, ideally scored by a second agent	Draft scored against a checklist
You decide	A human, loop pauses	Anything irreversible or pure taste

Functional checks are cheap and have no opinion. Each row below adds interpretation, and interpretation is where a loop can fool itself.

Herk's own demos show this, and he says so. One loop was asked to recreate the Abbey Road cover using only HTML, CSS and SVG, stopping when the average rubric score reached 9 or after 8 passes. It stopped at version 7 with a 9.0. By his account the result still looked nothing like the photo. The check passed and the goal was missed. A loop optimizes whatever the check measures.

His thumbnail demo had the opposite flaw. The stop condition was to iterate until the agent was satisfied, and he calls that out himself. His fix is a separate scorer agent. He does not show how that scorer gets calibrated.

My own done-checks

My research pipeline already had done-checks before I had the word for them. It writes a note for each video where every claim carries a timestamp anchor, and it refuses to finish until the anchors verify. The compile step that turns source notes into topic articles has a gate on anchors too.

Both are functional checks: a machine can answer them yes or no. They are also narrow. An anchor check proves a claim points somewhere in the source. Whether the claim is a fair reading of what was said there is a judgment check, and that one is still mine.

When not to build one

Herk says most tasks do not need a loop. His test has two parts: the task repeats or has many unknown steps, and the agent can check done by itself. If either is missing, prompt it once or do it yourself.

Cole Medin is blunter. He says loops are not how you get the best results, that plain /loop in Claude Code stays in one session and bloats the context window, and that cost climbs fast because an orchestrator and its workers keep passing context back and forth. He says one simple app cost him over a million tokens. The dashboard frame in my notes shows about 1.36 million as the total across 15 loops and 100 runs, and about 489 thousand for the single Kanban run. I cannot tell which figure he meant. Either one is a lot for a static page.

His fix is to take decisions away from the agent wherever the answer is already known. The example I keep is tests: let the agent write the code, and run the test command as a plain shell step so the agent never decides what passing means. That is a done-check moved out of the model entirely. His recommended tooling is his own project, Archon. The principle holds without it.

Matt Pocock, in conversation with David Ondrej, adds that a single endless loop is the wrong shape for most development anyway. He describes a queue of scoped tasks that agents pick up. As I read it, that gives every task its own small finish line.

Hard stops

A done-check tells the loop that it succeeded. A loop also needs to know when to give up, and that is a separate condition.

IBM's explainer on agent failures lists the infinite loop first: an agent retrying similar actions with no progress, such as searching for a document that does not exist. The causes it names are no termination condition, no tracking of whether each retry differs from the last, and no tracking of whether results improve. The mitigations follow directly: a cap on retries, steps or runtime, and a comparison against previous attempts. IBM's premise, that models are now consistent enough to rule out as the cause, is asserted without evidence. The checklist stands without it.

Herk says a hard stop belongs on every loop. He reports loops of his own that ran more than 12 hours without producing anything useful. The Abbey Road prompt had both halves: a score threshold and a pass limit. In Cole Medin's closing diagram, reaching the round cap hands control to a human who approves before the next expensive round.

Key Takeaways

A loop is a trigger, an action and a stop condition. Only the stop condition is hard.
Write done so a machine can check it. Prefer functional checks, and be suspicious of rubric scores.
A stop condition has two halves: a done-check for success and a hard cap for giving up.
Most tasks do not need a loop. Build one when the task repeats and the agent can verify its own result.

Sources

Next for me: before I leave any loop running on its own, it gets an explicit iteration cap and a budget, written next to its done-check.