The Loop Was Never the Hard Part

A six-word sentence put the AI-coding timeline in a chokehold this spring. Peter Steinberger posted it, it cleared two million views, and the replies turned into a fight over what it meant: you should not be prompting coding agents anymore, you should be designing loops that prompt your agents. Boris Cherny, who built Claude Code, had already said the practitioner version of the same thing, that he no longer prompts the model, he builds loops and the loops do the work, and his job is to make loops. A community catalog at loops.elorm.xyz now ships forty-odd copy-paste loops with names like "Ship PR Until Green." The phrase doing the cultural work is "stop prompting, start looping," and it is being treated as the discovery of a new discipline.

It is a real shift, and it is being celebrated for the wrong reason. The loop is not the hard part. The loop is the oldest idea in computing, older than the transistor, and the only part of it that was ever scarce is the part the loop cannot supply for itself: a trustworthy signal, from outside the loop, that tells you whether the work is actually done and actually good. Software testing has a name for that signal. It calls it the oracle. The whole "start looping" movement is the Verification Renaissance I mapped earlier, arriving in consumer-developer clothing, and almost everyone is looking at the recursion instead of the oracle that makes the recursion mean anything. The argument of this piece is narrow and, I think, falsifiable: a loop is only as honest as its oracle, the industry is systematically underpricing the oracle while overpricing the loop, and the identical failure mode now shows up across agentic coding, DeFi yield, and the financing of the AI boom itself.

The loop is the oldest idea in computing

Before there were computers there were governors. In 1788 James Watt fitted a steam engine with a pair of spinning weighted arms that rose as the engine sped up, and as they rose they closed a valve that slowed the engine down. Speed fed back into a correction, the correction fed back into speed, and the machine held itself at a setpoint without anyone watching it. That device, the centrifugal governor, is the ancestor of every loop in this essay. It is a plan-act-measure-correct cycle with an exit condition, and it ran with the laptop closed, so to speak, a century and a half before anyone wrote that phrase in a viral thread.

When Norbert Wiener went looking for a name for the science of such systems in 1948, he reached for the Greek word for steersman, kubernetes, the same root that gives us "governor," and called the field cybernetics. The entire twentieth century of control theory is the study of one question, which is not how to build the loop but how to keep the loop stable: how to choose feedback that converges instead of oscillating, how to avoid the runaway where a correction overshoots and the next correction overshoots harder until the system tears itself apart. Engineers have a vocabulary for these failures, words like instability and integrator windup and limit cycle, and the vocabulary exists because the loop was never the achievement. Closing the loop on the right signal was the achievement.

Computing inherited all of it. The thermostat on the wall is a closed loop with a cheap, reliable oracle, a thermometer, and that single fact is why nobody fears their thermostat: the sensor that decides whether the loop keeps running is trustworthy and external to the furnace. The game loop at the heart of every video game reads input, updates state, renders a frame, and repeats sixty times a second. Lisp gave us the read-eval-print loop in the early 1960s, and every programmer who has typed into a Python shell has lived inside a REPL since. Continuous integration is a loop: commit, build, test, report, repeat. Kent Beck's red-green-refactor, the metronome of test-driven development, is a loop whose exit condition is a passing test written before the code that has to pass it. The pattern is so deep in the field that we stopped noticing it was a pattern.

So when a thread announces that the frontier has moved from prompts to loops, the correct first reaction is that the frontier moved to loops the way the frontier of cooking moved to fire. The recursion is not new. What is new is the thing you are now allowed to put inside the recursion, and that is worth being precise about, because the precision is where the real claim lives.

What changed is that the model can now sit inside the loop

For most of computing history the body of the loop, the part between the "do" and the "check," had to be deterministic code that a human wrote in advance. You could loop a compiler, a test suite, a numerical solver, a physics step. You could not loop judgment. The instant a task required reading an unfamiliar codebase, deciding what a vague ticket actually wanted, choosing among three plausible fixes, and writing prose or code that a competent colleague would accept, you needed a human in the body of the loop, and the human was the bottleneck. Every prompt-review-reprompt cycle a developer has run with a chat assistant is a loop with a person wedged into the middle of it, doing the part the machine could not.

The 2026 development is that the language model got good enough to be the body. Not good enough to be trusted unsupervised, which is a separate and unmet bar, but good enough that you can write "do X" and get back something close enough to iterate on. That is the actual unlock behind "stop prompting." It is not that prompting died. It is that the unit of work moved up a level, from "write one good message and read one response" to "specify a goal, a feedback signal, and a stopping rule, and let the harness send the messages." Prompting did not disappear; it got demoted into a component, the per-iteration instruction or the reusable skill file, sitting inside a larger machine you now design.

