The Loop Engineer

# The Loop Engineer

Your loop ran all night. Every pass reported done. By morning the output folder was empty.

Nothing crashed. That's the part worth sitting with — the reporting worked perfectly and the work
did not, and the only thing standing between those two facts was a verifier that was really just an
opinion.

The LOOP kit is the decision procedure that runs *before* any of that: a four-condition test that
decides whether the loop should exist, plus the five named ways a loop lies to you once it does.

## Five ways a loop lies

1. It says done early. The classic quiet failure: the agent emits "done" before the job is
finished and the loop exits on half a result. This happens whenever the "verifier" is a judgment
rather than a measurement. *Fix:* an objective gate — tests pass, build compiles, linter returns 0.
Not an opinion about whether it looks finished.

2. Goal drift. Summarization is lossy. The instruction you wrote at turn 1 — *never touch the
prod config* — survives being restated at turn 12, gets truncated at turn 29, is folded into a
summary at turn 41, and is simply gone at turn 47. *Fix:* a standing spec file, re-read every
iteration, not carried in the conversation.

3. Self-preferential bias. A maker grading its own homework gives itself an A every time. It is
not being dishonest; it is scoring against the same reasoning that produced the work. *Fix:* a
fresh-context verifier with no exposure to the maker's chain of thought.

4. Agentic laziness. "Handled" is not the same claim as "handled enough," and the loop will not
tell you which one it meant. Partial completion reported as completion is the most expensive of the
five, because it looks exactly like success. *Fix:* an objective stop condition, checked by a fresh
model rather than by the worker.

5. No hard stop. Without a declared cap, a loop runs until the rate limit or the bill notices.
*Fix:* token, iteration and time caps declared up front, before the first run.

This is the part most automation advice leaves out. Before any of the above matters, the skill asks
four questions, and missing one means keep it manual:

1. Does the task actually repeat? Not "could it" — does it, on a real cadence?
2. Is success machine-checkable? If the only way to know it worked is to read the output
yourself, you have not built a loop, you have built a thing that generates reading.
3. Can a fresh model do the checking? If the only available verifier is the thing that did the
work, see failure mode 3.
4. Is there a cap declared up front? Tokens, iterations, wall time. Declared before the run,
not discovered during it.

Run those four honestly and the most common outcome is *don't build it*. That is the point. The
tests you fail save more time than the ones you pass, because an automation that should not exist
costs a weekend to build and then keeps costing attention forever.

- SKILL.md — the four-condition test, the five building blocks, and the failure-mode catalogue
- LEARNINGS.md — what actually went wrong in practice, with the incidents attached
- DECISION-CARD.md — the whole thing on one printable page: four conditions, five lies, one
verdict rule

Install in about two minutes: unzip it into ~/.claude/skills/loop-engineering/, and the next time
you're about to automate something, run the card against it first.

Comment LOOP on the video and I'll send it over — though nothing is gated on that. The kit is at
sharpendaily.co/kit/loop either way, no email and no DM required.