Days. That's how long Dex Horthy's team reportedly spent wading through spaghetti code to find a single wrongly-routed primary key. Then three more weeks to re-onboard humans to a codebase no human had ever read.
That was the wreckage of an experiment that started in July 2025: let the model write the code, let humans review nothing. Four months later they shut the whole thing down and threw it out. Production broke, and no matter how hard they prompted Opus 4.1, it couldn't find the root cause.
Hold that scene. We'll come back to it, because it's the exact place where the current gospel of "loop engineering" quietly fails.
The current gospel of loop engineering quietly fails exactly where verification is missing: without an oracle, the loop never stops, it just compounds confidently-wrong work.
The gospel goes like this. Boris Cherny, the creator of Claude Code, at Anthropic's developer conference: "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."
Peter Steinberger posts his own version of this idea as a monthly reminder. Addy Osmani canonized it into a discipline he calls loop engineering. A PM newsletter reportedly spent five weeks testing whether it works for product managers.
And everyone reposting it copies the same neat anatomy: a loop needs five pieces. Automations for the heartbeat. Worktrees so parallel agents don't collide. Skills to write down project knowledge. Connectors to reach your real tools. Sub-agents so the maker isn't the one grading its own homework. Plus a sixth thing — memory on disk, because the model forgets everything between runs.
Last week I argued the harness — the code you wrap around a single agent — is the real skill, not prompt craft. This week the claim goes one floor up: loop engineering is being sold as the named successor to prompt engineering. And the floor underneath it is verification.
Here's what almost nobody reposting the five-piece anatomy is saying: four of those five pieces are just plumbing now.
Look at Osmani's own comparison table. Automations, worktrees, skills, connectors, sub-agents — every one ships inside both Codex and Claude Code today. Scheduled tasks, `git worktree`, `SKILL.md`, MCP servers, subagents defined in TOML or in `.claude/agents/`. The names differ; the capability is identical.
A year ago a loop meant a pile of bash you wrote and maintained forever. Now it's a tab in an app. As Max Kanat-Alexander put it, the loop may have just been a temporary hack while the harnesses caught up and let you do the same thing from a single prompt.
So if the primitives are commodity, what actually decides whether a loop compounds value or compounds confidently-wrong work?
One thing. The oracle.
An oracle is something outside the model that returns a hard yes or no: passing tests, a clean build, a green pipeline, a real production signal. It's what `/goal` checks against. You give it "all tests in test/auth pass and lint is clean," and after every turn, per E8's description of Claude Code, a separate small model checks whether that condition actually holds — so the agent that wrote the code isn't the one grading it, and the loop keeps running until the answer is genuinely yes.
Without that oracle, the loop doesn't stop. It just keeps going, generating more work you're not watching, and it compounds errors faster than you can read them.
Now go back to Dex Horthy's four-month collapse. What was missing wasn't automation, worktrees, skills, or connectors. Those experiments had plenty of plumbing. What was missing was a verification oracle strong enough to catch that a primary key was being routed wrong through the entire codebase.
That's the part that can't be faked. Horthy's own diagnosis of why models degrade codebases points straight at it: today's models are trained to ace SWE-bench-style benchmarks that reward reproducing a known fix, because you can run a unit test and get a yes/no. But the cost of bad architecture "cannot be evaluated by running a unit test." There's no oracle for it. So the loop happily ships it.
This is why the disappointment stories cluster where they do. Devs who tried looping and rejected it report the agent drifting and the "human in the loop" simply getting better results. Some hit "tokenmaxxing" — the loop burns money at API prices with nothing hard to stop it. In every case the failure isn't a missing primitive. It's a missing stopping condition.
Which reframes the whole skill shift. The industry is selling this as a jump from language craft to systems design in general — learn the five pieces, wire them together, become a loop engineer. That framing is wrong, or at least it hides the load-bearing part.
The real shift is narrow and teachable: it's the specific act of writing a stopping condition and a verification for work you are not going to watch. Everything else is configuration.
Watch what happens when someone actually does this well. Claire Vo built a custom harness for Sentry bug triage at ChatPRD. The interesting move isn't the tooling — it's that she encoded "investigate only, do not write code" as a flag she clicks, not a prompt she has to remember to type every time.
The tradeoff, per E5's summary: "Giving a constrained agent a specific harness gets more consistent output than giving a powerful agent an open prompt." The open chat field was good enough, she says, until it stopped being good enough.
Notice what she constrained. Not the model's intelligence — its permissions and its endpoint. She built an opinionated Sentry adapter that pulls exactly what a bug report needs and nothing else, so the agent can't wander off into traces. And every run emits the same artifact bundle: a task log, an issue brief, relevant logs, a worker report, an HTML summary.
That artifact bundle is the oracle in disguise. It's a defined, checkable "done" — a specific yes/no shape the output has to take. She replaced "figure out when you're finished" with a condition that either holds or doesn't.
That's the whole game, and it's the same game underneath Osmani's later, more honest framing: agents run the inner loop — investigate, implement, verify — and humans own the outer loop, the decision that the work is actually safe to ship. His words: "an independent check, not the model's own say-so, decides when the work is done."
Independent check. Outside the model. Hard yes or no. Same oracle, every time.
The market data makes the stakes concrete. In Sonar's 2026 report, 42% of committed code was AI-generated or significantly AI-assisted, and teams expect that to keep climbing. GitLab's June 2026 research found review and validation are already the bottleneck — and that governance usually happens after the code is created, after the risk has been accepted.
Creation got cheap. Verification didn't. The scarce resource now is the thing that decides when autonomous work is done — and no primitive shipping inside Codex or Claude Code writes your stopping condition for you.
So here's the honest version of the meme. You can copy Cherny's line and repost the five-piece anatomy all you want. You can wire up automations, worktrees, skills, connectors, and sub-agents in an afternoon, because they ship in the box now.
But if you cannot specify a hard yes/no condition for the work you're handing off — the auth tests pass, the artifact bundle is complete, the production signal is green — you will not get leverage from any of it. Your loop won't compound value. It'll compound Dex Horthy's four months, just faster, because the newer models generate the wreckage sooner.
Loop engineering is real. It just isn't the five pieces. It's the one you have to write yourself.