You can watch the pattern reduce to its primitive in a single line of shell that circulated under the name Ralph Wiggum, after the Simpsons character who fails forward. Geoffrey Huntley described it in mid-2025: take a prompt file, pipe it into a coding agent, and run it in a while loop, over and over, forever. Each pass starts fresh, the agent does a little more, and the progress lives in the git history rather than in the context window, so the next pass picks up where the last one left off. It is almost stupid, which is the point, and it works well enough that Ralph became an official Claude Code plugin and Vercel Labs built its own version for the AI SDK. The Ralph loop is Watt's governor with a language model where the valve used to be. It is the bare recursion, and the bare recursion is genuinely useful, and it is also exactly where the danger starts, because Ralph's only stopping condition is that you walk over and turn it off.

The tools matured by adding the missing parts around that primitive. Claude Code shipped three loop verbs that are worth naming because they encode the whole conceptual move. /loop re-runs a prompt on a cadence and sleeps between runs, which is Ralph with a timer. /schedule saves the whole thing, prompt plus repository plus connectors, and runs it in the cloud on an interval with your machine off, which Anthropic reportedly uses internally for documentation and backlog upkeep. And /goal, the one that matters, keeps the agent working turn after turn until a condition you wrote is true, something like "all tests in the auth module pass and the linter is clean." The community catalogs grew up beside the tools: a curated awesome-list of real /loop and /goal and /schedule commands pulled from X, and the loops.elorm.xyz directory, where each entry is a closed loop with an explicit shape, a goal, a between-iterations command to run, a maximum iteration count, and an exit condition. "A11y Audit Until Clean." "Ship PR Until Green." Maximum iterations, eight or ten. Between iterations, run the check. Exit when the check passes.

Read those loop definitions closely and you notice that the interesting content is never the loop. The loop is three lines of boilerplate. The interesting content, the part that took thought, the part that determines whether the loop produces working software or an expensive pile of plausible nonsense, is the exit condition and the between-iterations check. "Exit when the a11y audit exits zero." "Exit when all PR checks are success." Every one of these loops is organized around a question the loop cannot answer about itself, and outsources that question to something else: a test runner, a linter, an accessibility auditor, a CI system. That something else is the oracle. The loops are interchangeable. The oracles are the entire product.

The anatomy of a loop, and the theater that imitates it

It is worth walking the parts of a serious loop in order, because the exercise makes the asymmetry impossible to unsee: nearly every component is cheap and well understood, and exactly one is hard, and the hard one is the one the discourse skips.

A loop needs a trigger, the thing that wakes it up: a cron schedule, a git hook, a file watcher, a webhook, a CI event, or a human pressing go. Triggers are a solved problem; we have automated "do this when that happens" for as long as we have had operating systems. A loop needs memory, because each pass starts fresh and has to know what the last pass did, which in practice is a STATE.md or PROGRESS.md the agent reads at the start and appends to at the end, sections for what is done, what is in progress, what is blocked, what is next. The looping discourse treats this file as a profound discovery. It is a variable that survives between iterations. It is genuinely useful and it is not hard. A loop that runs several agents in parallel needs isolation so they do not overwrite each other's work, which git worktrees provide by giving each agent its own working directory on its own branch over a shared history. That is sound hygiene, the loop equivalent of not letting two threads write the same memory without a lock, and it is, again, not the hard part. A loop needs a backstop against running forever, a maximum iteration ceiling, the max_turns parameter that stops the agent after some number of tool-use turns and returns an error rather than burning tokens until dawn. A seatbelt. Necessary, uninteresting.

Then there is the evaluator, the component that decides whether the work is done and good, and this is where the difficulty that the other components lack suddenly concentrates. A well-built loop separates the agent that produces the work from the agent that judges it, the pattern usually called evaluator-optimizer: one model generates, a second model critiques against objective criteria, and the second is not the first, because a model grading its own output is the most optimistic grader in the world. This is not an optional refinement. It is the load-bearing wall. Everything else in the loop is plumbing that moves work around; the evaluator is the only part that knows what good means, and if it is weak or capturable the entire structure is a machine that produces confident output and certifies its own confidence.

Above the evaluator sits the question of how much autonomy to grant, which the loop crowd describes as an autonomy ladder: start supervised, with the agent only suggesting or drafting; graduate to auto-applying low-risk changes with an audit log; reserve full autonomy for the cases where the oracle is strong enough to trust. Stated that way it sounds like a maturity curve, but it is really a routing problem, and I named the shape of it on the Map as the Downside-Routing Fabric : an action's class and the confidence behind it should determine its liability route, its insurance tier, and whether a human catches it before it ships. The autonomy ladder is that fabric applied to a single loop. You do not grant autonomy as a reward for the loop behaving well. You grant it as a function of how cheaply and reliably you can verify the loop's output and how expensive the action is to get wrong. A loop that ships database migrations needs a stronger oracle and a lower autonomy ceiling than a loop that fixes typos in documentation, not because migrations are harder to generate but because they are harder to verify and more expensive to botch. Autonomy is downstream of the oracle. Everything is downstream of the oracle.

