Years before any of this had a name, I had a script on my homelab box that restarted a flaky transcode job, checked the log for a specific error string, and gave up after five tries instead of running all night. It was maybe fifteen lines of PowerShell, later rewritten in Rust once I got tired of PowerShell’s startup time on that box. The retry logic was never the interesting part. The giving-up logic was. A script that retries forever isn’t automation, it’s a slow-motion outage with a delay timer.

That instinct, that the stopping condition matters more than the retry, turns out to be the entire argument behind something the industry now calls loop engineering.

Addy Osmani gave it its name and its anatomy in a June 2026 essay, crediting a post from Peter Steinberger a day earlier for the original framing. The pitch is that the job changed; you’re not typing prompts at a coding agent turn by turn anymore, you’re designing the system that prompts it for you instead.

I’ve spent nearly three decades writing the unglamorous version of that system, cron jobs and watchdog scripts, for services that never once involved a language model. Applying the same discipline to something that guesses instead of computing is the part worth digging into, and, for now, the part that’s still genuinely unresolved as engineers and data scientists continue to experiment.

The Bottleneck Was Never the Prompt

For about two years, using a coding agent meant a loop shaped entirely around a human: write a prompt, read what comes back, respond with your contextual knowledge, and repeat!

Osmani’s framing is that this is largely over. “Loop engineering is replacing yourself as the person who prompts the agent,” he wrote in the essay that gave the practice its shape, reprinted later that month on O’Reilly’s Radar. “You design the system that does it instead.”

He lists five pieces that make up a working loop, plus a sixth that ties them together.

1. Automations fire on a schedule,
2. worktrees keep parallel agents from stepping on each other’s files,
3. skills write project knowledge down instead of re-explaining it every session,
4. connectors give the loop access to real tools,
5. and sub-agents split between the one that writes and the one that checks.

The sixth, some form of memory outside the conversation, isn’t another step in that sequence. It’s what the other five read from and write to on every pass, the reason cycle forty knows something cycle one learned.

Strip the specific tool names and the first five pieces reduce to four jobs done inside a single cycle. Something has to start the cycle. Something has to route work between the agent and the tools it can reach. Something has to check the output before anyone trusts it. And something has to decide the loop is finished, or has failed enough times that it should stop trying. Call them trigger, topology, verifier, and stop rule.

Memory doesn’t belong on that list, and forcing it there is the kind of tidiness that hides the actual risk. Trigger, topology, verifier, and stop rule all reset with each pass, clean slate, new cycle. Memory is the one piece that persists past the pass that created it, which means a bad write to it doesn’t cost you one bad cycle, it costs you every cycle downstream that trusts what’s already in there. My old retry script had exactly one of the four done on purpose, because the topology was “this one box” and the trigger was “whenever cron said so,” and it carried no memory at all past a single log file it overwrote every run. What’s changed isn’t the shape of the four jobs. It’s that the thing being routed and checked now guesses instead of computes, and that there’s a persistent layer underneath accumulating state in a way none of my old scripts ever did.

The four jobs reset every cycle. Memory doesn't — it's the layer every cycle reads from and writes to.

A Thermostat for a Model That Guesses

Pull back far enough and a loop is a control system, the same feedback logic that runs a thermostat or a PID controller, applied to something that responds in probabilities instead of degrees. A thermostat works because the sensor is trustworthy: 68 degrees means 68 degrees, every time. The loop’s theoretical case is that you can get comparable reliability out of an unreliable component, a single model call, by wrapping it in a cycle that checks its own output and refuses to call the job done until a condition is actually met. That’s a real improvement over one prompt and a hope. A bounded, checked, repeatable cycle is auditable in a way a single conversation with an agent never was.

The weak point is the sensor. A thermostat’s sensor doesn’t have opinions. A loop’s verifier, when it’s another language model, does. Osmani names this directly when explaining why loops split the writer from the checker: “the model that wrote the code is way too nice grading its own homework.” Fair, but the fix has the same problem one level up. A second model grading the first model’s work is still a model, still sampling from a distribution, still capable of being confidently wrong in a way that looks exactly like being confidently right.

