Loop Engineering Is Real, Useful, and Everywhere. It's Still Not a Strategy.

Walk into almost any engineering team shipping with AI right now and you can find the same setup running somewhere on a laptop. An agent sits in a loop, reads the next task off a list, writes some code, commits it, and starts over. Left alone overnight, it can turn a rough idea into a working prototype by morning. The technique is real and the results are often impressive. The trouble starts when leaders mistake running the loop for having a strategy.

The pattern got its name fast. Addy Osmani's widely read field guide called it loop engineering, framing the shift as replacing yourself as the person who prompts the agent to instead design the system that does the prompting. The phrase moved through the builder community in days. Amid all the excitement, Osmani was careful about one thing: A loop is only as good as the condition that tells it to stop and the check that runs after every turn. He said the verification is still your job.

Martin Rojas has spent this year trying to make that idea survive contact with production. As AI Acceleration Lead at PlayOn Sports, the high school sports media and streaming company, he chairs an internal AI Guild whose whole reason to exist is moving teams from experiments to systems that people actually depend on, and before that he spent years as a senior engineer inside ad and marketing agencies. He isn't a skeptic here. He runs loops. His warning is about what happens when a team confuses one for a plan. "Loop engineering is real, useful, and everywhere right now," Rojas wrote on LinkedIn. "It's also not a strategy." In the piece titled "Loops Are for Prototypes. Lifecycles Are for Production.," he lands on a reframe that both the enthusiasts and the cynics tend to skip. A loop and a lifecycle aren't rivals but stages, and the skill worth having is knowing which stage a project is in and when it has to move from the first to the second.

Where loops earn their keep

His case starts by giving loops their due. When the work is exploratory—a spike or a proof of concept or a throwaway build meant to surface a design problem—a loop is close to the ideal tool. The requirements are still moving, nothing downstream depends on the output, and the thing you're optimizing for is how fast you learn, not whether every line is correct. A loop reading a task list off disk and grinding through it overnight can genuinely hand you a working prototype by morning. For that kind of work, Rojas argued, adding process would be the mistake, not the loop. Nobody needs a change-management gate on something that might be deleted on Friday.

The verification problem

The trouble is that the same properties that make a loop ideal for a prototype turn dangerous the moment the output starts to matter, and the reason is structural rather than a question of model quality. "The verifier is the author," Rojas wrote. In a simple loop, the agent that checks the work runs on the same instructions and the same weak points as the agent that wrote it, so it's inclined to approve its own output. A prototype can absorb that, but a system other people rely on cannot. Real verification has to be independent, and that means different instructions, often a different model, and pass-or-fail criteria that live outside the agent and don't bend to it. Designing those checks takes senior engineering judgment. A loop can’t independently define the standard by which its own work should be judged.

And self-agreement isn't the only way a loop turns on you. Left running long enough, small deviations pile up into drift that no single pass would flag. Loops that rewrite their own instruction files can write a bad decision straight into memory, where it biases every run that follows instead of costing one wrong output. And a loop holds no view about what matters. It executes whatever is next on the list, with no sense that this ticket touches billing or that this migration can't be undone. Those judgments live in process, which is the thing a bare loop was built to strip away.

The cost of running loops

The gap between a prototype and a product shows up on the invoice. Agentic loops are expensive by design, and the numbers aren't small. In Anthropic's own account of building a multi-agent research system, the company reported that agents burn roughly four times the tokens of a normal chat, and multi-agent setups about fifteen times. A loop with no stop condition and no budget doesn't read as persistent so much as a bill that keeps climbing while nobody is watching. Rojas framed it more sharply, calling an ungoverned loop "a debt-creation machine running at machine speed."

Loops inside lifecycles

None of this means the loop disappears in a serious setup. It just gets demoted. In a production workflow the loop becomes the execution primitive inside a larger lifecycle, the way a function call sits inside an application, wrapped in the things a bare loop leaves out. Specification comes first, because an agent will happily turn a vague ticket into confident, wrong code. Verification runs against hard, external criteria instead of the agent's own sense that it's finished. Humans sit at the irreversible steps.

That last piece maps neatly onto a broader distinction: being in the loop means approving every step, while being on the loop means designing the specs, tests, and checkpoints, then stepping in only when a decision can’t be rolled back. The work shifts from clicking approve to building the harness that defines what approval requires.

For anyone running an engineering team, that redraws where the value sits. If a loop can produce the first working version of almost anything, the scarce skill stops being the ability to produce code and becomes the ability to say what has to be true before that code ships, and to build the checks that hold the line when no human is reading every diff. That's senior work. It rewards the engineer who can specify tightly, design verification a loop can't game, and decide which changes are the ones a machine should never wave through on its own. AI hasn't made that engineer easier to do without; it's raised the price of exactly the judgment it can't supply, and handed more of the week to the people who have it.

A loop will build you something impressive by morning. Deciding what has to be true before it ships, and making sure something other than the loop is the judge, is the part you still hire an engineer to do.