Loop Engineering: The Definitive Field Guide

For two years the skill was prompting — you held the agent one turn at a time. That era is closing. The new skill is designing the loop that prompts the agent for you: a system that finds work, decomposes it, hands it out, checks it, records what happened, and decides what to do next.

That ring is the whole discipline in one picture. Five stations, turning without you. The leverage didn't vanish when agents got good — it moved one floor up, from the prompt to the machine that writes the prompts. This is the complete parts list, the assembly order, the maturity ladder, and the failure modes, from running these loops across a live portfolio of products.

In early June 2026 a phrase stabilized across the builder community almost overnight. Peter Steinberger, who built OpenClaw, put it bluntly: stop prompting your coding agents and start designing the loops that prompt them. Boris Cherny, who leads Claude Code at Anthropic, described his own workday the same way — he no longer prompts Claude; he writes loops that prompt Claude and figure out what to do next.

On June 7, 2026, Addy Osmani published the essay that turned those one-liners into a named discipline: loop engineering. He didn't invent the practice — he caught an idea moving fast, gave it a name, and gave it a parts list. O'Reilly Radar republished the essay on June 22, which is how it reached most of the industry.

But the technique predates the name by nearly a year. In July 2025, Geoffrey Huntley published "Ralph Wiggum as a 'software engineer'" — a bash while loop wrapped around a coding agent that he used to build an entire programming language. Ralph is the ancestor of everything here, and still the clearest way to understand what a loop is, because it removes everything inessential.

My stance, stated the way both authors stated theirs: this is early, the failure modes are real, and a loop that runs unattended is also a loop that makes mistakes unattended. But the shape of the work has genuinely changed. If you build software with AI agents, this is the thing worth getting good at now — not despite the difficulty, but because the difficulty is where the professional edge lives.

The reason this went mainstream so fast is that it stopped being a tool thing. A year ago a loop meant a pile of bash you owned and maintained forever. Now the pieces ship inside the products — the same primitives, whether you're in Claude Code or the Codex app. Once you see the shape is identical, you stop arguing about which tool and design a loop that works regardless of which one you're sitting in.

Strip away the tooling and a loop is almost embarrassingly simple:

The entire craft is in making the check real and defining when to stop. Model choice, harness, connectors, sub-agents — all secondary to those two things.

A working loop is built from six primitives. Five do the work; the sixth remembers it.

The distinction that matters most: skills, memory, MCP, and AGENTS.md are the four knowledge surfaces — instructions, state, access, and rules. Worktrees and sub-agents are the two structural primitives. Get the knowledge surfaces right and the agent stops guessing. Get the structural ones right and the loop can run unattended without turning into a mess. If your loop is producing confident nonsense, the problem is almost always a knowledge surface. If it's producing a tangle, the problem is structural.

The two tools have already converged

These primitives ship inside both major products and map almost one-to-one. Design for the shape, not the vendor.

The names differ. The capability is identical. Stop being loyal to a tool and start being fluent in a pattern.

Before the primitives shipped inside the products, there was Ralph — still the purest expression of a loop. Geoffrey Huntley named it in July 2025. The name has two origins, both of which he owns: Ralph Wiggum, the cheerful Simpsons character who rams a doorframe and announces "I'm helping!" — and "ralph" as slang for vomiting, roughly how Huntley felt realizing how cheap autonomous code generation had become. His framing is that the technique is "deterministically bad in an undeterministic world." Once you see why that's a feature, the rest clicks.

Short Ralph — a while loop and a prompt

You feed the same prompt file to a fresh agent instance, over and over, until the work is done. Progress accumulates in files and git history — never in the model's context window. My first reaction was "that can't possibly work." It does. Huntley used exactly this shape to build CURSED, a production-grade programming language the model had no training data for. A contact of his delivered a $50k contract MVP for roughly $297 in tokens.

LLMs degrade as context fills. Huntley pins the practical clip at around 147k–152k tokens against an advertised 170k–200k window; past that, output quality drops and tool calls start failing. A long continuous session inevitably drifts into that zone, loses the plot, and confidently makes things worse. Ralph sidesteps this by killing context after every increment and starting clean.