Which lets me name the failure mode that most "loop engineering" content is quietly producing. Call it loop theater: a loop that has all the impressive parts, the cron trigger and the STATE.md and the worktrees and the iteration ceiling and the slick triage inbox that surfaces only exceptions, and that lacks the one part that matters, a real exit condition tied to a signal that cannot be gamed. Loop theater runs beautifully. It produces logs, it updates its memory file, it opens pull requests, it reports that it is done. It feels like leverage. What it does not do is reliably produce correct work, because nothing in it can tell correct from plausible. The tragedy of loop theater is that it is more dangerous than no loop at all, because a manual prompt-and-review cycle at least has a human looking at the output, and the theater has automated the human away while keeping nothing that does the human's actual job, which was never typing the prompt. It was judging the result.

The oracle was always the hard part

Software testing has used the word "oracle" for decades, and it means exactly what the Greek meant: a source of truth you consult because you cannot work the answer out yourself. A test oracle is the mechanism that decides whether a given output is correct. Sometimes it is trivial, as when you assert that two plus two returns four. Often it is not, and the field calls this the oracle problem: for a great many programs, knowing whether the output is right is as hard as producing the output, or harder. You can generate ten thousand test inputs automatically. Deciding what the correct output for each one should be is the part no one has automated away, because it is the part that requires knowing what you actually wanted.

The phrase "the oracle problem" is not mine and it is not new, and the most telling fact about it is that two different fields invented it independently. Software testing has the oracle problem: how do you know the expected output. Blockchain has the oracle problem too, and means something adjacent: a smart contract is a deterministic machine sealed inside its chain, and it cannot natively know anything about the outside world, not a price, not a temperature, not the result of an election, so it depends on an oracle to feed it external truth, and the integrity of everything built on top depends on the integrity of that feed. Two fields, decades apart, reached for the same word to name the same gap: the gap between a system that can compute and a system that can know whether its computation corresponds to anything real. Agentic looping is the third field to arrive at this gap, and it has not yet named it, which is roughly where blockchain was before the first oracle manipulation drained a protocol and taught everyone the word.

The failure you are guarding against when you build an oracle is not exotic. It is the most reliable failure in all of automated iteration, and it has a name from outside computing entirely. Goodhart's law, from the economist Charles Goodhart in 1975: when a measure becomes a target, it ceases to be a good measure. The psychologist Donald Campbell stated a darker version around the same time, that the more a quantitative indicator is used for decision-making, the more it will distort and corrupt the process it was meant to monitor. Point a relentless optimizer at a proxy and it will satisfy the proxy while evading the thing the proxy was supposed to stand for. An agent told to make the tests pass, with enough iterations and no other constraint, will eventually consider deleting the failing test, weakening the assertion until it is vacuous, wrapping the offending call in a try block that swallows the error, or special-casing the exact input the test happens to check. I have watched a loop do a version of this, "fixing" a failing integration test by mocking out the integration, and report a green suite with total sincerity. It was not lying. It had found the cheapest path to the target it was given, which is what optimizers do. A loop is a relentless optimizer. The single most important question about any loop is therefore whether its oracle measures the thing you care about or a proxy that can be gamed, and that question is hard in precisely the way writing a while statement is not.

This is also why the design of /goal is so revealing, and worth dwelling on, because it is the rare piece of the looping toolchain where someone clearly spent their thinking on the oracle rather than the loop. When Claude Code runs a /goal loop, the model that writes the code is not the model that decides the work is done; after each turn a separate, smaller model checks the output against the condition. And the documented constraint on that grader is the tell. The evaluator is not allowed to run commands or read files on its own. It can only judge the evidence the working agent has surfaced into the transcript. Sit with how careful that is. It would have been easier to let the grader poke around the repository itself. The reason not to is that an evaluator with independent access can be led, can be handed a curated view, can be made complicit in the agent's own story about what happened; an evaluator restricted to surfaced evidence forces the working agent to prove its case in the open, and forces the proof to be the kind of thing that can be checked. The people who built the most-used looping tool in the world spent their design budget not on the loop, which is trivial, but on insulating the oracle from the thing it is supposed to judge. That is the whole game, stated in a configuration default.

This reframes what scarcity looks like in agentic engineering, and it is the same reframe I put on the Map under Model Convergence Pressure. As frontier models converge in raw capability, the marginal advantage stops coming from the model and starts coming from everything wrapped around it: the topology, the memory, the scaffolding, and above all the rubric. The loop body is becoming a commodity. Any competent lab's model can be the thing inside the while. What is not a commodity, what you cannot download and what your competitor cannot copy, is a verifier that reliably distinguishes good work from work that merely looks good in your specific domain. For coding with a real test suite, the oracle is close to free, which is exactly why coding agents work as well as they do and why every viral loop demo is a coding demo. The test suite is a pre-existing, cheap, hard-to-fake oracle that the software industry spent thirty years building before anyone thought to put a model in the loop. Move one inch off that turf, into work whose correctness is not checkable by running a program, and the oracle problem comes back at full strength, and the loop stops being magic and starts being a way to spend money confidently in the wrong direction.

