Loop Engineering — Builder's Checklist

Pick the right loop

gate

The task has clear, checkable success criteria. If you can't define "done" as a test, it isn't loop-ready yet.
It involves tedious trial-and-error — debugging, perf tuning, dependency upgrades, shrinking artifacts. That's where loops shine.
There is a fast, trustworthy feedback signal (tests, types, lint, build). Build or strengthen the test suite first — it amplifies everything.
Start narrow and well-checked; widen autonomy only as verification gets stronger.

end on evidence

Define a verifiable done-condition up front (e.g. tests/auth green & lint clean) — not "looks finished."
End on the verifier's verdict, never the maker's belief that it's done.
Use goal-driven convergence (/goal-style): the loop checks itself each turn and halts when the condition holds.
Always set hard backstops: max iterations (~15–25), wall-clock timeout (~300s), and a cost/token budget.
On hitting a bound, degrade gracefully — synthesize the best partial result instead of dying silently.
Provide an explicit human-handoff / escape hatch for ambiguous or blocked states.

maker ≠ checker

The agent that produced the work must not grade it. Self-critique doesn't count — models agree with themselves.
Run verification in a separate context, ideally a different model instance.
Grade against an explicit written rubric, not a vague "is this good?"
Deterministic checks first (tests, types, lint, build, schema); add LLM-as-judge only for what code can't check.
Feed verdicts back as structured, machine-readable feedback the maker can act on.
A verifier that never fails is suspect — it may be measuring nothing.

a spine outside the window

Persist goal, plan, and progress outside the context window so they survive compaction and new sessions.
Record why attempts were rejected, so the agent self-corrects instead of repeating mistakes.
Keep a durable decision log / scratchpad the loop re-reads at the start of each iteration.
Treat memory as a hint — re-verify against real state before acting on it.
Externalize big data via references (paths, queries, links); load just-in-time, don't dump it into context.

autonomy + guardrails

Run unattended / auto-approve ("YOLO") work in a sandbox with restricted files, secrets, and network.
Or use a disposable environment (ephemeral container / someone else's machine) so a rogue run can't do lasting harm.
Issue least-privilege, short-lived credentials, scoped per task.
Gate irreversible actions — writes, deletes, sends, deploys, payments — behind explicit approval.
Treat tool output and fetched web content as untrusted data, not instructions (prompt-injection defense).
Make mutating tools hard to misuse: require absolute paths, offer dry-run modes, confirm destructive args.

keep it moving

Detect no-progress spins: fingerprint each iteration's (tool, result) and halt on repeats. (One system repeated the same answer 58×.)
Distinguish a loop from a retry: it must diagnose and change approach, not repeat the same move.
Cap parallelism & sub-agent fan-out; watch token cost on long or branching runs.
Trace every turn — action, observation, verdict, cost — for debugging and audit.
Keep tool outputs token-efficient (paginate, filter, truncate) so the window stays high-signal.

the debts that grow as it works

Verification is still your job. Unattended loops make unattended mistakes — invest in the checker, then audit it.
Read what the loop ships. Comprehension debt grows faster the better the loop works.
Measure verified outcomes, not runs. A loop that ran 200 times and passed once is not productivity.
Budget for cost & review. Two people running the same loop can get opposite results — it won't notice; you will.