Deep Dive · XiaoHu Explains

What is Loop Engineering, the thing everyone's suddenly talking about

A close look at Anthropic engineers' "loop engineering" methodology: instead of manually prompting AI line by line, you design a system that runs itself
Quick Take
  • Loop Engineering was independently discovered and named by Addy Osmani, Boris Cherny, and Peter Steinberger in the same week of June 2026: instead of manually prompting AI, you design a system that automatically prompts AI — you shift from "operating AI" to "designing the system that drives AI"
  • A loop has five steps: discovery, handoff, independent verification, persistence, and scheduling. Skip any one of the five and you get a corresponding named failure mode (the nodding loop, the amnesiac loop, the manual loop, the blind loop, the tangled loop)
  • The hardest step, and the one most often skipped, is verification: letting AI grade its own output makes it praise itself, so you need a separate agent playing the skeptic, defaulting to "assume the code is broken," and actually clicking through the page and taking screenshots — not just reading code
  • Stripe's Minions pipeline merges over 1,300 machine-written PRs every week; the reliability comes from deterministic constraints (linters run and forced, agents can't route around them), not a bigger model
  • A loop quietly racks up four kinds of debt: verification debt, understanding rot, cognitive surrender, and token-bill blowups. The four reinforce each other and eventually erupt together — the gatekeeper is always human judgment
1Origin · Naming

Three people stumbled onto the same thing in one week

In the same week of June 2026, Google Chrome engineer Addy Osmani, Anthropic's Claude Code lead Boris Cherny, and OpenClaw author Peter Steinberger — none of them coordinating — landed on the same realization: they'd all stopped manually prompting AI and started designing "systems that automatically prompt AI."

Loop Engineering names an identity shift: you go from "the person sitting at the keyboard directing AI one line at a time" to "the person designing a system that gives AI its own assignments." The whole weight of that sentence sits on "replacing yourself."
⚡
Why it's worth your attention: Steinberger's post — "you should be designing loops, not prompting agents" — hit 8 million+ views; Cherny put it as "I write loops now, my job is writing loops"; on June 7, Osmani named it Loop Engineering and wrote it up as an article. All three point at the same shift: what you design has moved from being a single behavior of the agent to being the entire system that drives the agent. And Stripe is already running this pattern at scale, merging over 1,300 machine-written PRs every week.
8,000,000+
Views on Steinberger's "you should be designing loops, not prompting agents" post
6 / 7
The date Osmani named it Loop Engineering and wrote it up, syncing to Substack the next day

Why this exact week

Three people reached for the same word in the same week without comparing notes — that's not coincidence, it's the surrounding tools quietly crossing a threshold. Three conditions matured at once: coding agents became reliable enough to finish a non-trivial task unattended; scheduling primitives just showed up in mainstream tools; and the cost of a single run dropped low enough that running it over and over stopped feeling wasteful. Once every part existed, "combine them" became obvious to everyone at the same time.

The name always lags the practice by months: people were already writing loops long before anyone called it Loop Engineering — the same way teams were already pairing a code-writing agent with a code-reviewing agent long before "generator/evaluator separation" had a name. Worth remembering: the next new term won't come from a model release, it'll come from the moment some capability gets cheap enough that a combination nobody would have dared try before becomes routine.

2Where It Sits

It sits at the top of these four layers

These "X engineering" terms aren't replacing each other — they stack, each layer managing something one size bigger than the one below: from a single sentence, to a context window, to a single run, to a self-sustaining loop. Click into each layer to see what it manages and how big the blast radius is when it fails.

Loop · Loop Engineeringthe top layer
Manages: scheduling on top of the harness, making it run itself over and over. Core question: how do you get it to run unattended, repeatedly. It adds three verbs on top of the layer below: scheduled runs (it wakes itself up on time, no button to press), split sub-agents (one drafts the change, another exists purely to find fault), and feeding its own output back into the next round (yesterday's findings get written to a file, read back in this morning, and built on). Blast radius when it fails: an error gets written into the state file, read back the next day as established fact, and built on — it can propagate for many rounds before anyone catches it.
Harness · single-run kitarm one run
Manages: fully equipping a single agent run — which tools it can use, which operations are allowed, how to recover from errors, what "done" looks like. Core question: what does this one run need to bring with it. It arms a single run, but doesn't make that run repeat on its own. Blast radius when it fails: the agent misreads something and edits a file based on it, but the run ends, the diff is visible, and a human reviews it before it ships.
Context · context engineeringthe window now
Manages: what's in the window right now — what to retrieve, how to summarize, what stale information to clear out. Core question: what do you show the model so it can actually solve this. A window stuffed with noise wastes even the best-written prompt. Blast radius when it fails: a confidently wrong answer — spot it and clear the context, done.
Prompt · prompt engineeringthe words you write
Manages: the sentence you write for the model — wording, examples, persona, tone. Core question: what should you tell the model. Its boundary is a single conversation. Its trouble is that it assumes someone is always sitting there to feed it the next prompt. Blast radius when it fails: caught on the spot within one conversation — just rewrite the prompt.

Take the same bug — an agent misreading some function's return value — and run it through all four layers: the higher up you go, the later it's caught and the more it costs. At the loop layer, that misreading gets written into a state file, read back as fact the next day, and built on layer after layer — by the time anyone looks, that wrong assumption has become a load-bearing wall.

This is the one intuition worth holding onto from loop engineering: the cost of an error equals how many rounds it survives before someone catches it, and a loop, by construction, is a machine for maximizing the number of rounds. Everything that follows — evaluators, human checkpoints, budget caps — exists for exactly one purpose: to shorten the distance between "the mistake happens" and "the mistake is caught."

3Five Steps

One cycle, five steps — skip any one and it breaks in a predictable way

Don't misread "loop" as idling. Every round does something concrete: find work worth doing, hand it off, verify it's correct, save the state, decide what's next. Skip any of the five steps, and the loop either won't turn, or it'll spin in place — and it breaks in a specific, named way.

Discover Handoff Verify can say no Persist Schedule loop a system that runs itself
Five steps arranged clockwise in a circle — scheduling feeds this round's leftover work into tomorrow's round · verification is the only step in the whole circle that can say "no"

Let's use Osmani's own example — the "morning triage loop" he built for himself — to walk through what each step does, and which named failure mode you get if you skip it.