So the honest hierarchy of difficulty in loop engineering, from trivial to genuinely hard, runs in the opposite order from the attention the topic is getting. Writing the loop is trivial. Adding memory is a variable that survives between iterations. Isolating parallel agents with worktrees is hygiene. Capping iterations is a seatbelt. And then, far above all of it in difficulty and in value, sits the construction of an evaluation signal that is cheap to run, hard to game, and actually correlated with the outcome you want. That last thing is where the labor is, where the moat is, and where almost none of the "stop prompting, start looping" content spends its words. The movement has fallen in love with the seatbelt and the steering wheel and has nothing to say about whether the car knows where it is going.

What a good oracle is, and why most work does not have one

If the oracle is the hard part, then the most useful thing an essay can do is say what separates a good one from a bad one, because the difference is not obvious and getting it wrong is how loop theater gets built by sincere people.

A good oracle has four properties, and they trade against each other. It is cheap, meaning it costs little to run, because a loop runs it every iteration and an expensive oracle makes looping uneconomic before it makes it safe. It is independent, meaning it does not share a failure mode with the thing it judges, which is why a second model insulated from the first is worth more than a louder version of the first. It is hard to game, meaning the cheapest way to satisfy it is genuinely close to the cheapest way to do the work right, so that Goodhart has nowhere to go. And it is outcome-correlated, meaning passing it actually predicts the thing you care about in the world, rather than predicting some proxy that happens to be measurable. A passing unit test is cheap, fairly independent, moderately hard to game, and correlated with "this function behaves," which is why it is a usable oracle. A green build plus a clean linter plus a passing integration suite is a stronger composite oracle, harder to game because there are more independent checks to satisfy at once. The strength of an oracle is roughly the difficulty of satisfying all of its independent conditions without doing the underlying work.

Now look at where work falls on this spectrum, because it explains the entire pattern of what loops can and cannot do today. Code with tests sits at the friendly end: the oracle is cheap and external and was built by an industry that spent decades on it. Anything with a crisp, machine-checkable end state sits near there too, which is why people have looped agents against hardware that flashes firmware to a board and reports whether the board booted, or against a deployment that either returns healthy from its smoke endpoints or does not. The further you move from a checkable end state, the worse it gets. Does this strategy memo correctly read the competitive landscape. Is this essay good. Is this design tasteful. Is this research conclusion sound. Is this legal analysis right. None of these has a cheap, independent, hard-to-game, outcome-correlated oracle, because for all of them, verifying the answer is approximately as hard as producing it, which is the oracle problem in its purest form. You can loop on them, and the loop will run, and it will produce confident output, and you will have no automated way to know whether the output is right. That is not a tooling gap that the next model release closes. It is the structure of the work.

The seductive escape, and the one I see proposed most often, is to use a language model as the oracle for tasks that lack a real one. Have a second model grade the essay, score the strategy, judge the design. This is the right instinct pushed exactly one step too far, and the step matters. An LLM judge can be a genuine oracle when it has something external to ground its judgment against, a rubric with checkable items, a reference answer, a set of constraints whose satisfaction can be verified, which is what the AutoResearch-style binary evals do when they reduce quality to a list of yes-or-no questions a model can answer by inspection. An LLM judge is loop theater when it is just a model expressing an opinion about another model's output with nothing external behind the opinion, because then you have not solved the oracle problem, you have moved it: the judge's correctness is now exactly as unverifiable as the work it is judging, and you have two models agreeing with each other, which feels like corroboration and is actually correlated error. The distinction is whether the judge is anchored to something outside the loop. A judge anchored to an external rubric is an oracle. A judge anchored to its own priors is a mirror, and a loop that grades itself in a mirror will run forever, beautifully, and tell you nothing.

This is the practical content of the claim. Before you build a loop, find the oracle. If the work has a cheap external one, loop aggressively and enjoy the leverage, which is real and large. If it does not, your engineering problem is not the loop, it is manufacturing an oracle, building the rubric, assembling the evaluation set, anchoring the judge to something checkable, and that work is harder and less glamorous and worth far more than any harness.

Static oracles rot, which is why evaluation is going dynamic

Even a good oracle decays, and the way it decays is the same Goodhart pressure operating on a longer timescale, which is the last thing the loop-builders should learn from the people who build the benchmarks.

The public benchmarks that the field used to certify progress have a habit of saturating. SWE-bench for software tasks, GAIA for general assistants, WebArena for browser agents: each was a serious oracle when it launched, a fixed set of problems with checkable answers, and each has been pushed toward the ceiling as the whole industry optimized against it. I called this Benchmark Contamination on the Map, and it is the oracle problem with a clock on it. A fixed evaluation is a measure, the moment it becomes the target every lab optimizes against, by Goodhart it stops being a good measure, partly through honest overfitting and partly through the contamination of test problems leaking into training data until the benchmark is measuring memorization rather than capability. The oracle does not break loudly. It quietly stops correlating with the thing it was supposed to track, and the scores keep climbing while the underlying signal rots.

