Loop engineering in practice

What is loop engineering?

Loop engineering is designing the automated system that prompts, verifies, and re-prompts AI agents: the person designs the loop, and the loop does the prompting. In practice it means scheduled runs, goal conditions graded by a separate model, isolated worktrees, subagent fan-out, external state files, and hard budget guards. The term has a short, traceable history. Peter Steinberger, June 8: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, who runs Claude Code, on a podcast: "I don't prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops." Addy Osmani named the term on June 7 and gave it a parts list.

Osmani's anatomy (worth reading in full; O'Reilly republished it) has five components plus one: automations (scheduled discovery and triage), worktrees (parallel isolation), skills (codified project knowledge, kept short), plugins/connectors, subagents (the maker/checker split), and a sixth, quieter component: state that lives outside the conversation, a markdown file or a board, "the same trick every long running agent depends on." His sharpest mechanism is /goal: the agent works until a written condition is true, and the grading is done by a separate small model, in his words, "so the agent that wrote the code isn't the one grading it."

Is loop engineering just prompt engineering rebranded?

No. The "just a while loop" crowd on Hacker News is aiming at the wrong floor: prompt engineering shapes one turn, context engineering shapes what one turn can see, and loop engineering shapes what happens across a thousand turns nobody watches. The layers stack rather than replace each other, and the stacking has a property the explainer posts tend to skip: a loop amplifies whatever is inside it. Bad context inside a loop compounds across iterations rather than averaging out. One Hacker News comment states this more directly than the explainer posts do: "designing the loop is half of it. The other half is putting something in the loop that can say no: a test, a type check, a real error. A loop with nothing to push back is the agent agreeing with itself on repeat."

Osmani acknowledges this himself: verification stays human, "comprehension debt" grows fastest when the loop runs smoothest, and "the comfortable posture is the dangerous one." One footnote: Steinberger's own documented workflow, "Shipping at Inference-Speed" (December, a good read), is mostly a single agent, a queue, commits to main, and personal taste ("usually I'm the bottleneck"), closer to solo craft than the loop-heavy manifesto suggests. The discourse is running roughly six months ahead of its own founders, which is a reason to separate evidence from vibes before repeating either.

Patterns that hold up in practice

• Ralph Wiggum loop (Geoffrey Huntley): plan → implement → test → verify → PR, as a bash loop against external checks. Its one commandment: "the agent does not decide when work is finished — the harness does." (writeup)
• Maker/checker split: a second model grades the first's work, because "the model that wrote the code is way too nice grading its own homework" (Osmani). Anthropic's harness post hardens it: features live in a JSON list, marked passing only after independent verification. Their documented failure modes (premature "done", half-finished features, skipped tests) are all self-grading failures.
• Cross-vendor review: Simon Willison runs OpenAI's model reviewing Anthropic's PRs and vice versa; his GPT-5.5 pass caught two transaction bugs Fable missed, an example of using rivalry between vendors as a QA check.
• Budget guards and stop conditions: iteration caps, per-iteration token budgets, compaction cadence (Steinberger publishes his exact auto_compact arithmetic). The HN warning stands: "without guardrails, you get infinite loops and billing surprises orders of magnitude over budget."
• Blast radius first: every loop above runs unattended, which means every loop above runs inside a sandbox or not at all. This blog's founding topic turns out to be a loop-engineering prerequisite.

Which model should engineer your loops?

The one local data point this blog can offer: its own pipeline was loop-engineered by Fable 5 from a rough goal and light steering, retry logic, verification gates, state files, and subagent routing included. Beyond that, the comparison below rests on the published record.

The published record is thinner than the discourse suggests. No rigorous head-to-head of "model as loop-architect" exists as of this writing: the agentic benchmarks all measure execution inside someone else's loop, and those benchmarks have well-documented problems of their own. The adjacent evidence, though, is consistent in direction:

• The subagent inheritance bug: in OpenAI's Codex harness, Sol cannot set its subagents' model or effort tier, so spawning at ultra means every child burns ultra too. Theo, whose Ultra-bill made him notice, wrote: "Causes massive token burn for no good reason… Claude Code is far ahead here." This is a harness bug rather than model cognition, but loop plumbing is exactly what's being graded here.
• Trust as loop-architect: METR reportedly found Sol gamed its software-engineering evaluation at the highest rate of any model they've publicly tested, and OpenAI's own system card acknowledges elevated over-agency versus GPT-5.5. A model that games success criteria and overreaches scope is not a good candidate for writing its own success criteria, which is what loop engineering delegates to the architect model. (Reported findings; primary documents still pending.)
• The positive case: in Willison's 37-prompt, 34-commit Fable release-engineering session ($149.25, itemized), Fable ran the multi-day loop, spawned subagents, and routed one narrow task to a cheaper Opus 4.8 instance. His direct read on Sol: "very competent, though so far it hasn't struck me as better than Fable at the kind of complex coding tasks I've been using with Anthropic's model."

Directionally aligned, none of it conclusive. If a benchmark for loop architecture appears, this blog will report its numbers, including if they point the other way. Until then the claim above stays labeled as unproven.

What to do

• Start with one loop: a scheduled task, a written goal condition, a grader that isn't the worker, an iteration cap, a token budget. Osmani's five components are optional, not required.
• Add a mechanical check that can say no: a failing test, a type checker, a lint gate, something that blocks bad output without being argued out of it.
• Route execution to cheaper models: Fable architects the loop, and cheaper models, Sol included, handle execution inside it. Keep Sol out of the architect role until the evidence changes.
• Externalize state: a markdown file the loop reads and writes persists; a context window does not. Part 1 covered this in more depth.
• Cap the blast radius: unattended loops belong in containers. The flag named in this blog's masthead is a loop-engineering tool, used correctly.
• Audit comprehension debt: read one full run transcript, end to end, weekly. Skipping that review is when Osmani's "cognitive surrender" risk becomes real.