AI Slop Prevention Is Loop Design, Not Luck

TL;DR

  • Two engineers build the same loop and get opposite results: one moves faster on work they understand, the other stops understanding the work. The loop doesn’t know the difference, you do.
  • The three failure modes a loop amplifies: unattended fake-done (“done” is a claim, not a proof), comprehension debt (your model of the system rots as the loop ships code you didn’t write), and token burn (subagents, empty runs, unbounded iteration).
  • AI slop prevention is loop design, not luck. The remedy is a pre-flight review ritual you run after every loop run, plus three caps every loop needs: iteration, cost, time.

Two engineers clone the same repo. Same loop config, same model, same stop condition. Six weeks later the first one ships faster on a system she understands better than when she started. The second ships faster on a system he no longer understands at all. The loop did exactly what it was told in both cases. That is the unsettling part.

AI slop prevention gets framed as a model problem, or a prompt problem. It is neither. The difference between those two engineers was not the loop. It was who stayed the engineer.

A loop is a recursive goal: you define a purpose and a verifiable stop condition, and the system iterates agents against it until the condition holds — without you prompting each turn.

This is the finale of a series that opened, nine parts ago, with one promise: the same loop that compounds a careful engineer’s leverage compounds a careless engineer’s slop, and the loop cannot tell the difference. Where this series started made that claim in a single sentence and deferred the proof. This part is the proof. The thesis, unhedged: loop design is harder than prompt engineering, not easier. A bad prompt fails in front of you. A bad loop fails while you sleep.

A Loop Running Alone Is Also Failing Alone

Unattended operation is the whole point of a loop, and also its sharpest risk. When no one watches the run, “done” is whatever the worker claims, and the worker is the most generous grader in the building. Anthropic documents “premature victory” and fake-done features in its guidance on effective harnesses for long-running agents. Those are the vendor’s own failure modes, not a critic’s complaint.

Then there is the receipt from a real run. In one of our own fix loops, a bug (BUG-003) closed at its highest tier, FULL. Read the run summary and the picture complicates honestly: the run flagged its own deviations. The browser console was not clean (three unrelated HTTP 404s). The prod-faithful build fallback was blocked by an unrelated image bug. So the loop closed on a layer-appropriate computed-style check and logged the gaps (GAP-A, GAP-B, GAP-C) instead of papering over them.

The lesson is not “the loop lied.” The loop reported. A human still had to read that report to learn what FULL actually meant in that run. A stop condition is a claim until a human or a different model checks it. The canonical definition above rests on one load-bearing word: verifiable. Strip the verification and a loop is just build faster, fail faster with the last reviewer removed from the room.

Key insight: “Done” is a claim a loop makes and a human still has to read. Anthropic lists premature victory and fake-done features as documented failure modes precisely because an unverifiable stop condition fails silently.

Comprehension Debt: The Code Ships, Your Mental Model Doesn’t

Every loop-written change you merge without understanding is a loan against your model of the system. The interest comes due the day you have to debug it. Comprehension debt is the growing gap between what your system does and what you understand it to do, and a loop widens that gap faster than manual work because it ships more, faster, with less of you in each line.

Contrast it with technical debt. You usually know where technical debt lives; you filed the ticket, you left the comment. Comprehension debt is invisible until you go looking, and you only go looking when something breaks. By then the loop has shipped a hundred changes you skimmed and approved.

The structural antidote is not “review harder.” It is keeping a human in the merge seat by design. Our most mature manual loop, the design component loop, has 10 verified runs behind real green gates (vitest at 650/650, the toolkit spec validator at 65/65, independently re-run), and it still ends every single spine row with “Nothing merged, Ethan merges.” That gate is not bureaucracy. It is the comprehension checkpoint. The honest tension, and it is the one worth sitting with: the more you trust the loop, the more tempting it is to remove that checkpoint. The moment you do, comprehension debt compounds in the dark.

Key insight: The most mature loop we run keeps a human merging every diff by design (10 verified runs, green gates, “Nothing merged, Ethan merges” on every row). The merge gate is the comprehension checkpoint, not red tape.

Where Loops Burn: Token Economics and the Three Caps

A loop’s cost is not the model’s per-token price, it is the shape of the run. Loops burn in three places, and three caps keep the burn bounded. The first burn source is subagents. The maker-versus-checker discipline that makes a loop trustworthy also multiplies spend, because every turn spins a separate checker subagent with its own context. Trust has a token price. A Tier-2 advisory reviewer compounds it: it is single-sample and non-deterministic, so you pay for a fresh-context opinion that will not come back identical twice.

The second is empty runs. A scheduled loop fires whether or not there is work. One of our heartbeat loops archives empty runs cheaply by design, but cheap is not free, and a loop that wakes on a schedule to find nothing still pays to look. The third is unbounded iteration: the failure mode where a loop retries forever against a goal it cannot reach. The fix is the one every serious system already uses, a cap. The content review loop in this very toolkit caps at three iterations; /goal runs are capped by construction. Every loop gets a cap.

Burn sourceWhat it costsThe cap that bounds it
Subagents (maker plus separate checker each turn)Multiplied context per turn; non-deterministic reviewer spendCost: a token or budget ceiling per run
Empty runs (scheduled wake with no work)Small per-wake cost that accrues over timeTime: a wall-clock ceiling and a sensible schedule
Unbounded iteration (retry against an unreachable goal)Open-ended spend until you noticeIteration: a max-turns counter