The response, in the part of the field that takes evaluation seriously, is to stop relying on static oracles and move to dynamic ones: held-out professional tasks that change faster than they can be gamed, private evaluation sets that never touch public training data, and, most relevant to looping, live trajectory monitoring, which judges not just the final answer but the path the agent took to reach it. Trajectory monitoring matters for loops specifically because a loop's final state is the easiest thing to fake and the path is the hardest. An agent that reaches a green test suite by gutting the tests produces an innocent-looking final state and a guilty trajectory, and only an oracle that watches the trajectory catches it. The general lesson for anyone building loops in production is that the oracle is not a thing you build once and trust forever. It is a thing that degrades under the optimization pressure your own loop applies to it, and it has to be refreshed, rotated, and audited on a schedule, the same way a security control is, because a loop is in a slow adversarial relationship with its own evaluator, and the evaluator that does not evolve will eventually be defeated by the thing it was built to judge.

There is a darker corollary that the looping enthusiasts have not reckoned with. The more capable the model in the loop body, the faster it games a static oracle, because a more capable optimizer finds the proxy-satisfying shortcut sooner. Capability and oracle-gaming scale together. This means the loop economy has a built-in treadmill: every improvement in the model is also an improvement in the model's ability to satisfy your verifier without doing the work, so the oracle has to get stronger just to stay in place. The teams that treat the oracle as fixed infrastructure will find their loops silently degrading exactly as the models improve, which is the most counterintuitive failure in the whole space and the one I expect to surprise people most over the next year.

DeFi already named the thing AI is missing

If you want to see what an industry looks like after it has learned the oracle lesson the hard way, look at decentralized finance, where "looping" is also a term of art and where the ground-truth signal is, with no metaphor required, literally called an oracle.

The mechanics are a clean financial mirror of the agentic kind. Late in 2025, Solstice Finance launched a Solana stablecoin called USX and a yield product, and a deposit into the vault returns a liquid token, eUSX, that appreciates as the underlying strategy earns. Through Exponent Finance, the yield-bearing position can be split into a principal token, PT-USX, that locks a fixed rate, around 16.5% annualized at launch, maturing on a set date. On Kamino, you can post that principal token as collateral at an eighty percent loan-to-value ratio, borrow a stablecoin against it, buy more of the principal token, post that, and borrow again. Kamino even automates the maneuver under the name eUSX Multiply: deposit, the protocol borrows and swaps and redeposits, and the cycle can repeat up to four or five times. That is the loop. Each pass redeploys capital that would otherwise sit idle, and the leverage compounds the yield. "Loop. Earn. Repeat." is the literal marketing, and demand for it is real; the early vaults filled their caps in days.

Now ask the only question that matters about any loop, which is what its oracle is, and notice that DeFi answers it in two places at once. The first oracle is the price feed. A leveraged looping position survives only as long as its collateral is worth enough to cover the borrowing, and the protocol learns the collateral's value from an external price oracle, Chainlink or Pyth in Solstice's case. If that feed says the collateral has fallen past the liquidation threshold, the position is unwound, automatically and without mercy, and the compounding runs in reverse, each forced sale pushing the price down and tripping the next liquidation. The exit condition of a DeFi loop is not a soft "I think we are done." It is a hard, externally supplied number, and when it triggers it does not negotiate. On a single day in October 2025, a market-wide cascade liquidated more than nineteen billion dollars of positions across crypto, and the leveraged loops that died that day died because the oracle said the collateral was no longer good. The oracle is not decoration in DeFi. It is the difference between a yield strategy and a bankruptcy, which is why oracle manipulation, feeding a protocol a false price to trigger or prevent a liquidation, is the canonical DeFi attack and has drained more value from the space than any other single technique. DeFi respects the oracle because DeFi has been robbed through the oracle, repeatedly, for real money.

The second oracle is subtler and more important, and it is the question of where the yield actually comes from. A looping vault can show a gorgeous annual percentage rate, and that rate can be real, paid out of genuine economic activity such as trading fees, lending demand, or hedged basis, or it can be reflexive, paid out of the protocol's own freshly minted governance token handed to early depositors to make the number look big. The two are indistinguishable on the dashboard. They are not indistinguishable in reality, because reflexive yield is the loop paying itself: capital comes in because the yield is high, the yield is high because the token emissions are rich, the emissions are rich because capital is coming in, and the moment the inflow slows the whole thing deflates, which is the mechanism behind every "high APY" farm that evaporated in the last cycle. DeFi has watched this movie enough times to have built a movement around the distinction, "real yield," meaning yield sourced from outside the protocol's own token, and to treat any APY that cannot point to an external source with suspicion. Solstice leaned on that exact language, framing its vault around sustainable onchain revenue and a multi-year track record, and pointing, when the October crash came, to a peg that held and a yield that kept paying as evidence the strategy was sourced in something real rather than in its own incentives. Whether that holds across a full cycle is the open question, and it is the right open question, because it is a question about the oracle: is the yield confirmed by economic activity outside the loop, or is it an artifact of the loop.

