Loop Engineering: The Roadmap From Prompter to Loop Designer

*Based on a roadmap shared by @0xCodez on X, content credited to Lev Deviatkin.*

Prompting is a conversation. Loop engineering is a system: you design the thing that prompts the agent over and over — the trigger, the memory, the verifier, the stop — and then you leave. Deviatkin's roadmap lays out the full path from "person who types prompts" to "person who designs loops," and it's the clearest version of that ladder we've seen. Here's the roadmap, mapped onto loops you can actually copy from [the directory](/loops).

First, the 4-condition test

Most loop failures happen before the loop runs — someone automated a task that should never have been a loop. Run this test before building anything:

1. The task repeats at least weekly. A loop you run once is a prompt with extra ceremony. 2. Verification is automated. Tests, type checks, lint, build — an exit code, not a vibe. 3. Your token budget can absorb the waste. Loops burn tokens on dead ends. That's the deal. 4. The agent has senior-engineer tooling. Logs, a repro environment, the ability to run its own code. An agent that can't check its work will claim its work is fine.

Fail any one of the four and you don't have a loop candidate — you have a chore that still needs a human.

The 5 building blocks

Every loop worth running is assembled from the same five parts:

Automations — the schedule or trigger. When does this thing wake up?
Worktrees — parallel isolation. The blast radius of a bad iteration should be git worktree remove, not a force-push.
Skills — persistent project knowledge the agent loads instead of rediscovering.
Connectors / MCP — real tool access: GitHub, CI, your issue tracker.
Sub-agents — the maker/checker split, which gets its own section below because it's the one people skip.

You don't need all five on day one. Which brings us to:

The minimum viable loop

One automation + one skill + one state file + one gate. That's it. And the order matters: validate a manual run first, then wrap it in a loop, then schedule it. If the task doesn't work when you drive it by hand, a loop just automates the failure.

The smallest real example in the directory is [watch-pr-checks-pass](/loops/watch-pr-checks-pass) — poll a PR's checks every five minutes until they pass. One trigger, one hard signal, one exit. It's barely a loop, which is exactly why it's the right first one.

The state file: the agent forgets, the file does not

Context windows end. Sessions crash. The loop that runs tomorrow has no memory of today unless you give it one — a STATE.md (or PROGRESS.md, or an external tracker) that records what's done, what's in progress, and what got escalated. Tomorrow's run *resumes* instead of restarting.

The directory's best expression of this is [ralph-guardrails-learning](/loops/ralph-guardrails-learning): when a check fails the same way twice, the loop appends the failure pattern to a guardrails file that every later iteration reads first. The loop literally writes its own playbook. State files aren't bookkeeping — they're how a loop gets smarter than any single run of it.

Maker/checker: don't let the author grade the homework

The agent that wrote the code should not be the one deciding the code is good. Self-review by the same model carries self-preferential bias — it made those choices for reasons it still finds convincing. Use a separate verifier, ideally a *different model*. This is the evaluator-optimizer pattern Anthropic described in its Building Effective Agents engineering post (December 2024): one loop generates, an independent loop evaluates, and work only passes when the evaluator says so.

In practice: [clodex-adversarial-review-loop](/loops/clodex-adversarial-review-loop) — Claude plans and implements, opens a PR, then Codex runs an adversarial review and Claude fixes every blocking finding, repeating until the review is clean. Cross-vendor checking is the cheapest bias insurance available.

The Ralph Wiggum failure mode

The Ralph loop — the name comes from Geoffrey Huntley — is the brute-force pattern: same prompt, while true, fresh context each pass. It works surprisingly well. It also has a signature failure mode:

> No real verifier + soft completion conditions + no hard stop = a loop that fails quietly and keeps spending.

The agent decides it's "basically done," the loop agrees because nothing objective says otherwise, and the meter keeps running. The fix is not a better prompt. It's an objective, non-negotiable gate: an exit condition the agent cannot talk its way past. npm test exits 0 or it doesn't. There is no "mostly passing."

Pair every gate with a hard stop. [loop-cost-guardrails-pattern](/loops/loop-cost-guardrails-pattern) is the four-part checklist: a hard iteration cap, a stop-after-N-turns clause in the goal text, a budget limit on SDK loops, and a cost check inside the loop body. Applied together, not as alternatives.

Good first loops, bad first loops

Good: CI failure triage, dependency bump PRs, lint-and-fix passes, flaky test reproduction, issue-to-PR drafts on well-tested code. The common thread: "done" is machine-checkable and the blast radius is a branch.

Bad: architecture rewrites, auth, payments, production deploys — anything where "done" is a judgment call. Judgment-call tasks fail the 4-condition test at condition two, every time.

A model first loop: [dependency-upgrade-one-at-a-time](/loops/dependency-upgrade-one-at-a-time). One package per turn, full test/lint/build after each, pin and log anything that breaks, hard stop at 20 turns. Every breakage is attributable to a single change. That's loop design.

The security tax

Unattended loops pay a tax that supervised sessions don't, and you pay it up front:

The gate must include security checks, not just tests.
Audit skill sources before auto-install. A loop that pulls in unvetted skills is executing strangers' instructions overnight.
Sanitize or disable verbose logging in production — logs are where credentials go to leak.
Re-audit write-permission scope every 30 days. Scope creeps; nobody notices until it matters.

This is also the argument for a harness over a bare while true: budgets and gates enforced by machinery, not by asking the model nicely. (There's a real cost to skipping this — Addy Osmani calls the human side of it comprehension debt: code nobody understands accumulating faster than anyone can review it. A loop with no gate manufactures comprehension debt at machine speed.)

The metric that matters

Not tokens spent. Not loops scheduled. Cost per accepted change. If fewer than half of a loop's changes get accepted, the loop is net-*losing* your review time, not saving it — you've built a machine that generates rejection work. Measure acceptance rate, kill the loops that lose, and reinvest the budget in the ones that win.

Where to go from here

The ladder: pass the 4-condition test, ship a minimum viable loop, add a state file, split maker from checker, gate everything objectively, pay the security tax, and measure cost per accepted change. Each rung is one loop away.

The [loop builder](/builder) walks you through it — goal, exit condition, budget, guardrails — and hands back a harness you can run tonight. And when your loop needs to tell you it finished (or got stuck), ConnectMyEmail gives it email so it can report in and get back to work.

Loop Engineering: The Roadmap From Prompter to Loop Designer