One honest boundary, stated plainly: there are no per-run dollar figures here, because the audited artifacts do not contain hard ones (the fix-pack cost is approximate at best). The point is the shape of the burn and the caps that bound it, not a number I would have to invent. For the mechanics of actually controlling spend, the cost optimization playbook owns that ground; this essay only names where loops burn so you know what to cap.

Key insight: Three caps bound a loop’s burn: iteration (a max-turns counter), cost (a budget ceiling per run), and time (a wall-clock limit). The content review loop here caps at three iterations as a working precedent.

Same Loop, Opposite Results: Surrender vs. Designed Leverage

Designed leverage is real, and it genuinely wins. The same loop becomes cognitive surrender or designed leverage depending entirely on whether the engineer stayed in the loop’s decisions. Take the upside at full strength, because it is not a strawman. Boris Cherny reported a recent 30-day window in which 259 PRs landed with 100% of his Claude Code contributions written by Claude Code. Our own design loop has 10 verified runs behind real green gates. Addy Osmani’s loop-engineering synthesis frames this as the new shape of the work, and on the evidence he is right. This is leverage a careful engineer earns by designing the loop well. Concede it fully.

Now the other engineer, same loop. They stopped reading diffs. They stopped writing stop conditions they could defend in a review. They started merging green. Same tool, opposite trajectory.

The variable is not the loop’s quality. It is whether the engineer kept making the loop’s decisions (what it is for, what “done” means, what it may touch) or quietly handed those decisions to the loop too. Designed leverage keeps the human as the loop’s architect. Surrender demotes the human to the loop’s rubber stamp.

This is the constraint paradox at loop scale: the constraints you impose are what create the leverage, and removing them feels like speed right up until it isn’t. The devkit blueprint in Part 8 shows how to build the leverage side well; this essay is the part that tempers it.

Key insight: The designed-leverage case is genuine, not hype: 259 PRs in 30 days, 100% Claude Code-written, is a real receipt. The loop is not the variable. The engineer who either keeps or surrenders the loop’s decisions is.

When Not to Loop, and When It Just Makes AI Slop

A loop is the wrong tool for one-off work, unverifiable goals, and any domain you cannot yet review. Reaching for a loop there does not save time, it manufactures slop you are not equipped to catch. Three cases, in order of how often they bite.

One-off work: a loop is infrastructure, and infrastructure only pays back if the task repeats. For something you do once, writing the prompt is faster than building the harness around it. Unverifiable goals: if “done” cannot be checked by a machine or a different model, the loop cannot know when to stop, and you have automated the fake-done failure mode from the first beat. Domains you cannot yet review: the uncomfortable one. If you cannot review the output, because it is a language you do not know or a system you have not learned, the loop does not extend your reach. It removes the last reviewer you had.

The skeptics have a fair point worth stating in full. The honest “not yet” case holds that loops pay only when the task repeats, when verification is automated, and when the budget absorbs the waste. That is correct as far as it goes. The difference is where it ends: the skeptic stops at “don’t,” and this essay stops at “here is when it flips to yes, and here is how to stay the engineer once it does.”

Key insight: Loops pay off only when three conditions hold at once: the task repeats, verification is automated, and the budget absorbs the waste. Miss any one and a loop manufactures slop faster than you can catch it.

Build the Loop, Stay the Engineer

The remedy to all three failure modes is one habit, not three: stay the engineer the loop reports to. That is a ritual, not a feeling. After every loop run, regardless of a green gate, you personally read four things. The stop-condition output: did it actually verify, or did it only claim? The diff: do you understand every change, or are you merging on trust? The trace or state file: what did the loop try, and does its reasoning hold up? The caps: did it hit one, and if so, why?

Then the three caps, set before the run, not after: iteration, cost, time. Four read-items, three caps. It fits on an index card, and it is the entire difference between the two engineers we started with.

Key insight: AI slop prevention is a ritual, not a feeling. After every loop run, read four things: the stop-condition output (did it verify, or just claim?), the diff (do you understand every change?), the trace or state file (does the loop’s reasoning hold?), and the caps (did it hit one, and why?). Set three caps before the run: iteration, cost, time.

Nine parts ago this series argued that the leverage point moved from writing prompts to designing loops. The last word is that designing the loop is the easy half. Staying the engineer the loop answers to is the hard half, and the only half that decides whether you got faster or just got slop faster. The loop will run with or without you in the merge seat. Whether it produces leverage or slop is the one thing it cannot decide. You can. Build the loop, stay the engineer.

FAQ

What is AI slop and how do loops cause it?

AI slop is plausible-looking output that no one has actually verified or understood. Loops cause it when they run unattended against a stop condition that only claims “done” rather than proving it, so unchecked output accumulates faster than a human reviews it. The prevention is a verifiable stop condition plus a human who reads the result.

What is comprehension debt?

Comprehension debt is the growing gap between what your system does and what you understand it to do. A loop widens it faster than manual work because it ships more code with less of you in each line. The remedy is keeping a human in the merge seat, so every change is understood before it lands rather than after it breaks.

When should you not build an agent loop?

When the work is one-off (a loop is infrastructure that only pays back if the task repeats), when “done” cannot be verified by a machine or a different model, or when you cannot yet review the output yourself. In those three cases a loop manufactures slop you are not equipped to catch, and a plain prompt is the better tool.

This is the final part of the Loop Engineering series. No next part follows; these point back through the arc.