The cardinal rule: one thing per loop. Ask Ralph to do exactly one thing, and trust it to choose which thing matters most. Relax that as the project stabilizes — but the moment it goes off the rails, narrow back to one. You have roughly 170k of usable context and you re-spend it every iteration, so frugality is survival.

Long Ralph — persistence with structure

The naive loop works for small tasks. To ship something real, it needs structure around it without abandoning the fresh-context principle.

Ralph's honest caveats

Huntley is blunt about the boundaries, and any field guide has to carry them faithfully:

• Ralph is a greenfield technique. In his words, there's no way he'd use it in an existing codebase. It bootstraps new projects, and gets you roughly 90% of the way — not 100%.
• Senior expertise is non-negotiable. Anyone claiming a tool does 100% of the work with no engineer is, in his phrasing, peddling nonsense. Ralph gets tuned by a senior operator — like a guitar — every time it drifts.
• You will wake up to a broken codebase sometimes. The call is whether to reset hard and re-run, or craft new prompts to rescue it. That judgment is the job.

The most valuable structural decision in any loop is separating the agent that writes from the agent that checks. The reason is simple and human: the model that wrote the code is too loyal to its own work to grade it honestly. It chases its reward function — compiling code — and will happily wave through a placeholder it wrote ninety seconds ago. A second agent, with different instructions and sometimes a different model, catches what the first one talked itself into.

This matters specifically inside a loop: the loop runs while you're not watching, so a verifier you actually trust is the only reason you can walk away. It's also, under the hood, what a goal-style stop condition does — a fresh model decides whether the work is done, applying the maker/checker split to the exit condition itself.

One caution: sub-agents burn tokens, since each runs its own model and tool calls. Spend the checker where a second opinion is worth paying for — architecture-bearing changes, security-sensitive diffs — not on trivial edits.

The thing to notice: you designed this once. You didn't prompt any individual step. That's the whole idea made real — and it's the same pipeline in Claude Code or Codex, because the pieces are the same pieces.

Loop engineering isn't all-or-nothing. There's a maturity ladder, and the discipline is not climbing faster than your verification can support.

Most professional work today lives at levels 3 and 4. Level 5 is real, but reserve it for narrow, well-fenced changes where your automated checks genuinely carry the risk. Climbing a rung before your verification is ready is the single most common way loop engineering goes wrong.

This is the section most write-ups skip, and the one that separates a professional from a button-presser.

Get the tasks right

Get the cycle right

Set your loops up. But remember that prompting your agents directly is still effective. This is a balance, not a replacement.

1. Ralph → iterations. The engine: fresh context, one thing per loop, disk as memory.
2. Maker–checker → verification. The trust: the agent that writes never grades its own work.
3. Worktrees → parallelism. The scale: isolated checkouts, so many agents run without collision.
4. AGENTS.md → rules. The knowledge: how this project builds, runs, and must not be broken.
5. Memory → state. The spine: fix_plan.md, git history, and specs holding what's done and what's next.
6. MCP → workflow. The reach: connectors that let the loop act inside your real environment.

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go. The leverage moved. The responsibility didn't.

Sources and further reading

• Geoffrey Huntley — Ralph Wiggum as a "software engineer" (July 14, 2025): the origin of the technique, the fresh-context philosophy, and the canonical prompts. ghuntley.com/ralph
• Addy Osmani — Loop Engineering (June 7, 2026): the essay that named the discipline and gave it a parts list. addyosmani.com/blog/loop-engineering
• Boris Cherny (Head of Claude Code, Anthropic) — public talks and posts on writing loops rather than prompts.
• Peter Steinberger — the sentence that lit the fuse: design the loops that prompt your agents.
• O'Reilly Radar — republished Osmani's essay on June 22, 2026, carrying it to the wider industry.

The framing, the maturity ladder, the risk taxonomy, and the integration checklists are my own synthesis, drawn from running these loops across a live portfolio of products.