Loop engineering: what the new way of working with AI agents is worth — and when a good prompt is enough
I begin unusually, with two quotes. Boris Cherny, the creator of Claude Code, says: “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.” Addy Osmani, engineering lead at Google Chrome, defines the technique along with it: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”
Right now literally every corner of the AI scene writes about loop engineering: technique descriptions, field reports, advice, criticism. Against this backdrop arises the feeling that prompt engineering has died and whoever still prompts by hand today must urgently relearn to start cycles.
Is that true? Yes and no. Loop engineering is a very effective way of working that replaces neither prompting nor the setup of AI agents. It sets a layer on top — and you need it only in situations where a loop really contributes something. The hardest part is not starting a loop. The hardest part is getting a usable result out of it. How that works, which loop types exist as of July 2026 and why they fail in practice, I show in this piece, including a checklist for your first own loop.
Where the idea comes from: a thermostat from the year 1620
The Dutchman Cornelis Drebbel built, around 1620, an incubator for hen’s eggs that held the temperature itself. The construction: if the mercury above the fire warms, it expands and pushes a damper in the flue shut. If the temperature falls, the mercury contracts, the damper opens. Drebbel’s oven counts as one of the first documented systems with feedback: it performs an action, measures the result and derives the next action from it.
This pattern has many descendants. Deming cast it into quality theory as “Plan, Do, Check, Act.” And in July 2025 the Australian software developer Geoffrey Huntley gave it a name from “The Simpsons”: Ralph Wiggum, the character who does not shine through cleverness but never gives up. Huntley’s Ralph technique consists, in pure form, of a single Bash line:
while :; do cat PROMPT.md | claude-code ; doneA coding agent gets served the same prompt until the result holds. At the start of the technique this was necessary, because the models still worked unreliably at programming. Within a year, the Bash loop became real product features: the /goal function in Codex describes a target state along with a check criterion, Claude Code followed with /goal, /loop and /schedule, plus starts by schedule and by event: “Check open pull requests every five minutes, reply to reviews, fix broken tests.”
If you write no code: stay with it anyway. In code, loops matured first only because tests and compilers deliver an honest signal in seconds. That is no accident but a system. Andrej Karpathy explains in his Sequoia conversation “From Vibe Coding to Agentic Engineering” (April 2026) why models get better fastest in mathematics and programming of all things: the labs train them via reinforcement learning in environments where the result can be verified automatically. Where a checkable signal exists, the ability grows; loops use the same lever in application. A cheap, honest measurement is the core condition under which a loop makes sense at all — and such measurements exist far beyond code: do the sums in the table add up? Does the link open? Does the date lie in the right window? Does every claim have a source? Even in writing tasks loops can be used. How, I come to that yet.
Are prompts done with, then?
By no means, and there both Cherny and Osmani exaggerate a little. To start a loop, you write the agent a prompt. Inside the loop the model then prompts itself, and there are still enough situations today in which a loop is simply superfluous. OpenAI itself positions /goal as a tool for long, multi-step tasks; for the single task, an ordinary, cleanly phrased prompt suffices in most cases.
I now sort the layers for myself under the working term “model management,” without claiming universality: as a manager leads people and resources, a person working with AI leads several instances at once. Prompting remains the basic skill of putting requests precisely: goal, desired result, format, boundaries, necessary checks. Context engineering ensures the model has all the information necessary for the task; where the tokens go in the process I have shown elsewhere. The agent shell determines which tools the model works with — how such an agent is built from the inside was a topic here already. Loop engineering steers, as the fourth layer, the cycle: when to start, what to check, what to remember, when to stop.
The better the models get, the more of these layers stand ready. By no means all are needed in every case.
Which loop types exist?
The term is young, the systematization is still running. The most usable classification comes from the piece “Getting started with loops” by the Claude Code team of 30 June 2026. The definition there is pleasantly plain: a loop is an agent that repeats work runs until a stop criterion takes hold.
no check — only the hope that it worked
From there the field sorts by trigger. Turn-based loops are the surprise of the list: your normal dialogue with a model is already a loop. You set a task, read the answer, refine, the model tries again — and the stop criterion is you yourself with your “good, that works.” As soon as you turn this cycle deliberately, for instance ask the model to rate its own answer by named criteria and improve it, you already do half loop engineering. Goal loops are the classic /goal: the stop criterion is a checkable goal or an attempt limit, “get the rating above 90 points, at most five tries.” Time loops run by schedule, /loop and /schedule. Proactive loops start on an event, entirely without humans: a test fails, the agent repairs. A bug report comes in, the agent investigates and files a ticket. A dependency gets a new version, the agent updates and runs the checks.
From my practice an example for time loops: my agent Hermes sends me two compilations to Telegram every day. The first, with stock data, is the borderline case — a pure alarm clock with a fixed format that has not changed in a long time, and still a loop: it starts daily, delivers and lets me intervene when something jams. The second, a news selection, is built more finely: I read the collection, tell the agent what worked and what is missing, and it works the feedback into its search and writing skills. The next day the selection is noticeably different. Hand-built cycles I needed none for this; Hermes brings the skill improvement after user comments out of the box.
Two principles from the Claude Code piece I would frame. First: when a run misses the goal, do not correct the individual case — you write the lesson from it into the system, so it holds for all future starts. Exactly that happens when Hermes adjusts its skill after my comment: I edit one compilation, the improvement lives in all following ones. Second, the money: set explicit stop criteria, take scripts instead of model reasoning where the work is deterministic (why should a model “think about” a date check that one line of code handles?), and couple the start interval to the real frequency of change. A loop that checks something every five minutes that changes once a day simply burns tokens.
What do the practitioners report?
The classification is the theory. How loops are actually used, Gergely Orosz, author of the newsletter The Pragmatic Engineer, compiled on 14 July 2026 in a large analysis “What is loop engineering?”, based on around 210 answers from developers.
The picture is revealing. In real work two of the four types dominate: loops by event and loops by schedule. The typical production cases sound like the dream of a tired team lead: automatic pull requests for every error in the log, the repair of “flaky” tests, a nightly watchdog routine, incident investigations on fresh traces, long migrations an agent pulls over weeks.
More interesting than the successes are the complaints. Three disappointments run through the answers. The first: agents drift on long runs — my own case on that in a moment. The second: the costs. Loops eat tokens with impressive appetite, because every iteration is a full agent run, and iterations there are, by definition, many. The third is the most revealing: many practitioners report that a human in the loop delivers better results than full autonomy. Not because the model were dumb. But because the human is the cheapest sensor for exactly the things that cannot be checked mechanically. Karpathy calls the property behind it “jagged intelligence”: the same model that refactors a codebase of 100,000 lines or finds a zero-day gap suggests, in everyday life, walking the 50 meters to the car wash. A loop inherits these jags and does not notice them itself — the human at the edge of the cycle does.
On this observation I build the rest of the piece: what does a loop look like that checks honestly, brakes in time and puts the human at the right spot?
Where do loops really fail?
The uncomfortable answer: at the human. More precisely at their convenience, because starting a loop and handing responsibility to it is easy. Designing a good check is work.
A case from the last weeks. I am trying to build up a Threads account on the topic of AI news; the content is created by the same Hermes (under the hood ran GPT-5.5, meanwhile GPT-5.6). The starting plan seemed as solid as clockwork. For about a week I ran the account by hand, then handed it to Hermes: every morning analyze the channel, gather fresh news hooks on the AI topic, prepare ten draft threads. From these drafts I selected, edited, published across the day. The next morning Hermes parsed the channel, compared which drafts I had taken and how I had changed them, improved its search and writing skills — and the next run started on an improved footing.
The first days it went well, the agent reliably delivered fresh drafts. Then something caught my eye. The threads consisted strictly of three posts. The openings followed two or three ever-same patterns. And the topics slid ever further toward “AI in science” with a small rest of product news. What had happened?
Hermes, as the checker in the loop, had not seen my taste, because it cannot see it. It saw its shadow: the length of the chosen threads, recurring opening patterns, a science topic that ran well for a few days. These measures it optimized, conscientiously and ever further. That is Goodhart’s law in action: as soon as a measure becomes the goal, it no longer works as a measure.
Fine, the AI checker drifts. But is that really only my isolated case?
Is an AI fit to be the checker in its own loop?
Back to Drebbel, briefly. His controller worked for a single, simple reason: mercury cannot pass off wishes for reality. It expands exactly as far as the oven is hot, and it is indifferent to what the heater above “thinks.” In AI loops the role of this thermometer is often taken by a second AI — and exactly here begin the problems that can be captured in numbers.
This July a study appeared on this with the telling title “More Convincing, Not More Correct” by Chenyu Zhou. The setup: one model solves math problems from the GSM8K dataset, a second rates the solutions as a judge, without access to the correct answer. Then the solving model is trained to win the judge’s approval, while the author quietly checks every answer against a hidden gold standard the judge never sees. The result: the judge’s approval rose from 72 to 94 percent — from the outside it looks as if the system were getting rapidly smarter. The actual correctness stayed at around 20 percent. The solver did not learn to solve better. It learned to look more convincing. A panel of three judges helped little either: the ensemble waved through around 55 percent of the wrong answers, and the deceptions worked across judges from different model families, from Qwen through Llama to Gemma.
My Threads story is the everyday version of the same mechanism. Hermes did not write more interestingly, it wrote closer to what the checker in the loop would approve. A judge without access to reality rates plausibility, and plausibility is trainable.
Sounds like a death sentence for loops? It is not. The same study also shows the bolt: if the judge solves the task itself first and then compares the candidate against its own, recorded solution, the share of wrongly waved-through answers falls from 71.9 to 1.2 percent. The more general message behind it: the self-check begins to work as soon as information flows into the cycle from outside. A code run, a source search, a database query, a recomputed sum, a human edit — something that does not come from the model itself. From this follows the rule I would hang over every complex loop: every iteration must get information it did not have in the previous one. “Read it again and improve it” is no information.
How does a loop stay fresh? Separate exploration and exploitation
For my Threads experiment the simplest way out was to write the editorial analysis myself again: which drafts were weak and why, which topics were missing, which experiments would be worthwhile. Only, daily hand-work contradicts the purpose of the whole setup, maximum automation. So I proceeded differently: feedback I give as text once a week, and for the everyday I brought a principle into the loop that has long been known in management — the dilemma of exploration and exploitation.
Hermes had optimized magnificently toward exploitation: it took the signals from the channel and exploited them. The exploration, which I had never commissioned, it consequently left out. Now the process is rebuilt. Hermes still delivers ten drafts every morning, but with a different split: six arise from the channel analysis, four are experiments — new topics from its own knowledge, a different make (structure, number of posts, openings) and entirely new formats like short posts, images or questions to readers. Once a week the agent gets my text feedback on both.
Honestly: the experiments too begin to resemble one another after a while. I reckon I will lower their number and let the jumps grow larger instead; for solid feedback, two or three experimental posts a week suffice in experience, after which they influence the main stream by themselves. The nice punchline: hand-built cycles were never necessary. The skill improvement after comments Hermes brings along, I only set the split of the drafts and the feedback rhythm.
Do you even need a loop?
Let us begin with the question that saves the most money. As a filter I phrase it like this: what exactly does the system learn after the next run — and how does that change the one after? If you have no answer to that, you need no loop. Then a good prompt suffices, and it is many times cheaper. If there is an answer, two quantities decide the cut: the price of the check and the price of an error. The typical situations I have laid into a table:
| Situation | Role of the loop |
|---|---|
| An honest machine check exists (code with tests, data with reconciliation) | High autonomy possible |
| Rules plus subjective judgment (editing, analytics, office tasks) | Loop prepares and filters, the human decides |
| Taste or strategy decide almost everything | Short iterations with frequent human reaction |
| No new information arrives between the runs | No loop — a single prompt suffices |
| Errors are irreversible or expensive (publication, payment, deletion) | Mandatory human confirmation before the action |
Read the table as a spectrum, not as two camps “suitable / unsuitable.” My Threads loop lives in the second and third row at once: the mechanics (freshness of the hooks, duplicates, structure) the loop checks, the taste stays with me.
Before you build a loop, answer seven questions. They form the loop’s passport and at the same time the briefing for the agent that is to implement it:
- Goal – to what result does the loop lead? Not “improve until it is good,” but “meets these conditions.” The goal may end open, for instance a Threads account filled with content every day.
- Trigger – what starts the work: a command, a schedule or an external event? For me the drafts lie in Telegram every morning at seven.
- One iteration – what exactly happens in one run? In my example: channel analysis, skill adjustment, ten fresh drafts.
- Check – where does the honest signal come from, and how does it change the next run? Hermes compares my edited versions with its drafts.
- Memory – what survives the boundary between attempts: progress, rejections with reasons, already-tried paths? For me those are the skills for hook search and text creation.
- Brakes – all endings except success: “there is no viable result, and that is the answer,” a fixed number of iterations without progress, an exhausted budget. These are legitimate exits, not defeats. A loop that can say “there is nothing today” is more valuable than one that squeezes out a norm.
- Human – everything the system cannot decide. In my case: taste, topic setting, the publication itself.
And then what? A ready-made prompt for all situations I cannot give you; with Hermes the architecture is a different one than with /goal in Codex or Claude Code. The common workflow is simple nonetheless. Step 1: start the agent and have it first gather the current state on loop engineering — the models’ knowledge ages in months, without web search they often work here with outdated commands. Step 2: hand over the filled-in seven-question passport with the task of building a loop from it. Step 3: run a test pass, watch and comment on what deviates.
Frequently asked questions on loop engineering
What is loop engineering? Loop engineering is the design and steering of cycles in which an AI agent repeats work runs until a stop criterion takes hold. The term established itself in 2025/2026 around techniques like Huntley’s Ralph loop and functions like /goal in Codex and Claude Code. The core is not the repetition but the check: every run must be measured against an honest signal.
Does loop engineering replace prompt engineering? No. The loop itself is commissioned with a prompt, and inside the cycle the model prompts itself. For one-off tasks a precise single prompt remains the cheapest tool; OpenAI positions /goal explicitly for long, multi-step tasks.
When is a loop not worth it? When no new information arises between the runs. A loop that only repeats “read again and improve” optimizes plausibility instead of quality. Also critical: tasks with expensive, irreversible errors like payments or deletions — there a human confirmation belongs before every action.
What does a loop cost? Every iteration is a full agent run and consumes tokens accordingly. In Gergely Orosz’s practice survey (July 2026, around 210 answers) the costs count among the three most frequent disappointments. Antidote: explicit stop criteria, scripts for deterministic checks and a start interval that fits the real frequency of change.
Do loops work outside programming too? Yes, as soon as a cheap, honest check signal exists: consistent sums, reachable links, evidenced statements, date windows. On taste and strategy questions the human stays the checker in the loop — as in my Threads example, in which the agent takes the mechanics and I the selection.
Four hundred years later
At the start stood an oven that regulated itself, because mercury cannot flatter. Exactly on that it is decided to this day whether a loop holds: on a check signal committed to reality and not to the wish to look good. Karpathy quotes in the same conversation a sentence that shaped him and that could hang over every loop: thinking can be delegated, understanding cannot. The loop takes on the runs. The judgment of what a good result is stays with you. There is, by the way, the well-founded view that the hand-built loop is a transitional phenomenon — functions like /goal are already in the agents, and with each generation they will suggest themselves where a cycle is worth it. Until then, test it on your own case: take a task you triggered by hand three times this week and fill in the seven-question passport. If no honest signal is left at question 4, spare yourself the loop — and keep the prompt.