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. 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, the stopping condition matters more than the retry, turns out to be the entire argument behind what the industry now calls loop engineering.

Addy Osmani gave it its name and anatomy in a June 2026 essay, crediting a post from Peter Steinberger a day earlier for the original framing. The pitch: 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.

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 computes is the part I’m 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 (or hope your RAG is setup and tuned), 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. Sub-agents split between the one that writes and the one that checks

The sixth, or 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.

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, or 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. The loop’s theoretical case: 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 and is still sampling from a distribution that iscapable of being confidently wrong in a way that looks exactly like being confidently right.

A Sonar blog post, published days after Osmani’s essay, 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, anything that isn’t an “opinion”.

Sonar sells tooling built around that second camp’s instinct so there’s potential 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. Let’s 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 pages a human.

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.

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 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.

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 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…

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…”

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…

I don’t have a feel for how much I trust a verifier I didn’t write myself, though there are 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.

I wholeheartedly agree; it’s similar to previous sentiment I’ve shared of treating a fresh agent as “handing a junior developer all the keys, but none of the instructions, and went on holiday for a month without my mobile or laptop?” And that’s not a knock on the AI (or a junior developer), but on me to not be there to coach, guide, provide context, and ensure they can’t unknownlingly get into trouble.

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 loop skills 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.