A Sonar blog post, published days after Osmani’s essay went up, frames this as two camps that seem to disagree. One camp trusts an LLM verifier sub-agent because it can judge things no automated test encodes, whether a change actually solves the user’s problem, not just whether it compiles. The other camp wants something that returns pass or fail identically every run: a test, a type check, a build, a static analyzer, not an opinion.

Sonar sells tooling built around that second camp’s instinct so there’s potentially some bias, but the line still holds up as the sharpest version of this argument I’ve read: “a failing build is a fact; an opinion is a starting point.”

Researchers formalizing the same problem academically call the gap between what a skill artifact tells an agent to do and what it can be shown to have done an enactment gap. Their proposed fix, a verifiable contract checked by something outside the agent’s own self-report, is the same argument in heavier vocabulary.

Verification and stop conditions really do turn one unreliable call into something closer to a bounded process. Only the deterministic half of that verification is actually deterministic, though. The half done by another model is still one guess checking another.

Same Bugfix, Two Different Workflows

Put the five pieces next to an actual task and the before-and-after gets concrete fast. Say a null-reference exception shows up three times this week in the same background job.

Under prompt engineering, I notice the pattern in Monday’s error digest, open the repo, describe the problem to the agent by hand, read the diff, ask a follow-up when the first fix misses an edge case, then open the PR myself. Every step needs me sitting there.

Under loop engineering, mapped onto Osmani’s five pieces, an automation, the trigger, runs every morning against yesterday’s error logs instead of waiting for me to notice the digest. It hands the finding to an isolated worktree, the topology, so this fix can’t collide with whatever else is in motion, and a first sub-agent drafts the null check. A second sub-agent, the verifier, checks the draft against the project’s real test suite and a skill file that already encodes the rule that this codebase logs and re-raises instead of swallowing exceptions, so the fix doesn’t just suppress the symptom. A connector opens the PR and pings wherever the team already looks for review. If the verifier can’t confirm the fix within a fixed number of tries, the loop stops and drops the finding in a queue for me instead of guessing again.

Nobody typed “fix the null check” into anything. You design the cycle once, months before this specific bug existed, and the cycle noticed a class of bug you’d described only in general terms. That’s the leverage Osmani and Anthropic’s Boris Cherny are both describing when they say the job moved: Cherny has put it bluntly, “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” I’d add, from years of building the boring non-AI version of this, that it’s the same leverage a good CI pipeline has always offered over running tests by hand. What’s actually new is the middle step. The fix itself is now written by something that reasons in language instead of executing a fixed diff, which is exactly why the verifier step carries so much more weight than it ever did in a deterministic pipeline.

A Homelab Script and the Hundred-Agent Fleet

The homelab end of loop engineering is almost boring, which is why it works. A loop I’d actually build for my own infrastructure runs on a cron trigger, hands the work to one agent, checks the result against a single verifier, did the service come back healthy, yes or no, and stops after a handful of retries, paging me instead of running all night (and eating through tokens). The whole thing costs pennies in API calls, and I can hold it entirely in my head, which means I can actually reason about what it will do at 3 a.m. while I’m not watching it.

The production end looks nothing like that, and the gap between the two is beefy. In May 2026, weeks before the term “loop engineering” existed, Peter Steinberger, the developer behind the OpenClaw agent project who had joined OpenAI a few months earlier, posted a screenshot of his API dashboard showing $1,305,088.81 in spending over 30 days, covering 603 billion tokens across 7.6 million requests from roughly 100 coding agents run by a three-person team. Steinberger framed it as research into what software development looks like without a token constraint; OpenAI, which employs him, covered the bill. Steinberger later said a high-throughput setting accounted for much of the total. Turning it off would have cut the raw cost to something closer to $300,000. Even with that caveat, six figures for one team’s month requires some interesting discussions with your leadership.

Uber’s version of the same gap wasn’t a deliberate experiment. Its CTO, Praveen Neppalli Naga, told The Information in April 2026 that the company had already exhausted its 2026 AI budget within a few months, driven largely by a surge in Claude Code usage the company itself had encouraged through internal leaderboards, and that Uber was “back to the drawing board.”

