For about two years the deal with a coding agent was simple, and if you have shipped anything with one you know the rhythm in your hands. You wrote a prompt. You read what came back. You wrote the next prompt. You were holding the tool the entire time, one turn after another, and the quality of the output was mostly the quality of your typing. That was prompt engineering, and a whole cottage industry of LinkedIn carousels grew up to teach you how to phrase the thing you typed. It worked. I built real systems that way, including a PCI-scoped autonomous payment agent on .NET 10 that I would not have attempted by hand in the time I had.
In June 2026 a few people who would know started saying that part is over. Peter Steinberger, the Austrian who built OpenClaw and then left Europe for OpenAI, put it as bluntly as anyone: you should be designing loops that prompt your agents. Boris Cherny, who runs Claude Code at Anthropic, said the same thing from the inside, that he does not prompt the model anymore, he has loops that prompt it and figure out what to do, and his job is now to write loops. Addy Osmani, a Google engineer who has been narrating this transition in long, careful blog posts, gave the pattern a name and a shape. The name is loop engineering. I am skeptical by trade and I am going to stay skeptical here, but the people saying this are not bloggers chasing a keyword. They are the people who build the agents. When the head of Claude Code tells you his job changed, that is a primary source.
So let me do what I always do. Take the claim apart, see what is actually load-bearing, separate the part that ships from the part that sells a consulting retainer, and then point at the bill. Because there is always a bill, and in this particular revolution the bill is the most interesting character in the story.
What loop engineering actually is
Strip the romance off it and a loop is a recursive goal. You define a purpose once, and a system iterates against that purpose until the work is genuinely done, deciding for itself what to do next between turns instead of waiting for you to type the next instruction. That is the whole idea. The reason it feels new is that for two years you were the recursion. You were the thing in the loop reading the output and deciding what to ask for next. Loop engineering removes you from that seat and puts a small piece of software there instead.
The mental model that finally made it click for me is that there were always two loops, and we only ever talked about one. Every agent already runs an inner loop on every single turn. It reasons about what to do, it calls a tool or edits a file or runs a test, it observes the result, and it loops back to reason against the new state. Perceive, reason, act, observe. That inner loop is the thing that makes an agent an agent instead of a glorified autocomplete. What is new is the outer loop. The outer loop runs on a schedule, spawns helpers, feeds itself work, and keeps the inner loop turning across hundreds of cycles without you in the chair for any of them. Loop engineering is the craft of building that outer loop. It sits one floor above the harness that a single agent runs inside, and the harness sits one floor above the model. Three floors, and the elevator of attention just moved up another one.
The honest one-sentence version, the one I would say to a CTO who has thirty seconds in a hallway: you stop optimizing the prompt and start optimizing the system that generates and grades the prompts. The leverage point moved. Cherny was careful about this and I want to be careful too, because it is the single most misread part of the whole conversation. He did not say the work got easier. He said the highest-value thing you can do is no longer writing a prompt. A well-designed loop multiplies a good engineer. A badly designed loop multiplies a bad decision at machine speed with nobody watching. Same machine, opposite outcome, and the machine cannot tell which one it is running.
The five pieces, plus the one that actually holds it together
Osmani lays out five building blocks and then a sixth thing that everyone forgets is a thing. I am going to walk through them in prose because anyone who has read me knows I do not do bullet lists, and also because the relationships between these pieces matter more than the pieces themselves. A list would hide that.
The first piece is automations, and this is the heartbeat. Without it you do not have a loop, you have one run you did once and felt clever about. An automation is a recurring trigger that goes off on a schedule and does discovery and triage by itself. In the Codex app there is a literal Automations tab where you pick a project, a prompt, a cadence, and whether it runs against your local checkout or a background worktree. Runs that find something land in a triage inbox. Runs that find nothing archive themselves quietly, which is the kind of small mercy that tells you the people who built it have actually lived with the thing. OpenAI uses these internally for the boring work, daily issue triage, summarizing CI failures, writing commit briefings, hunting the bug somebody slipped in last Tuesday. Claude Code gets to the same place through a /loop command that turns your cadence into a cron job, plus lifecycle hooks that fire shell commands at defined points, plus the option to push the whole thing into GitHub Actions so it keeps running after your laptop is closed and you are at jiu-jitsu. The shape is identical across both tools, which is the recurring theme of this entire topic and the reason it is worth learning once.
There is a second, sharper primitive hiding inside the automation layer, and it is the one this whole movement is really about. Both Codex and Claude Code now ship a /goal command. You give it a verifiable stopping condition, something like every test in the auth suite passes and the linter is clean, and it keeps working across turns until that condition is actually true. The detail that matters, the one I keep pointing at when people get starry-eyed, is that after every turn a separate, smaller model checks whether the goal is met. The agent that wrote the code is not the agent that decides the code is done. Hold that thought, because it is the entire game and I am coming back to it.
The second piece is worktrees, and this is the unglamorous plumbing that decides whether your parallelism is leverage or chaos. The second you run more than one agent, the files start colliding, and two agents editing the same file is precisely as bad as two engineers committing to the same lines without talking first. A git worktree is a separate working directory on its own branch that shares the same repository history, so one agent’s edits literally cannot touch another agent’s checkout. Codex builds this in so several threads hit the same repo without bumping into each other. Claude Code gives you the same isolation through git worktree, a worktree flag, and an isolation setting you stick on a sub-agent so each helper gets a fresh checkout that cleans itself up afterward. Here is the part the slide decks leave out: the worktree removes the mechanical collision, but it does not remove you. Your bandwidth to read and approve what got merged is the real ceiling, not the number of checkouts the tool will spin up. Ten agents producing diffs you cannot review is strictly worse than two you can. I have watched a team learn this the expensive way.
The third piece is skills, and this is how you stop re-explaining your own project every session like you are talking to a goldfish with a build pipeline. A skill is a folder with a markdown file inside holding instructions and metadata, plus optional scripts and references. Both tools use the same format. You invoke a skill by name or it fires on its own when a task matches its description, which is exactly why a boring, precise description beats a clever one. The deeper point is about intent. An agent starts every session cold and will fill any gap in your intent with a confident guess, and a confident wrong guess is the most expensive output in this entire field. A skill is your intent written down on the outside, the conventions, the build steps, the we-do-not-do-it-that-way-because-of-that-one-incident-in-2024. Without skills, the loop re-derives your entire project from zero every cycle and pays full token price to rediscover what you already knew. With skills, knowledge compounds. I have been writing these for my own stack, the MCP server conventions, the Microsoft Agent Framework deployment patterns, the SQL Server 2025 vector search quirks, and the difference in output quality is not subtle.
The fourth piece is plugins and connectors, and this is where a loop stops being a clever toy that can only see the filesystem and becomes something that touches your actual business. Connectors are built on the Model Context Protocol, MCP, and they let the agent read your issue tracker, query a database, hit a staging API, or drop a message in a channel. Codex and Claude Code both speak MCP, so a connector you wrote for one usually just works in the other, which is a genuinely big deal and not something the industry usually grants you for free. This is the difference between an agent that says here is the fix and a loop that opens the pull request, links the ticket, and pings the channel the moment CI goes green, entirely on its own. I build and operate MCP servers, including one in production that fronts a personals listings catalog, so I will say the quiet part plainly: the connector is also the blast radius. A loop with connector access and a bad afternoon can do things to your real systems that a chat window never could. We will get there.
The fifth piece is sub-agents, and if you make me rank these, this is the one that earns its keep. The single most useful structural move in a loop is splitting the agent that writes from the agent that checks. The model that wrote the code is far too generous grading its own homework, the same way I am far too generous about my own pull requests at eleven at night. A second agent, with different instructions and ideally a different and stronger model, catches the things the first one talked itself into. In Codex you define sub-agents as small configuration files, each with a name, a description, instructions, and an optional model and reasoning effort, so your security reviewer can be a strong model running on high effort while your explorer is something fast and read-only. Claude Code does the same with sub-agents and with agent teams that hand work between them. The usual split, in both, is one agent explores, one implements, one verifies against the spec. And notice that the /goal stopping condition I told you to remember is just this same maker-checker split applied to the question of whether you are finished. A fresh model decides done, not the one that did the work. The whole architecture is one idea wearing several hats: never let the thing that made the claim be the thing that grades the claim.
Then the sixth thing, the one nobody puts on the architecture diagram because it looks too dumb to matter: memory. Not the model’s context window, which is amnesia with a fixed token budget, but state that lives on disk outside any single conversation. A markdown file, a Linear board, a list of GitHub issues. It holds what got tried, what passed, what is still open. The model forgets everything between runs, completely, every time. The repository does not. Tomorrow morning’s run reads the state file and picks up exactly where today’s run stopped, and that single boring file is the spine that turns a pile of disconnected runs into something that behaves like a colleague who remembers the project. Skills hold the durable knowledge, how we build and what our conventions are. Memory holds the changing state, what is done and what is next. Lose the distinction and your loop either forgets the project or forgets the progress, and both failures look like the agent suddenly got stupid overnight.
Put it together and a single thread becomes a small control panel. An automation runs every weekday morning. Its prompt calls a triage skill that reads yesterday’s CI failures, the open issues, and the recent commits, and writes findings into a memory file. For each finding worth doing, the thread opens an isolated worktree and sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project skills and the existing tests. Connectors open the pull request and update the ticket. Anything the loop cannot handle lands in the inbox for me. Look at what I actually did there. I designed it once. I did not prompt a single one of those steps. That is the whole pitch, and it is the same loop whether it runs in Codex or in Claude Code, because the pieces are the same pieces. That tool-agnostic convergence is, to me, the most underrated fact in the entire discussion. We spent two years arguing about which agent is best and the agents quietly agreed on the same architecture behind our backs.
The part that is genuinely magnificent when someone else is paying for the tokens
Now for my favorite section, the one I could not write with a straight face if I tried. Loop engineering is, without exaggeration, the most fun you can have in software right now, and it is roughly ten times more fun when the tokens are billed to a cost center that is not yours. Let me make the case for the defense before I read the charges, because the case is real.
A loop running unattended overnight is a beautiful thing. You design it, you go to bed, and you wake up to a triage inbox full of drafted fixes, a couple of green pull requests, and a memory file that reads like a diligent junior engineer worked the whole night without once checking LinkedIn. The marginal cost of your ambition has collapsed. Want to try three different refactors of the same module in parallel? Spin up three worktrees and three sub-agents and let them race. Want a verifier on every change, a second strong model second-guessing the first on every single turn? Done, it is a config line. In the prompt era every one of those moves cost you your own time and attention, the only genuinely scarce resources you have. In the loop era they cost tokens. And tokens, gloriously, are someone else’s problem, right up until the precise moment that they are very much somebody’s problem and that somebody is holding an invoice and looking for a name.
Here is where the comedy turns into a TechCrunch headline. The economics of this are, at the enterprise level, completely unhinged right now, and I mean that as a description and not a slur. Per-token prices have fallen off a cliff, somewhere between sixty-seven percent year over year on a blended basis and as much as ninety-eight percent over a longer window depending on whose analysis you read. That should mean AI got cheaper. It did the opposite. Enterprise AI bills tripled, because the thing loop engineering does for a living is consume tokens at a scale a human typing into a chat box never could. Jellyfish put a number on it that I have not been able to stop thinking about: per-developer token consumption rose roughly eighteen-and-a-half times in nine months. Eighteen-and-a-half. The price per unit fell and the bill exploded anyway, which is the kind of result that ends careers in finance departments and starts entire new ones.
The anecdotes are better than the aggregates. Uber burned through its entire 2026 AI coding budget by April, and its CTO, Praveen Neppalli Naga, said the company was back to the drawing board, which is a remarkable sentence to hear from a company that spent three-and-a-half billion dollars on R&D last year. Uber’s own COO, Andrew Macdonald, admitted on a podcast that the link between all that spend and actual shipped value is, in his words, not there yet, while the CEO told the earnings call that autonomous agents wrote roughly ten percent of committed code. Microsoft handed its developers Claude Code licenses and then revoked them months later. A Priceline employee told TechCrunch that a routine Cursor renewal came back four to five times more expensive, and a Priceline finance director compared the whole all-you-can-eat-then-the-meter-runs business model to getting someone hooked on a substance and then sending the bill. And the line that should be printed on a mug in every engineering org in America: one company reportedly ran up a five-hundred-million-dollar Claude bill in a single month after forgetting to set usage limits for its employees. Five hundred million. Because nobody capped the loop.
EY framed the per-interaction version of this for the CFOs in the room. A simple linear workflow in 2023, input then retrieval then a response, cost about four cents per interaction. The 2026 version, the orchestrated kind with tools and reasoning and iterative loops, runs around a dollar twenty per interaction, roughly thirty times more. Multiply thirty-times-per-interaction by eighteen-times-the-interactions and you understand why JPMorgan published a note with the cheerful title that AI token costs are eating internet profits alive, and why one real engineer reportedly spent forty thousand dollars on tokens in thirty days and his managers genuinely could not decide whether to fire him, promote him, or clone him. The honest answer is probably clone him, but only after you cap the loop.
This is not going unanswered. The share of finance professionals responsible for managing AI spend went from about a third to nearly all of them inside twelve months. The Linux Foundation is standing up a Tokenomics Foundation, launching in July, to do for AI token spend what FinOps did for cloud, which is to say invent the discipline of not being shocked by your own invoice. Datadog, New Relic, Ramp, and a flock of startups with names like Pay-i are racing to instrument the meter. So the punchline, the one I promised, holds up under scrutiny: loop engineering is spectacular, transformative, the most leverage I have felt in thirty years on this stack, and it is approximately at its most spectacular when the meter is pointed at a balance sheet that does not have your name on the bottom line. Build the loop. Set the cap first. And if you are a consultant, and I am, design the loop, bill the design, and let the client own the meter. I did not invent this game. I just read the rules carefully.
Where loops actually run, once you stop staring at the IDE
Everyone writes about loop engineering as a coding-agent story, because the people who coined it write code and the tools that ship the primitives are coding tools. That framing is a failure of imagination, and it is the part I most want to push on, because the loop is not a coding pattern. The loop is an operating pattern. Discover work, hand it out, check it, remember what you did, decide the next thing. That description does not contain the word code anywhere. It describes half the jobs in your company. So let me take the loop out of the IDE and walk it through some buildings where I have either worked or watched it land.
Start with money, because money is where unattended loops are simultaneously most valuable and most terrifying. Financial institutions already run what amount to loops to flag and halt suspicious transactions in milliseconds, manage portfolios against predefined risk policies, reconcile invoices, and run know-your-customer verification. The loop shape fits fraud detection almost perfectly: an automation watches the transaction stream continuously, a maker agent flags anomalies, a checker agent confirms or clears them against policy before anything is frozen, and a memory of confirmed patterns makes tomorrow’s pass smarter. The maker-checker split is not a clever AI trick here. It is literally the control structure that banking compliance has demanded for a century, which is why finance is going to adopt this faster and more carefully than software ever did. The newest and most vertiginous version showed up this month, when MetaMask published an agent wallet that lets autonomous agents execute on-chain trades across blockchains and decentralized finance under a mandatory guard mode, with spending limits, allowlists, transaction simulation, and two-factor approval on the risky edges. Read that sentence again. We are wiring loops directly to treasuries. The guardrails are the only thing standing between leverage and a very public, very irreversible loss, and on-chain there is no chargeback and no support ticket. That guard mode is the worktree-and-verifier idea reincarnated as the difference between a fund and a smoking crater.
Move to security operations, which to me is the cleanest non-coding fit of all. The agentic security operations center is already a named thing, and it does exactly what a loop does. Instead of a human analyst drowning in alerts and flagging them one at a time, a system of agents investigates the alert, analyzes the malware, correlates it against what it has seen, and recommends or stages a response in real time, while the human gets promoted from tactical responder to strategic defender. This is the loop with the stakes turned up, because the verifier is not checking whether the tests pass, it is checking whether you are about to isolate a production subnet at two in the morning on the strength of one agent’s hunch. The discipline I described for code, never let the maker grade itself, is not optional in a SOC. It is the difference between catching a breach and causing an outage. My own open-source diagnostic work, the PLogger pipeline that bridges production telemetry to dev-time agents, lives right on this seam, and I will tell you from experience that the hard part was never getting the agent to find the problem. The hard part is the gate that decides whether to act on what it found.
Then there is the long, less dramatic tail where loops are quietly going to eat the most actual labor. Supply chain and logistics, where agents predict demand spikes, re-route shipping fleets against weather and traffic, allocate warehouse inventory, and run procurement reorder cycles, all of it a continuous discover-act-verify loop against a memory of what the network looked like yesterday. Sales, where the learning-agent flavor qualifies leads, books meetings, and runs follow-up across the CRM and the calendar, behaving less like a script and more like a junior rep who never sleeps and never gets discouraged by a no. Healthcare administration, the unglamorous mountain of it, where agents maintain context across patient records and grind down the paperwork burden that is burning out everyone in the building, while a human keeps every clinical decision firmly on their side of the gate. Marketing and SEO, where a loop can run content production, keyword work, and performance triage on a cadence, which I have direct opinions about because I run a portfolio of web properties and the temptation to point a loop at all of them and walk away is real, and so is the way it can quietly fill your sites with confident, well-optimized, slightly-wrong nonsense if you remove the human read. And robotics, where NVIDIA’s newest tooling lets fleets turn streaming telemetry into test scenarios and patch controllers, which is the loop reaching out of the datacenter and into the physical world, where the cost of a bad unattended decision is no longer a reverted commit.
The pattern under all of these is the same, and it is worth saying once cleanly. Anywhere there is recurring work that can be discovered automatically, attempted by one agent, verified by a different agent against a real condition, and remembered between runs, the loop fits. The fit is not about the domain. It is about whether you can write down what done actually means and whether you can stomach the cost of being wrong while you were not watching. Software was just the first building the loop walked into, because programmers build their own tools and we always experiment on ourselves first.
Can we loop the loops? On the automation of the automators
Here is where I am supposed to be the sober practitioner, and I will be, in a minute. But let me first follow the thought all the way down the staircase, because it is irresistible and because the people building the agents are already standing at the bottom of it waving.
If my job is now to write loops instead of prompts, then writing loops is just another kind of recurring, discoverable, verifiable work. Which means, by the logic of the entire article you have just read, it is itself a candidate for a loop. A loop that designs loops. An automation whose triage step is not yesterday’s CI failures but yesterday’s loops, reading which of my outer loops underperformed, drafting better ones, spinning up a verifier loop to grade the new loops against the old ones, and merging the winners. We just moved up another floor. There is always another floor. And once you have a loop that improves loops, the obvious next question is whether the thing being improved can include the improver, and at that point you have stopped describing a workflow and started describing recursive self-improvement, which until about a year ago was a phrase you only heard from people with strong opinions about the year 2045.
Except it is not a thought experiment anymore, and the source making it concrete is the same company whose tool I have been describing. Anthropic published an essay this month, plainly titled around the idea of AI building itself, in which they report that in April their own model shipped over eight hundred fixes that reduced a class of API errors by a factor of a thousand, and that the engineer overseeing it estimated a human would have needed four years for the same work. Four years, compressed, by a system improving the system. Their framing of the trajectory is almost a taunt: humans writing code, then agents writing whole files, then agents handing hours of work to other agents, ending at a system that could, given enough compute, autonomously design and develop its own successor. Jack Clark, one of their founders, has been going to lawmakers specifically to get the phrase recursive self-improvement into the room before they hear it screamed on cable news. OpenAI has said it wants intern-level AI research agents by this September and fully functional ones by 2028. Sakana stood up an entire lab whose stated loop is an AI scientist that builds better agent models that build a better AI scientist. There is an academic workshop now where the spine of the agenda is loops that update their own weights, rewrite their own prompts, and patch their own controllers, and the organizers’ polite phrasing is that they want to govern these loops without hand-waving. The hand-waving, I would gently note, is doing a great deal of work in that sentence.
So can we loop the loops and eventually take the humans out entirely? Mechanically, in narrow and well-fenced domains, we already partly have, and the fences are the only reason it has not gone sideways in public. But here is the catch that every serious version of this story arrives at, including Anthropic’s own, and it is the catch that brings me back to the ground. Execution got cheap. Judgment did not. When agents hand hours of work to other agents, the bottleneck does not disappear, it migrates, and it migrates to the one place no loop can fully occupy: the decision about whether the output is actually good and actually what we wanted. The loop generates. Something still has to be the bouncer at the door. If a large fraction of what the loop produces is junk, and at the frontier it often is, then your entire remaining edge is the speed and the quality of your no. Loop engineering, taken to its recursive limit, does not eliminate the human. It refines the human’s job down to a single irreducible function: saying no, correctly, fast, to a machine that is very confident and occasionally, expensively wrong.
The honest part, which is also the part that keeps me employed
Three problems get worse, not better, as the loop gets good, and they are the reason I am not selling my judgment to a cron job just yet. The first is verification. A loop running unattended is also a loop making mistakes unattended, and the verifier sub-agent, as much as I love it, produces a claim of done, not a proof of done. Your actual job, the one that does not go away, is to ship code, or trades, or responses, that you confirmed work. The second is comprehension debt, and it compounds exactly like financial debt, which is to say invisibly until it doesn’t. The faster the loop ships things you did not write, the wider the gap between what exists in your system and what you actually understand about it, and a smooth, fast loop just widens that gap faster unless you make yourself read what it produced. The third is the quiet one, the one Osmani calls cognitive surrender and I would call the comfortable death of having an opinion. When the loop runs itself, it is so easy, so pleasant, to stop forming a view and just accept whatever comes back. Designing the loop with judgment is the cure. Designing the loop to avoid thinking is the disease. The action is identical. The outcome is opposite. And the loop, as I keep saying, cannot tell the difference. You can. That difference is the entire value of the engineer in the age of the loop, and it is not automatable, because the moment you automate it you have simply moved it up a floor to whoever decides whether to trust the automation.
Two people will build the exact same loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid ever understanding the work at all. Same five blocks, same memory file, same maker-checker split, same green pull requests in the morning. One of them is getting more powerful every week. The other is getting more dependent every week, and the bill is identical. So build the loop. Build it like someone who fully intends to remain the engineer, not someone auditioning to become the person who presses go and looks away.
And now I am going to take a nap
Here is what I am actually going to do, having written all of that. I have a morning automation that will fire on the repo while I sleep. It will read yesterday’s failures, draft the obvious fixes in isolated worktrees, send a strong-model reviewer to argue with each draft, open the pull requests that survive, update the tickets, and drop everything it could not handle into my inbox with a note. The verifier will second-guess the maker on every turn. The memory file will remember what it tried so it does not chase the same ghost twice. The cap is set, because I read my own article. And the tokens, for this particular run, are not coming out of my pocket, which I will admit improved my sleep quality before I even lay down.
So I am going to close the laptop and trust the loops. The agents will discover the work and hand it to other agents and grade each other’s homework and write it all down, and I am going to lie down on the couch with my dog and let the outer loop turn without me in the chair for the first time in thirty years of doing this by hand. The maker will make. The checker will check. The world, I am fairly sure, is going to be okay.
I hope.
About he Author
Gal Ratner is Chief Architect at Prana Entertainment and the founder of Inverted Software and WhiteStar Labs. He writes about AI, software architecture, and the economics of platform decline at galratner.com.