Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

Everything you actually need to know about loop engineering

You’ve probably seen loop engineering floating around X the last couple months. Threads on “the five parts.” Guides on building your first one. Someone in your feed saying prompt engineering is basically over now.

Most people just repost the thread and move on. Before you sink a weekend into learning it, here’s where it actually came from. I went and checked instead of taking it at face value.

Before we get into it, follow me on X for more articles like this.

X - https://x.com/waynoir

Where the name came from

Peter Steinberger, who built OpenClaw, put out a tweet saying people need to stop prompting coding agents one message at a time.

Peter Steinberger @steipete·Jun 8Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore.

You should be designing loops that prompt your agents.1.7K2.8K19K8.5M

Design the loop that does the prompting for you instead. Addy Osmani, who’s on the Chrome team at Google, turned that into a full essay on June 7th. O’Reilly Radar picked it up a couple weeks later. Boris Cherny, who runs Claude Code at Anthropic, was saying more or less the same thing around then too. His actual job now, he said, is writing the loops that prompt Claude, not typing prompts himself

Three people landed on the same idea in the same week without talking to each other. That’s not usually a coincidence. It means something already shifted underneath and everyone just noticed around the same time

What a loop actually is

A prompt gets you one answer then it waits on you to figure out what comes next. A loop keeps going by itself until whatever you asked for actually gets done. Every one that works has the same handful of pieces underneath it, even if nobody points them out directly.

There’s the trigger. Whatever kicks off a run. Could be you sending a message, could be a clock, could be some event firing. If there’s no trigger besides you, you’re still doing the work. Just with extra steps in between.

There’s the actual work. The agent gathering context, doing the task, reading back what happened.

Then there’s the gate, and this is the part most people mess up. It has to be something with zero opinion that can reject bad output outright. A test suite that fails or passes. A type check. A build. Not a vibe. Not the model looking at its own work and deciding it seems fine. Skip this and you’ve basically asked the agent to grade its own homework. And it turns out the model that wrote the code is an incredibly generous grader of that same code.

There’s state. Some record kept outside the actual conversation, what got done, what broke, what’s next. Without it, every run starts over from nothing and repeats whatever mistake it made last time.

And there’s a stop condition. Success, plus a hard limit for when success never shows up. Leave this out and you’ve built something that can burn all night doing nothing useful and never tell you it’s stuck.

Pull any one of these five out and the loop either stalls completely or spins in place while it keeps costing you money.

Why the gate is the part that actually matters

There’s an Anthropic engineer, Prithvi Rajasekaran, who ran into this directly while building agent systems meant to run for a long time. Ask an agent to grade its own work, and it praises it. Confidently. Even when a human looking at the exact same output can tell right away it’s mediocre. It’s not that the model is dumb. It’s more structural than that. The context where it wrote the code is stuffed full of every reason it had for writing it that way, so when it rereads the work, it mostly just sees its own reasoning reflected back, not the actual result sitting in front of it. Writers hit the same wall rereading their own drafts. You see the version that was in your head, not what’s actually on the page.

He tried the obvious fix first, pushing the same agent to be harsher on itself. Didn’t work. What worked was handing the checking job to a completely separate agent. Different instructions. Ideally a different model. Its only job is to assume the work is broken and go looking for why. It’s the same reason a bank doesn’t let the person who enters a large transfer also approve it.

When it’s actually worth building one

There are four conditions here, and if even one is missing, you’re better off prompting manually instead of setting all this up.

The task needs to actually repeat, at least weekly. Otherwise the setup cost never pays for itself.

Something needs to be able to reject bad output automatically. An actual command that fails or passes. Not you eyeballing it.

The agent needs to be able to do the whole thing end to end. Not do half and hand the rest back to you.

And “done” needs to be objective, not a judgment call. If quality is subjective, a person still wins that fight.

The loops worth building tend to be the boring ones. CI failure triage. Dependency bumps. Lint and fix passes. Chasing down flaky tests. The ones that feel exciting to hand off, architecture calls, anything near auth or payments, production deploys, anything where “done” is really someone’s judgment call, those are exactly the ones you want to keep doing by hand.

There’s also a version of this that shows up even if you never touch a scheduler or a cron job. When you’re actually building a product, you’re not running one loop, you’re running three, stacked inside each other at different speeds. The agentic coding loop is the fastest one, the coding agent writing, testing, and rewriting its own work every few minutes without you in the room. Sitting above that is the developer feedback loop, you actually looking at what got built and steering it, on the order of tens of minutes to hours, not seconds. Above that is the external feedback loop, real users or testers actually using the thing, which can take hours or stretch into weeks. The outer loops feed the inner one. What a tester says on day four changes what the coding agent gets asked to do on day five. And here’s the part that’s easy to miss. Speeding up the innermost loop doesn’t automatically speed up the whole system. The two outer loops are still bottlenecked on a human actually looking at something and forming an opinion about it.

That’s worth sitting with. It’s also a decent argument for why loop engineering isn’t going to make human judgment less relevant. It just makes judgment the one part of the system that can’t be sped up anymore.

The cost nobody mentions in the demo

Loops run on tokens, and the cost adds up in a way that’s easy to miss at first. Every time it goes around again, it’s re-reading its own context, the goal, the code so far, whatever happened last round. That pile of context just keeps growing every pass. A loop that runs ten times isn’t ten prompts worth of cost. It’s ten prompts that each get a little bigger than the last one. A single medium task can run anywhere from 50,000 to 200,000 tokens on its own before you’ve added anything else.

Add a separate agent to verify the work, which is genuinely the thing that improves quality the most, and you basically double your bill on top of that, since now two models are reading through everything instead of one.

The number that actually matters here isn’t tokens spent or how many runs completed. It’s cost per accepted change. If your loop spits out ten results and you throw away six of them, you’re just doing the review work by hand that the loop was supposed to save you from. Once your accept rate drops under half, the loop is quietly costing you more than it’s giving back. There’s a name for the specific way this goes wrong too. Geoffrey Huntley calls it the “Ralph Wiggum loop,” where the agent convinces itself it’s done way too early, exits on something that’s actually half finished, and the loop keeps running and spending while producing nothing. It won’t crash when this happens. It’ll just quietly bill you.

So, honestly

Loop engineering is a real shift. Not because the idea itself is new, agents that check their own work and retry aren’t a new concept. What’s actually new is that models finally got good enough that running this whole cycle unattended is worth the money. The people getting real value out of it aren’t the ones who found a clever prompt trick. They’re the ones who sat down and wrote a real gate, a real stop condition, a real state file, instead of hoping the agent figures out on its own when to stop.

There’s an easy test for whether you’ve actually built one of these or just something that feels like one. You can get most of the behavior of a loop right now, in any chat window, by giving the model a goal, strict criteria, and telling it to score its own output and keep going until it clears the bar. It’ll draft, grade itself, find the weak spot, rewrite, over and over, and it genuinely works. But you’re still the trigger. You opened the tab, you pasted the prompt, you’re the one sitting there watching it iterate. Close the tab and it’s gone. Nothing runs while you’re not looking. A real loop is the same thing minus you being in the room for it.

Get that part right before you let anyone convince you the next renamed version of this is the thing that actually matters.

If you want to stay up to date with everything happening in AI.

follow me on X : https://x.com/waynoir