Search "loop engineering" and page one splits into two camps: definition posts that explain the term, and Reddit threads asking whether it’s real or just another AI buzzword. Nobody in either camp seems to actually run a production loop. I do — every day — so here’s the verdict the explainers skip.
IWhat "loop engineering" actually means
Loop engineering is replacing yourself as the person who prompts the agent. Instead of typing every instruction, you design a system that does the prompting for you — on a schedule, against a goal it can verify — and it iterates until the work is done. The term got its name on June 7, 2026, when Peter Steinberger, creator of the OpenClaw agent framework, posted that "you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents." It hit five million views in under a day. Addy Osmani, an engineering lead at Google, wrote the essay that systematized it: "You design the system that does it instead." Anthropic’s Boris Cherny, who leads Claude Code, put it plainly: "My job is to write loops."
IIMy honest verdict, up front
Loop engineering is real. It’s genuine leverage, not hype. But — and this is the part the definition posts won’t tell you — it only earns its keep under four narrow conditions, and most people repeating the phrase this month don’t run a loop that clears the bar.
I run a production agent swarm every day. Loops that start themselves, do the work, check their own output, and stop. That’s the vantage point for everything below: what the pieces actually are, the guardrails that keep a loop from becoming a billing surprise, the four-point test I use to decide whether to build one at all, and where the skeptics are right. Because they are, partly.
IIIWhere it fits: the four layers from prompt to loop
Loop engineering isn’t a replacement for what came before it — it’s the fourth layer wrapping the previous three. First came prompt engineering (roughly 2022 to 2024): optimizing the wording of a single request. Then context engineering, which Shopify’s Tobi Lütke defined on June 18, 2025 as providing all the context needed for a task to be plausibly solvable by the model. Then harness engineering: the environment a single agent runs inside. Loop engineering sits on top — the cycle that drives that harness on a timer.
Here’s the honest concession to the buzzword crowd: the cycle underneath is the ReAct pattern — Reason, then Act — and that’s computer-science-old. The primitive isn’t new. What’s new is wiring it to a schedule, a verifier, and a budget so it can run without you.
IVWhat a real loop is actually made of
Osmani names six primitives, and every production loop I run is built from the same six. Automations are the scheduled heartbeat — the trigger that starts a loop with no human in the room. Worktrees are isolated filesystem branches so parallel loops don’t stomp on each other. Skills are project knowledge written down so the agent stops guessing at things you already know. Connectors — MCP, in practice — let the loop touch your real tools: the issue tracker, the database, Slack. Sub-agents are the maker/checker split (more on that next). And external state is memory on disk that survives between runs — the agent forgets, the repo doesn’t.
None of this is exotic. It’s plumbing, and the plumbing is the actual stack I run these loops on. But skip any one of these and you don’t have a loop — you have a script that occasionally calls a model.
VThe maker/checker split is the whole game
If you take one thing from this piece, take this: one sub-agent drafts, and a separate, independent sub-agent verifies the draft against tests, specs, and linters before the loop is allowed to call anything done. The reason is simple. A single model grading its own work has built-in confirmation bias. As Osmani puts it, the model that wrote the code is "way too nice grading its own homework."
The verifier is the only reason you can walk away from an unattended loop and trust what you find when you come back. This is why verification — not generation — is now the bottleneck: generating a candidate answer is cheap; proving it’s correct is the hard, valuable part. Claude Code leans on exactly this — its /goal runs a fresh model as the checker on the stop condition itself, so the thing deciding "we’re done" isn’t the same thing that wrote the work. No verifier, no walking away. Full stop.
VIGuardrails, or how loops become billing surprises
A loop without guardrails isn’t a productivity tool — it’s an open tap on your token bill. The field has converged on three hard stops. Cap iterations — a common rule is to stop the loop after twenty tries. Detect no progress — stop when the same error, an empty diff, or a failing test repeats N times in a row. And set a dollar budget. As one production engineer bluntly warned: "Without guardrails, you get infinite loops and billing surprises orders of magnitude over budget."
The numbers make this concrete. Agents burn roughly four times the tokens of a standard chat interaction, and up to fifteen times in multi-agent systems, according to Oracle’s writeup of the agent-loop pattern — a pattern every major lab (OpenAI, Anthropic, Google, Microsoft, Meta) has independently converged on. And the cost risk isn’t theoretical. Per Bloomberg, via Simon Willison, Uber capped every employee at $1,500 in monthly token spend per AI coding tool — Claude Code and Cursor tracked separately — after burning through its entire 2026 AI budget in about four months. CTO Praveen Neppalli Naga said the company was "back to the drawing board," and COO Andrew Macdonald admitted they couldn’t yet tie rising Claude Code usage to anything customers could see. If Uber can torch its budget, so can you. I’ve watched it happen up close — it’s the same lesson from when I spent $1,300 testing every major AI agent tool: the model is rarely the constraint. The economics are.
VIIWhen a loop actually pays off: my four-point test
Before I build a loop, I run the task through four questions. All four have to be yes. If even one is no, I prompt it by hand and move on.
- The task repeats — at least weekly. A loop is amortized infrastructure. Build one for a one-off and you’ve spent more designing the loop than doing the work.
- A machine can reject bad output. A test, a type-check, a build, or a linter has to be able to say "no" without a human. That’s the verifier’s teeth.
- The budget can absorb wasted iterations. Loops fail forward — they retry. If you can’t afford the retries, you can’t afford the loop.
- The agent already has a senior engineer’s tools. Logs, a reproduction environment, and the ability to actually run the code it writes. An agent flying blind just fails faster and more expensively.
aGood first loops
Start where the blast radius is small and the verifier is obvious: CI-failure triage, dependency-bump PRs, lint-and-fix passes, and flaky-test reproduction. Repeatable, machine-verifiable, hard to make worse.
bLoops to avoid (for now)
Architecture rewrites, auth and payments code, production deploys, and anything where "done" is a judgment call. No automatic verifier can sign these off, which means there’s nothing holding the loop accountable — and that’s exactly where the expensive mistakes live.
VIII"It’s just a while loop with an LLM call" — answering the backlash
The critics deserve a fair hearing, because a lot of them are engineers, not cynics. The reduction is real: strip the vocabulary away and you’ve got a while loop wrapped around an LLM call. There’s a Reddit thread openly asking whether it’s real or just another AI buzzword, an ~1,800-comment Hacker News thread making the same case, a satire site (extra-steps.dev) making it funnier, and The Register’s June 24 take arguing the latest buzzword "still needs humans in the loop" because the demos quietly hide how much steering real work takes.
The sharpest version comes from Gergely Orosz of The Pragmatic Engineer, and it’s not an anti-AI argument — it’s a preconditions argument. "Outside of the increasingly few people who 1) have unlimited AI token budgets 2) feel like prompting agents are holding them back," he wrote, "I don’t think many have a use case for them." He’s more than content prompting by hand.
He’s right, mostly. Here’s my counter: those critiques land on weak loops — no verifier, no spend cap — not on the discipline itself. A while loop with an LLM call and no checker is a while loop with an LLM call. Add the maker/checker split and a hard budget and it becomes something else. Proof the pattern works came before the name did: Geoffrey Huntley’s "Ralph loop" — a brute-simple cycle that did nothing but feed the same prompt back into the agent, over and over, until the spec was met — shipped real work. His rule still holds: "sit on the loop, not in it." Set it running and supervise from above; don’t babysit every iteration. But Orosz is also right that most people don’t need one yet.
IXThe two risks that outlast the token bill
The token bill is the risk everyone talks about. The two that actually keep me honest are quieter. Osmani names them well. The first is comprehension debt: the faster a loop ships code you didn’t write, the wider the gap between what your repo contains and what you actually understand. The second is cognitive surrender: the slow temptation to stop having an opinion and just accept whatever the loop hands back.
His sharpest observation is that the same loop, built by two different people, produces opposite outcomes. One person moves faster on work they already understand. The other uses the loop to avoid understanding it at all. The tool doesn’t decide which one you are — how you organize the work around it does. That’s most of what I think about in how I structure a one-person company around AI: staying the person who could still explain the system, not just the one who started it.
XThe bottom line: build the loop, stay the engineer
So — real or buzzword? Real. Loop engineering is genuine leverage on repeatable, machine-verifiable work with a hard budget stop. It’s not magic, it’s not a buzzword, and it’s not for everyone yet. A loop is a multiplier, and it multiplies whoever runs it — good or bad, careful or careless.
Osmani’s closing line is the one I’d tape to your monitor: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." That’s the whole verdict. Build loops where they clear the four-point test, guard them like they can bankrupt you (they can), and never outsource your own understanding to the thing you built to save time.
This — building and operating loops that hold up under real load — is most of what I do, and it’s why I wrote a verdict instead of another explainer: the four-point test, the maker/checker split, the guardrails, all of it exists to answer one question — does this task deserve a loop, or does it just deserve you? Most days, for most tasks, the honest answer is still you. But for the ones that clear the bar, build the loop, stay the engineer, and let it run.
— Michael Rouveure
