Loop Engineering Doesn't Remove the Human. It Promotes One.

There's a sentence that broke AI-coding Twitter in June 2026. Peter Steinberger — the creator of OpenClaw — posted that you shouldn't be prompting coding agents anymore; you should be designing loops that prompt your agents. A few days earlier Boris Cherny, who runs Claude Code at Anthropic, had said almost the same thing from the inside: he doesn't prompt Claude anymore, he writes loops, and the loops do the prompting.

Two sentences, millions of views, and a week of people arguing about what a "loop" actually was. Here's the version that actually holds up — and the part almost everyone gets wrong.

What loop engineering actually is

For about two years, getting work out of a coding agent meant holding it the whole time. You write a prompt, read what comes back, write the next one. You are the loop. You are the thing deciding what happens on every turn.

Loop engineering is the move from being the loop to building it. You design a small system that finds the work, hands it to an agent, checks the result, writes down what's done, and decides the next action — on a schedule, or until a goal is actually met. Then you let that system poke the agents instead of doing it yourself.

Addy Osmani, who wrote the reference piece on this, breaks a working loop into five pieces plus one:

1. Automations — something fires on a schedule and does discovery and triage on its own.
2. Worktrees — isolated checkouts so two agents working in parallel don't overwrite each other.
3. Skills — your project knowledge written down once, so the agent stops re-guessing it every session.
4. Connectors — the agent reaches your real tools: the issue tracker, the database, Slack, the staging API.
5. Sub-agents — one agent has the idea, a different one checks it.

And the sixth, the one that quietly makes or breaks everything: persistent state. A markdown file, a Linear board, anything that lives outside the single conversation. The model forgets everything between runs. The repo doesn't. The state file is the spine — tomorrow's run picks up exactly where today's stopped.

That's loop engineering. Not a bigger prompt. A system that discovers, assigns, verifies, remembers, and knows when to stop.

The part everyone gets wrong

The popular summary is "loop engineering means no humans — agents running 24/7, fully autonomous." That's the misconception, and it's worth killing carefully, because the truth is more useful.

Loop engineering removes the human from one specific position: the per-prompt driver's seat. You stop being the one poking the agent turn by turn. It does not remove human oversight. Osmani is blunt about this — a loop running unattended is also a loop making mistakes unattended. Verification doesn't disappear. It moves up a level.

The cleanest way to say it borrows language the AI-governance world has been using all year:

• Human-in-the-loop (HITL): a human approves before anything happens. Slow, safe, doesn't scale.
• Human-on-the-loop (HOTL): agents run autonomously through their own decide-act cycle; the human monitors via dashboards and alerts and steps in only on exceptions — one person overseeing many agents in parallel instead of micromanaging each step.
• Human-out-of-the-loop: fully autonomous, fine for low-risk reversible actions.

So loop engineering isn't "remove the human." It's relocation, not elimination. You move from in-the-loop to on-the-loop. You stop approving every step and start designing the system and owning the exceptions. That distinction is also the honest answer to the "isn't this dangerous / isn't this hype" objection: the human never leaves. They get promoted from operator to architect.

The design that actually works

If the human is on the loop, two things have to be true: agents have to check each other, and the human needs a single place to handle what the agents can't.

Agents reviewing agents is the most-endorsed structural pattern in the whole conversation, and the logic is simple: the model that wrote the code is far too generous grading its own homework. A second agent — different instructions, ideally a different model — catches what the first one talked itself into. The reason this matters specifically inside a loop is that the loop runs while you're not watching. A verifier you actually trust is the only reason you can walk away.

There's a great line from the original thread: a loop with nothing in it that can say no is just the agent agreeing with itself on repeat.

The human dashboard is the other half. Anything the loop can't resolve lands in a triage inbox — an approval queue the human works through when they have time, instead of being interrupted on every action. That's your HOTL realization: the agents handle the routine, the dashboard surfaces the exceptions, the human spends their attention only where judgment is actually required.

Picture an airline rebooking agent. Most passengers get rebooked automatically — out of the loop. A first-class international itinerary with a loyalty override hits a policy boundary, so the agent pauses, packages the context, and routes an approval request to a senior human — in the loop. Meanwhile a supervisor agent watches the whole flow for anomalies like unusual cost spikes. All three oversight levels, one system.

The catch nobody mentions (and the fix)

Here's where most takes stop, and where the credibility actually lives: agents checking agents is not a free lunch.

The core failure is correlated error. If your worker and your reviewer are the same model, they share the same blind spots — models even score their own output higher when they recognize it. Stack several agents voting and it gets worse: they can converge on the same wrong answer with total confidence, and a judge model facing a 3-against-1 split will often side with the majority even when the lone dissenter is right. The raw numbers are sobering — LLM-as-judge error rates climb past 50% on genuinely complex tasks, and most teams still keep humans involved in evaluation for exactly this reason.

So the verifier can't just be "another opinion." Two fixes make it real:

1. Anchor verification in something objective. A test that passes, a type checker, a real API response, a build that actually compiles — something external that can say no regardless of what any model believes. Agent-as-reviewer plus a hard external check beats agent-reviewing-agent alone every time.
2. Use a different, stronger model as the reviewer. Different family, different blind spots. This single change kills most of the correlated-error problem.

And watch for the dashboard's own failure mode: governance theater — a human nominally approving actions they don't have the context to actually evaluate, rubber-stamping a queue and calling it oversight. A dashboard that floods you with approvals you can't meaningfully judge is worse than no dashboard, because it manufactures false confidence. Real HOTL means the human sees enough — the trace, the reasoning, the cost — to make the call count.

Where this is heading

This isn't just an architecture preference anymore. The EU AI Act (Article 14) and NIST's risk framework now write human oversight into law. "Audit, HITL, RBAC" has gone from nice-to-have to a buying gate. The teams that designed oversight in from the start are about to have a real advantage over the ones bolting it on.

This is the bet I'm making with what I'm building — a control plane where agents are organized like a company, every cross-agent call lands in one observable timeline, and the HITL ladder (no-approval, single-reviewer, dual-reviewer) is configured per role and graded by risk. Because the platform is model-agnostic per role, you can wire a stronger model as the reviewer for exactly the correlated-error reason above. The loop runs; you stay on it.

The one line to remember

Osmani put it best: two people can build the identical loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop can't tell the difference. You can.

So build the loop. Just build it like someone who plans to stay the engineer — not the person who presses go. The work didn't get easier. The leverage point moved.