From prompts to loops — and the plumbing both forget
The frontier stopped prompting and started building loops. They're right — and what they've described is a control plane. Here's the governance the loop still needs: a verifier that proves its claim, a kill threshold before the bill, and a human who stays in the decision.
The model was never the deliverable.
The frontier crowd has quietly stopped prompting and started building the loops that prompt the agent for them. Boris Cherny, who runs Claude Code at Anthropic, says he writes loops now, not prompts. Addy Osmani named it loop engineering — replacing yourself as the person who prompts the agent. Peter Steinberger says the same thing a different way. Fine. Strip the novelty and look at what they actually found: the model was never the deliverable. The harness is.
That is not a new idea on this site. The model is the easy part; the plumbing is what kills you. Loop engineering is the same sentence in a different accent — and the moment it gets specific, it lands exactly where governance has been standing the whole time. The misread is expensive: loop engineering is not a new way to drive the agent in the repo you already have open. It's a different solution architecture. You stop using the agent to solve the problem and you build the system that solves it.
Intelligence is rented. Piping is owned.
A loop is a control plane, not a trick.
Watch where they land when they get concrete. A loop is five capabilities — scheduling, isolated git worktrees, durable skills files, tools that actually act through MCP, and a separate verifier sub-agent — plus a sixth piece that holds it all together: state. That is not a prompting trick. That is a control plane. You don't start from the open editor; you start from scratch, the way you'd design any system: what recurring problem does this loop own, what unit of work can it find by itself, what does "done" look like as a gate something other than you can check, what budget and what state does it carry between runs.
Their own conclusion is the thesis of this entire site, almost word for word: reliability lives in the infrastructure, not the model, and production agents converge on the same control plane regardless of which model sits inside. Engrave it. That's the whole business — and it's the reason we build pipes instead of prompts.
The verifier is the part everyone gets wrong.
A loop does not satisfy your goal. It satisfies the gate you wrote. "Done" is a claim, not a proof — and a well-built loop will cheerfully ship work that passes your gate and misses your intent, then do it again on the next run, and the next, unattended. They call it Goodhart's law wearing an agent costume. We call it the exact failure AUD-1 — Attributable Actions — exists to stop.
A verifier that's easier to satisfy than the goal it stands in for is attribution without the attribution: a checker that can't tell you why it passed something it shouldn't have. So design the verifier first, not last. Split the maker from the checker — and make the checker prove its verdict on a record something other than the maker can read. If you can't trace why "done" fired, you don't have a verifier. You have a second maker nodding along.
The maker–checker split isn't a safety feature you get for free. It's the hardest design problem in the loop — and most failures trace back to a verifier that was easier to satisfy than the goal it replaced.
A schedule is a budget you forgot to set.
A loop on a five-minute cadence that spawns an implementer and a verifier every run can burn a month's token budget before breakfast. That isn't a cautionary anecdote — it's LMT-1, Kill Threshold Monitoring, with the receipt already written. A runaway loop becomes a runaway bill, and it does it at 3 AM with nobody watching.
We put a kill threshold on a US multi-agent system for exactly this: continuous telemetry on speed, spend and error volume, with automatic suspension the moment a threshold is breached. Hard iteration caps and budget ceilings are not optional hygiene — they are the pipe. Make the harness tight before you make the loop long.
Make the harness tight before you make the loop long.
You are the variable, not the loop.
The uncomfortable finding: two engineers build the identical loop and get opposite outcomes. One uses it to move faster on work they already understand deeply; the other uses it to avoid understanding the work at all. The loop cannot tell the difference — which is exactly why loop engineering is harder than prompt engineering, not easier. Osmani calls the second posture cognitive surrender: the same act, designing a loop, is the cure when you do it with judgment and the accelerant when you do it to stop thinking.
This is why a human gate was never just a stop button. HITL-3 keeps a human in the decision, not adjacent to it. Gate by consequence, not by confidence — the model's certainty is not a measure of the action's reversibility, and a green check from your verifier is not a measure of your understanding.
The comfortable posture — let it run, take whatever it returns — is the dangerous one. Build the loop like someone who intends to stay the engineer, not the person who presses go.
Don't ship a maker you can't check.
Loop engineering is correct, and it's incomplete. Building the thing that builds the thing is the right move. But an unattended loop with a weak verifier and no budget ceiling isn't leverage — it's the same liability you started with, now running on a schedule.
An unattended loop with a weak verifier isn't leverage. It's liability running on a schedule.
So put the loop behind the plumbing. Classified before it runs (PRIOR), monitored while it runs (WIN), stopped with the evidence intact when it breaks (FIRE). The loop is the maker. Governance is the checker. The frontier is right that the loop is the new unit of work — it's just describing the half of the system that builds. The other half is the half that survives a regulator.