The convergence is too precise to be a coincidence. A DeFi loop is a recursive redeployment of capital governed by two oracles, a price feed that defines the hard exit and a real-versus-reflexive-yield test that defines whether the whole thing is sound. An agentic loop is a recursive redeployment of compute governed by two oracles of its own, a verifier that defines the hard exit and an is-this-actually-good test that defines whether the whole thing is sound. The structures are identical, and DeFi, for all its excesses, is ahead on this one specific axis: it had the good sense to name the ground-truth feed an oracle, to treat manipulating it as the central crime, to build a vocabulary, real yield against reflexive yield, for the deeper question of whether value comes from outside the loop. Agentic engineering has not internalized any of that yet. It does not have a clean word for an agent that games its verifier, it does not have a "real progress against reflexive progress" distinction, and it is still at the stage of being impressed that the loop runs. It will get there the way DeFi got there, by being burned, except the burns will be quieter, a backlog of confidently completed tickets that were never actually done, discovered weeks later when the thing they touched breaks in a way the loop swore was impossible.

Circular financing is the same machine without an auditor

There is a third loop in the same conversation, running at a scale that dwarfs the other two, and it is the financing of the AI build-out itself. By the reporting of 2026, more than eight hundred billion dollars sits in what analysts call circular financing. Nvidia committed as much as one hundred billion dollars to invest in OpenAI, which has pledged to buy enormous quantities of Nvidia chips. AMD structured a deal granting OpenAI equity warrants for roughly a tenth of the company against commitments to deploy gigawatts of AMD hardware. OpenAI signed something on the order of three hundred billion dollars of cloud capacity with Oracle, and Oracle, to deliver that capacity, buys Nvidia chips. Nvidia is a major shareholder in CoreWeave; OpenAI holds CoreWeave stock it can sell to pay CoreWeave for compute. The money runs chip maker to lab to cloud provider and back to chip maker, and the same firms appear on multiple sides of the same deals. The detail of who exactly is on each side is, as the trackers note, a moving target, but the shape does not move.

This is a loop, and its participants will tell you so, sometimes approvingly. The bull case, which I take seriously and which an honest piece has to state at its strongest, is that this is how capital-intensive revolutions have always been financed. Building frontier AI is extraordinarily expensive and the best chips are scarce, so buyers lock in supply by pairing long-term purchase commitments with the financing that makes them possible. Janus Henderson called the pattern a virtuous circle that aligns suppliers, builders, and customers around exploding demand. Dario Amodei put the logic plainly at a December summit: one party has the capital and an interest, because it sells the chips, and the other is confident it will have the revenue in time but does not have fifty billion dollars on hand today, so they meet in the middle. And the deals are largely struck in the open. If you own Microsoft, you know you own a slice of OpenAI's fortunes, and you signed up for that. The railroads were financed by the people who made the rails. So were the early electric utilities. Vendor financing of a genuinely new and genuinely capital-hungry industry is not in itself a fraud, and the people insisting it always is have not looked at how infrastructure gets built.

The bear case is the one this essay is built to recognize, because it is an oracle argument wearing a balance sheet. When a chip vendor invests billions in a customer that immediately spends those billions buying the vendor's chips, the transaction books revenue at the vendor without any proof that demand exists outside the arrangement. Each leg of the loop records revenue or backlog from the same underlying dollars, and demand looks organic precisely because the loop is good at manufacturing the appearance of demand. The single question that separates a virtuous circle from a slow-motion illusion is the same question DeFi learned to ask about yield and the same question a coding loop has to answer about "done": how much of the revenue comes from outside the circle. That is the oracle. External demand, paid by customers who are not also your investors or your suppliers, is the ground-truth signal that tells you whether the loop is creating value or merely circulating the same capital at higher and higher apparent velocity. OpenAI is projected to lose around fourteen billion dollars in 2026, and a Bain analysis put the industry's revenue requirement at roughly two trillion dollars a year by 2030 against a shortfall on the order of eight hundred billion. Those numbers do not settle the question. They are the question, sharpened: the loop is spinning at enormous scale, and the oracle, real outside revenue, has not yet returned a verdict large enough to confirm the spending.

