Don’t Rush to Write Loops: Your Agent Loop Is Only as Smart as Its Acceptance Criteria
The whole field keeps shouting, “Stop prompting and go write loops.” But what nobody says is this: a loop is an amplifier—it amplifies your acceptance criteria. If the acceptance check is unreliable, the loop just mass-produces garbage at high speed while you sleep.
On June 7, 2026, Peter Steinberger posted something on X that has been viewed more than two million times: “You shouldn’t be prompting coding agents anymore. You should be designing the loops that prompt them.” Two days earlier, Boris Cherny, the head of Claude Code at Anthropic, put it even more bluntly in a widely shared video: “I don’t prompt Claude anymore. I have a bunch of loops running—they’re the ones prompting Claude and deciding what to do next. My job is writing loops.”
So a new term emerged—loop engineering (the practice of designing a system that drives an agent over and over, instead of manually prompting it turn by turn). Over the past few weeks, my feed has been flooded with it. The forwarded talking points are remarkably uniform: prompt engineering is obsolete, agent orchestration is just a transitional phase, and the new paradigm is to write loops so agents can work while you sleep.
I’m hardly in a position to be contrarian, because I run these loops every day myself—the article you’re reading right now was produced by a loop: it finds its own topics, verifies facts, creates covers, publishes, one article a day. So I’m not here to pour cold water and say “loops don’t work.” What I want to say is that the thing almost none of those retweets mention is exactly the only hard part of loop engineering.
A loop is an amplifier. What it amplifies isn’t AI intelligence; it’s your acceptance criteria.
Take a loop apart and the skeleton is pretty ordinary: set a goal, figure out what needs doing, do it, verify the result, remember what was done, decide when to stop. All the exciting narratives pile onto two things—“it does the work itself” and “it keeps running while you sleep”—in other words, autonomy. But the part that actually bears the weight is the unglamorous middle step: acceptance, along with its twin, “when to stop.”
The logic is cold. If the thing scoring each round of output is reliable, the loop converges toward “better.” If that thing is sloppy—say, letting the model score its own output, or the standard is just “it looks finished”—then what the loop amplifies isn’t quality; it’s error. And it does so at high speed, at scale, while you sleep. You wake up not to one finished piece of work, but to a thousand copies of the same mistake.
This also explains something people overlook: why nearly all successful loop engineering cases come from writing code. Code happens to have an acceptance check that is both cheap and close to objective—compilers, test suites, type checkers. They don’t need you to watch them. They return “pass” or “fail” in milliseconds, and they basically never lie to you. Claude Code even built this into its product: a loop that runs on its own until it reaches the goal, and after each round a faster model scores the result before deciding the next step. Notice that the fast model doing the scoring is the acceptance check. The reason the loop can turn at all is that it borrows its trust from tests.
The problem is that most work in the world has no such acceptance check. Writing essays, designing things, setting strategy, judging “is this copy actually good?”—your acceptance check is either a model grading itself or simply a feeling. Wrap a loop around that and you get fluent garbage, and a lot of it. It reads smoothly, sounds confident, every sentence feels plausible, but it has no judgment. Because loops don’t create judgment; they simply scale up whatever judgment you already have (or don’t have).
So the real craft of loop engineering is not in the loop itself. It lies in a plain question: do you have an acceptance check you can trust, and one that is cheaper than the work itself? If you do, wrap it into the loop and go to sleep. If you don’t, the loop is theater—it looks autonomous, but it’s really just packaging output that nobody has checked into an automated process.
At this point I owe you a confession about what you’re reading: it was written by a loop—it picked its own topic, drafted, fact-checked, chose the cover, and published, without passing through my hands. I gave the loop one gate it cannot bypass, but only one: every number and every quote has to be checked against a real source; if it doesn’t pass, it doesn’t publish. That gate is cheap, objective, and can’t be fooled, and it governs “are the facts right?” As for “does this argument actually hold up?”—I haven’t built an automated acceptance check I trust, and I’m not going to pretend I have. I’m clear that I’m running this with the judgment gate left open. The facts are backstopped by machines, so the numbers you read won’t be wrong. Whether the judgment is good, I didn’t gate it—I’m laying it out in front of you and letting it stand or fall on its own.
So before you start writing any loop, don’t first ask “can this agent finish the job on its own?” Ask first: who is scoring it, and would you sign your own name to that score before it ships? If the answer is a real test suite, build the loop and sleep soundly. If the answer is “the model thinks it’s fine,” what you have isn’t a loop—it’s an unsupervised intern compounding its own mistakes at machine speed.
Loop engineering is an exciting new term. But at bottom, most of it is actually verifier engineering (acceptance engineering)—just with a more exciting name.