Loop Engineering Minus the Hype

Loop engineering, where developers define loops that prompt coding agents until a task is complete, is gaining attention from figures like Peter Steinberger and Boris Cherny. However, the approach faces challenges: coding agents already loop internally, and defining robust verification upfront can be slower than interactive development. For ambiguous product features, interactive agent use may be more efficient than rigid loops.

“Loop engineering” is having a moment. Peter Steinberger, the creator of OpenClaw, told a few million people https://x.com/steipete/status/2063697162748260627?s=20 to stop prompting coding agents and start designing the loops that prompt them. Boris Cherny, who created Claude Code, says https://x.com/PawelHuryn/status/2069363303952818474?s=20 he no longer prompts Claude directly. Loops prompt Claude, and his job is to write the loops. Then the pattern got a name, and the hot takes https://x.com/mvanhorn/status/2063865685558903149?s=20 followed 😱 The basic idea is: instead of guiding a coding agent step by step, define a “loop” that lets it keep working until the task satisfies some “done” condition while you sleep, eat, and live the good life. The loop keeps the pesky agent accountable and on track as it builds your empire. Win-win With a bit of patience, you could set up teams of agents continuously building, reviewing, deploying, and repairing software while humans occasionally adjust the machinery. This vision sounds too good to be true. And it is, kind of. It also contains a grain of truth. The problem is figuring out which grain. The first slightly awkward fact is that a coding agent is already a loop. Codex and Claude Code do not take one action and stop. They inspect the codebase, make a change, run a command, look at the result, reconsider, make another change, and continue until they believe they are done. Sometimes they believe this a little too early, but the looping part is already there. So when we add another loop around the agent, that loop needs to do something useful beyond saying: Please continue looping. Make no mistakes With that said, a loop can be genuinely additive and still be a terrible idea. Why? I’m glad you asked. The usual loop story assumes that success is already defined, or at least can be defined with little ambiguity. Unfortunately, product development often does not work that way. The building process and the discovery process happen together. You change a screen because the product manager asked for it, and an end-to-end test breaks. Is the feature wrong? Or is the test now obsolete? The failure tells you that two sources of truth disagree. It does not tell you which one should win. Now the loop has a problem. A rigid loop gets stuck banging its head against obsolete tests and irrelevant constraints. A flexible loop can “succeed” by weakening the tests, accepting scope creep, drifting away from the original intention, or redefining the task until its current output counts as done. This is not because the model has bad intentions but because every specification has gaps, and the model is forced to fill them. But let’s say we can somehow write a near-perfect specification. There is still another problem. Defining good verification upfront can take longer than building the feature interactively with the agent. To create a robust loop, you may need to spell out: At some point you may notice that you are not merely “defining the loop.” You are designing the feature plus massive scaffolding around it, but wait... Interactive development with a good coding agent is already quite fast. You ask it to build something. You look at it. You notice that the empty state is weird, the mobile layout is broken, and the filter should probably survive a page refresh. You clarify. It changes the implementation. You look again. The implementation helps you discover the specification. So the relevant question is not: Is writing a loop faster than writing the code myself? That comparison is obsolete. The real question is: Is defining and supervising the loop faster than building the feature interactively with an agent? For a one-off, ambiguous product feature, I suspect the answer is often no. The obvious counterargument is amortization. If you build the verifier once and then run it every night, across every repository, or for the hundredth dependency upgrade, the setup cost starts to make economic sense. Correct. That gives us a useful rule: Loops make sense when the cost of verification can compound across many attempts or many tasks. This brings us to the places where loops really do look powerful. Coding agents often stop at a slightly irritating point. They implement the feature. They run a unit test. Maybe they run the type checker. Then they proudly tell you the work is complete. You open the app and the button does nothing. A better handoff loop could: The goal is not full autonomy. It is to stop involving the human before the agent has exhausted the cheap and obvious work. The loop should not blindly satisfy every reviewer or rewrite every failing test. Its job is to finish the routine work and package the disagreements. I think this category is immediately useful. I also would not overinvest in it. Browser testing, CI monitoring, and review follow-up are generic capabilities. Codex, Claude Code, and similar harnesses have every reason to absorb them. It may be worth building a lightweight version today because it saves you time today. It is probably not worth creating a grand internal “agent orchestration platform” around the fact that the coding agent currently forgets to open Chrome. The second category is repeated search against a measurable target. Suppose the goal is: These tasks have something precious: A success landscape. The agent can make a change, measure the result, keep improvements, discard regressions, and try again. You can even run several agents in parallel and choose the best result. This is much closer to actual software-factory work. The target is stable enough that repeated search is useful. Of course, the target is only as good as the guardrails around it. A Rust rewrite that passes all tests may still have worse operability, broken failure modes, or subtle behavioural differences the tests never captured. So the first step may be building the environment in which the loop can safely search: That setup may be expensive. But unlike the specification for a single product feature, it can pay for itself repeatedly. Every attempt, every parallel agent, and every future task of the same type benefits from it. This is where the economics start to work. The third category is the most interesting because the agents do not wait for you to give them work. The system watches the business and reacts. It might monitor: An agent can cluster related signals, investigate likely causes, reproduce a problem, write a regression test, prepare a fix, and open a pull request. Sometimes it may even be safe to deploy the repair automatically. Now we have something that really does look like a factory: Production emits a signal. The agent investigates it, fixes the problem, deploys the change, monitors the result, and waits for the next signal. This is the image that sends everyone racing toward fully autonomous software companies. But there is a subtle switch hiding inside the story. Operational loops are very good at two things: They are much less obviously good at deciding what “good” should mean. An agent can detect that a deployment broke checkout and restore the previous behaviour. It can notice that hundreds of customers struggle with onboarding step three and present the pattern, examples, and likely causes. But should it redesign the onboarding flow? Which trade-off should it make? Should the product become simpler for new customers at the expense of expert users? Is this problem more important than the five other things the company could build? Now we are no longer repairing the machine. We are deciding what machine to build. This is the distinction the software-factory metaphor tends to hide. In control-system language, loops make good regulators and poor reference-setters. A regulator keeps a system close to a target. A reference-setter chooses the target. Agent loops can plausibly: They become much less trustworthy when they must: This does not make loop engineering fake. It makes it narrower and, I think, more useful. The software factories may be real. They may keep systems running, optimize them, repair regressions, and continuously bring humans better information. That would already be a very big deal. But they will be much better at running and improving a known machine than deciding what machine the business should build next. And that second problem is where most of the value, and most of the judgment, still lives.