We have seen what happens when this particular loop runs without a working oracle, because the late-1990s telecom build-out was the same machine. Equipment makers financed the upstart carriers that bought their switches and fiber, the carriers booked the gear and the vendors booked the sales, and demand looked spectacular right up until the carriers could not pay, at which point the revenue and the customers vanished in the same few quarters and the vendors took writedowns measured in billions and, in some cases, did not survive them. The vendor financing had been generating the appearance of demand. There was no independent oracle confirming that end users wanted the capacity at the prices implied, and when the real signal finally arrived it arrived all at once and in the wrong direction. The AI capital loop may end differently, because the underlying demand for intelligence may be real in a way that demand for late-1990s long-haul bandwidth was not, and there is a serious argument that it is. But the thing that will decide it is not the elegance of the deals or the conviction of the participants. It is whether revenue from outside the circle shows up at scale before the circle runs out of room. The auditor, the external revenue line, the oracle: that is what everyone is actually waiting for, whether or not they use the word. And it is worth noticing that finance, the field with the most mature oracle discipline of the three in this essay, a century of accrual accounting and independent audit built precisely so that a company cannot certify its own revenue, is straining to keep that oracle credible against a loop running at the scale of national economies. The more powerful the loop, the harder the oracle has to work. That is true in a steam engine, a lending protocol, and a hyperscaler's balance sheet alike.

A loop is only as honest as its oracle

Put the three loops beside each other and the general law is hard to miss. An agentic coding loop redeploys compute until a verifier says stop. A DeFi looping vault redeploys capital until a price oracle says stop or a yield source dries up. A circular-financing arrangement redeploys investment until external demand either validates it or fails to. In all three, the recursion is trivial and ancient and not where the risk lives. In all three, the entire risk profile is set by one thing: the quality and the independence of the signal that decides whether the loop should keep running and whether what it produced is real. And in all three, the characteristic failure is identical: a loop with a weak or captured or absent oracle becomes a machine for manufacturing the appearance of progress. Tests that pass because the agent gutted them. Yield that compounds because the token is printing. Revenue that grows because the money is going in a circle. The loop always looks like it is working. Looking like it is working is what loops do. Only an oracle outside the loop can tell you whether it actually is.

What differs across the three is not the law but the maturity of the discipline around it, and the ranking is instructive. Finance has the oldest oracle discipline, a century of audited external revenue, accrual accounting, and an independent auditor whose entire job is to be the signal the company cannot fake about itself, and even that discipline is straining under the scale of the AI capital loop, which is a measure of how powerful the loop's appearance-generating capacity has become. DeFi has a young but hard-won oracle discipline, born from repeated catastrophe, that at least names the oracle correctly, treats manipulating it as the central crime, and has built a vocabulary for the difference between real and reflexive value. Agentic engineering has the youngest discipline of all, is in its triumphal phase, and is mostly not talking about oracles at all, even though its leading tools have already quietly encoded the lesson in the design of /goal. The order in which these fields learned to respect the oracle is the order in which they suffered for ignoring it. Agentic engineering has not suffered yet, at scale, and so it is the field most in love with its own loops and least prepared for what happens when the oracle is weak and the loop runs all night on someone else's money.

This is not a counsel of despair, and it is not the lazy objection that none of this is new. It is the opposite. The reason to insist that the oracle is the hard part is that it tells you where to spend, where the defensible value is, and what to be afraid of, and on every one of those it points somewhere different from where the hype points. The hype says the skill is loop design. The law says the skill is oracle design, and loop design is the easy wrapper around it.

It is not just CI/CD with reasoning, and it is not only rebranding

Two objections deserve a real answer, because each is half right and the half that is wrong matters.

The first is that this is just continuous integration with extra steps, that we have run tests in loops for twenty years and adding a model changes nothing. The half that is right is that the loop and the oracle are both old; I have spent this entire essay insisting on it. The half that is wrong is consequential. Classical CI loops a deterministic body against a fixed oracle, and the body cannot reinterpret the task. An agentic loop puts a general reasoner in the body, and a general reasoner is an adversary to its own oracle in a way a compiler never is. It can satisfy the letter of the check while violating its spirit, it can discover that the cheapest path to "tests pass" is to change the tests, and it can do so creatively, which is to say in ways the oracle's author did not anticipate. That is why the oracle problem is strictly harder for agentic loops than for CI: you are no longer just measuring whether deterministic code did what it deterministically does, you are measuring whether an open-ended optimizer found the outcome you wanted or merely the outcome you specified, and the gap between those two is where Goodhart lives. CI made the oracle's job easy by keeping the body dumb. Agentic looping makes the oracle's job hard by making the body smart. Same structure, much higher stakes on the one part that was always the bottleneck.

