This is chapter zero on purpose. Before you learn how to build a loop, learn when not to — because the most expensive loop is the one that should never have existed. A loop has fixed costs (designing it, writing the verifier, maintaining the memory, and paying the orchestration tax forever), and those costs only amortize over recurring, verifiable work. The skill isn't building loops everywhere; it's knowing which work earns one.
The person who named the field agrees that prompting agents directly is still effective — "it's all about finding the right balance." A loop is a power tool, not a default.
Use a loop only when the task has a cheap, repeatable, machine-checkable done-condition, a bounded and reversible blast radius, and enough externalized intent that the agent isn't guessing — and keep a human as the verification gate whenever the output is taste-driven, safety-critical, or regulated.
Everything below is that sentence, unpacked into a checklist you can actually run.
A loop pays off only when both are true:
- There is a clear, machine-checkable success criterion — a test passes, a
build is green, a schema validates, a benchmark improves, a rubric returns
PASS. If you can't say how a machine would know the work is done with no human looking, a loop won't converge; it will thrash and bill you for it. - Reaching it involves tedious trial and error you'd otherwise do by hand, turn after turn. If it's a one-shot, prompt it once and move on.
If you fail #1, you don't have a loop problem — you have a specification problem. Find a checkable proxy first, or keep prompting by hand. Do not build a loop to avoid understanding the work.
Two preconditions the gate quietly assumes — make them explicit before you commit:
- It repeats often enough to amortize. A loop has real fixed costs (the verifier, the memory, the orchestration tax). A rough floor: if the work doesn't recur at least weekly, it's a one-off script, not a loop — write the script. Repetition is what pays the fixed cost back.
- The agent has an engineer's tools. A loop only converges if the agent can do what an engineer does to get unstuck: read logs, reproduce a failure in an environment, and run its own code to see the result. If the task is checkable in principle but the agent can't actually run the check itself, you don't have a loop yet — you have a human relaying outputs back and forth.
Don't run an autonomous loop when any of these hold:
| # | Stop sign | Why a loop is the wrong tool | Source |
|---|---|---|---|
| 1 | No verifiable done-condition | With no ground truth, the maker optimizes for looking done — and reward hacking thrives exactly here. | 05 |
| 2 | Taste- or judgment-driven work | API/interface design, naming, product/UX taste, prioritization — "correct" is contested and human. | 09 |
| 3 | One-off / low-repeat task | Loops amortize over reuse. METR found experienced devs were ~19% slower with AI on exactly this kind of mature-repo work. | METR RCT1 |
| 4 | High-intent-debt legacy code | The agent "starts most sessions cold" and guesses the unwritten why. Those guesses become un-deletable rot. | 09 — Intent debt |
| 5 | Safety-critical or regulated, with no human approver | Medical-device, financial-reporting, credit, critical-infra outputs legally require independent human review (EU AI Act Art. 14, SR 11-7, PCI 6.2.3.1). A self-merging loop violates segregation of duties by construction. | 09 — Regulatory2 |
| 6 | The "lethal trifecta" is present | If the loop has private-data access + exposure to untrusted content + the ability to communicate outward, an attacker can exfiltrate. Break one leg before running unattended. | 123 |
| 7 | Irreversible blast radius, no sandbox | If one bad action can't be cheaply rolled back (the Replit prod-DB deletion), gate it behind a human. | 12 |
| 8 | Review can't keep pace with output | If the loop ships more diff than a human can genuinely review, comprehension debt compounds. "The unit of review is the unit of comprehension." | 09 |
If you trip one of these, you have three honest options: (a) fix the gap (write a checkable proxy, externalize the intent, add a sandbox), (b) keep a human firmly in the inner loop (assisted prompting, not autonomy), or (c) don't automate it. All three are legitimate. Forcing a loop onto work that fails the gate is not.
| Good (verifiable + repetitive) | Poor (no proxy, one-off, or high-stakes) |
|---|---|
| Fixing failing CI | Open-ended design or architecture |
| Triaging an issue inbox | Anything where "good" is a matter of taste |
| Dependency upgrades against a solid test suite | A single, one-time change |
| Performance tuning against a benchmark | Legacy code whose intent is undocumented |
| Flaky-test hunts | Safety-critical changes with no human gate |
| Doc builds that must stay green | Work you're using the loop to avoid understanding |
Before the first unattended run, every box should be checkable. If you can't tick them, you're not ready to walk away — you have a loop on paper, not one you can trust.
- Goal — one sentence; names the verifiable thing "done" means.
- Done-condition — an exact command or check a machine runs, no human.
- Separate verifier — a different call/model/test grades the work; the maker never marks its own homework.
- Budget cap — hard ceilings on iterations, tokens, runtime, and (if a credential can spend) dollars.
- Persistence — "done / next" lives on disk; a fresh process can resume.
- Sandbox + off-limits list — where it acts, and what it may never touch (force-push, deps, secrets, prod).
- Rollback plan — a bad run is cheap to throw away.
- Escalation path — the conditions that hand control back to a human, and where they land.
- Stop conditions — all four wired: goal met · budget spent · stalled · needs a human.
- Trajectory logging — you can reconstruct what it did in the last 24h.
A loop that can tick all ten is one you can trust unattended. One that can't is a background script wearing a loop's clothes.
You're allowed to not build the loop. That's the most underrated move in the whole discipline.
→ Next, the positive case: What Is Loop Engineering — or jump to Stop Conditions & Verification to make the done-condition real.
Footnotes
-
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ and https://arxiv.org/abs/2507.09089 (RCT: experienced devs ~19% slower on their own mature repos). The Feb 2026 follow-up, https://metr.org/blog/2026-02-24-uplift-update/, reaffirms it. ↩
-
EU AI Act (Reg. (EU) 2024/1689) Art. 14 (human oversight of high-risk systems), https://eur-lex.europa.eu/eli/reg/2024/1689/oj; US Fed/OCC SR 11-7 model-risk "effective challenge" by parties independent of the developer, https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm; PCI DSS v4 Req. 6.2.3.1 (code review by someone other than the author). See docs/09 for the fuller treatment. ↩
-
Simon Willison, "The lethal trifecta," https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ (Jun 16 2025). ↩