Both loops follow the same control jobs, trigger, topology, verifier, stop rule, with memory sitting underneath all four. Only one of them was ever small enough for a single person to reason about what it would do while they weren’t watching. That’s not automatically an argument against building large loops. It’s an argument that the discipline has to scale with the loop, or the loop becomes the risk instead of the fix. A homelab script with a bad stop rule wastes an afternoon. A hundred-agent fleet with a bad stop rule is a line item.

The Case Against the Loop

Loop engineering isn’t uncontested, and it shouldn’t be. Anthropic’s own engineering team, describing the multi-agent system behind Claude’s Research feature, found that agents typically use about four times the tokens of a normal chat exchange, and multi-agent setups use around fifteen times as much. That multiplier is only leverage when it buys a better answer. It’s also the kind of multiplier that makes raw token volume easy to mistake for a productivity signal, a pattern that picked up its own name this year, tokenmaxxing, treating how many tokens an engineer burns as a proxy for how much they’re shipping. Burning tokens is easy to measure and easy to inflate. Whether the work gets chucked during code review is harder to measure and gets checked less often.

The second failure mode is quieter than a budget overrun. A loop running unattended is a loop making mistakes unattended, and one operator who runs production loops daily has landed on a handful of guardrails worth borrowing regardless of scale: capping iterations at a fixed number instead of trusting the loop to know when to quit, stopping the moment the same failure repeats with no progress, and setting a dollar budget as a hard ceiling rather than a dashboard you check afterward. That operator relays a warning from a production engineer they work with, put bluntly: “without guardrails, you get infinite loops and billing surprises orders of magnitude over budget.” None of those guardrails require a language model to work, which is probably why they’re the ones that actually hold. The deterministic half of the control system is still doing the load-bearing work.

The backlash writers take this further, and the strongest version of that argument isn’t a hot take, it’s an incident list. A Fortune investigation documented Replit’s coding agent deleting a live production database of more than 1,200 executive records in July 2025, after the agent “panicked” at empty query results and ran a destructive command the project file explicitly told it not to run without human approval. Nine months later, a Cursor agent at the SaaS company PocketOS found an overscoped API token sitting in an unrelated file, used it to wipe a production database and its backups in nine seconds, and the company restored from an offsite backup with real gaps. Neither failure was missing a stop rule on paper, both projects had something that looked like one. What was missing was a stop rule the runtime actually enforced instead of one written down as a sentence the agent could reason past under pressure, which is the same distinction this piece has been drawing about verifiers all along: a check that lives outside the model’s own reasoning is a check, one that lives inside a prompt is a request. A widely read Hacker News thread makes a narrower version of the same point: strip the vocabulary away and a loop is a while loop wrapped around a model call, which isn’t new. Both critiques are fair. Neither one is really an argument against loops in general. They’re arguments against loops built without a verifier that can actually fail the work and a stop rule the system enforces rather than one the model is asked to honor, which is a smaller and more useful claim than “the whole idea doesn’t work.”

I don’t have a feel for how much I trust a verifier I didn’t write myself, though there’s some interesting experiments in flight. A deterministic check is trustworthy because it’s deterministic, and an LLM verifier earns its place precisely because it can judge things a deterministic check can’t, which means the loop is only ever as honest as the weaker half of that pairing.

Osmani, whose essay gave the practice its shape, doesn’t pretend otherwise. He’s said plainly that leaning on loops entirely, without reviewing the work himself, would leave him “stuck in a downward spiral, continuously digging myself into a deeper hole.” That’s not a hedge tacked onto an otherwise confident pitch. It’s the person who coined the term telling you the failure mode is real and he isn’t immune to it either.

My old retry script had one stop rule and nothing else, and it was honest about that limit because of scope and span. These new model loops I’m building now have more pieces, and more places for a verifier’s judgment to quietly substitute for mine without me noticing it happened. Whether that trade is worth it depends less on the loop’s design than on whether I’m still reading what it hands back closely enough to catch the moment it’s confidently wrong, but I hope we get to a better point of verifiable trust soon.