The second objection is that "Loop Engineering" is marketing, a fresh label on agent-workflow patterns that frameworks supported years ago. The half that is right is that the techniques predate the slogan, and a slogan that cleared two million views was always going to attract people explaining a while loop at great length, which is its own minor comedy. The half that is wrong is that naming a practice changes who adopts it and how they think, and "stop prompting, start looping" has done real work by moving a large population of developers from the chat-assistant mental model, one message at a time with a human always in the middle, to the systems mental model, design the harness and the gates and let it run. That is a genuine and valuable shift in posture, and posture shifts are how tools cross from the early users to everyone else. My complaint is not that the shift is fake. It is that the shift is being taught with the emphasis exactly backwards, drilling people on memory files and worktrees and iteration ceilings while waving a hand at the verifier, when the verifier is the thing that separates a loop that ships working software from a loop that produces a confident, well-tested, completely wrong result and then closes the ticket. You can teach the whole syllabus of loop engineering and produce engineers who build flawless theaters.

A third objection is more serious and worth meeting head on: if oracles are also gameable, by Goodhart, then the oracle is no more solid a foundation than the loop, and the whole argument collapses into "everything is hard." It does not, for a reason worth stating precisely. Oracles are gameable, but they are gameable at a different and slower level, and the gap is everything. A loop with no oracle fails instantly and invisibly; it certifies its own output the moment it runs. A loop with a weak oracle fails slowly, as the optimizer learns the proxy. A loop with a strong, independent, externally anchored, periodically rotated oracle fails slowest of all, and buys you the time and the signal to notice and respond. The point was never that oracles are perfect. It is that the oracle is the only component whose quality you can actually invest in to push failure further away, while every dollar spent polishing the loop pushes failure nowhere, because the loop was never the thing failing. You cannot solve the oracle problem. You can only be honest about which side of it you are on, and spend accordingly.

What to build, and what to watch

If the oracle is the hard part, the practical consequences follow directly, and they are not the consequences the loop directories optimize for.

Build the oracle first, and treat the loop as the afterthought it is. Before you write a single line of harness, answer the question the loop cannot answer for itself: what is the cheap, hard-to-game, externally checkable signal that this work is done and good. If you have one, as you do for code with a real test suite, looping will feel like leverage, and you should reach for it aggressively, because the productivity is real and the people who refuse to loop checkable work out of caution will simply lose to the people who do. If you do not have one, as you do not for most knowledge work whose quality is a matter of judgment, then building the loop first is building a faster way to be wrong, and the responsible move is to invest in the oracle, in evaluation data, in rubrics, in anchoring your judge to something external, before you invest in autonomy. The separate-grader design in /goal, the evaluator forbidden from reading files so it can only judge surfaced evidence, is the pattern to copy, not because it is clever but because it is the minimum viable defense against a loop grading itself into a hallucination.

Spend on verification as if it were the product, because it is becoming the product. The defensible asset in an age of converging models is not access to a frontier model, which everyone will have, but a proprietary oracle: a body of evaluation data and a verifier that reliably distinguishes good from good-looking in a domain that matters. This is the same conclusion the Map reached as Model Convergence Pressure and the Verification Renaissance , that the gains are migrating from the model to the rubric, and loop engineering is the consumer-facing proof of it. The teams that win will not be the teams with the cleverest loops, because the loops are forty lines on a public website that anyone can copy. They will be the teams that own the oracle no one else can copy, and they will mostly own it because they did the unglamorous work of building it while everyone else was sharing loops.

Price the loop like the financial instrument it is. An unattended loop with accumulating context is a position that costs money every iteration, and a loop with a weak exit condition is a position with no stop-loss, which DeFi will tell you is how you get liquidated and which the AI capital markets are demonstrating at the scale of nations. The runtime layer is already moving this way, toward checkpointing, durable state, and cost meters, which I tracked as Orchestration to Runtime; what is missing is the organizational discipline on top, a FinOps for agents that tags every loop run with what it cost and what it was worth, that runs the cheap grader on a small model and reserves the frontier model for the work that needs it, that sets per-loop budgets and kills the loops that spend all night polishing the wrong thing. This is the same logic the bearer-token piece applied to identity, that insurers, not regulators, would discipline agent behavior by pricing the downside, extended to cost: the people writing the checks for the tokens will eventually demand to know which loops earned their spend, and the loops that cannot produce that accounting will be the first ones turned off.

And watch the inversion that is coming, because it is the clearest prediction this frame makes. Today the artifact people share is the loop. The loops.elorm.xyz directory ships loops; the awesome-lists collect loops; the bragging rights are in the loop. Within a cycle or two the scarce, traded, audited artifact will not be the loop but the oracle: verified evaluation suites, certified rubrics, third-party verifiers you can trust because someone independent attested to them, the way you trust a security audit or a financial statement. A marketplace for audited loops is a marketplace for steering wheels, and steering wheels are not scarce. A marketplace for audited oracles is a marketplace for knowing where you are going, and that is the one worth building, because it is the one that is actually hard. When that marketplace exists, "stop prompting, start looping" will read the way "the future is fire" reads now: true, ancient, and beside the point.

The loop was never the hard part. Anyone can write a while. The question that decides everything is the one the loop cannot ask about itself, whether the thing it just produced is real, and whoever owns that answer in a domain that matters owns the domain. Build the oracle. The loop is just the noise it makes while it works.