Human developers have been increasingly edging themselves out of the development process, with seemingly positive results.

The rapid development of agentic coding started with code autocomplete (GitHub Copilot), graduated to chatbots (ChatGPT), then moved into IDEs (Cursor), and finally into the terminal itself (Claude Code). Now we have loop engineering: the point at which the developer steps out of the process entirely and instead builds the system that runs it.

While loop engineering can introduce massive productivity gains, if designed or managed improperly, it can also be painfully inefficient. One of the most costly mistakes to make in a loop is choosing the wrong model. Loops are iterative multi-stage, multi-turn processes. The work performed inside of them is not uniform in nature or complexity, meaning that selecting a single model for all tasks is never the answer. However, because the loop removes key points of human judgment from the development process, selecting the optimal model for the optimal task must be automated.

Loops that lack efficient, automated model orchestration risk producing lower quality output with poor latency at a higher operational cost. We argue that this orchestration needs to live in the inference layer. In this post, we explain the emergence of loop engineering, why it’s limited without proper model routing, and why model routing should live in the inference layer.

What is loop engineering?

Loop engineering is the practice of building a system that prompts your agent for you, instead of prompting it yourself, turn by turn. You move from directing each step at the keyboard to designing the system that runs and deciding what ships. The term surfaced in June 2026 from several people describing the same practice at once, among them Peter Steinberger, Boris Cherny, and Addy Osmani, who named it.

The first thing to understand about a loop is that it is not a single call. It runs on a schedule, it can spawn helper agents to work in parallel, and it runs while no one is watching. A loop fires call after call, unattended, often for hours. That volume and lack of supervision are what make its economics different from the older way of working, where a person issued one prompt, read the result, and decided what to do next.

The second thing to understand is that the calls a loop makes are not all the same kind of work. A single turn of a loop does several different things. It finds something worth doing. It drafts a change. It checks whether that change is any good. It decides whether the work is finished. These steps differ enormously in difficulty. Finding an open issue and reading a file is not the same order of problem as designing a fix, and neither resembles the simple yes-or-no check of whether a test now passes. One turn of a loop contains easy work and hard work side by side.

Where model selection breaks in the loop

A smart loop will have different models assigned to different stages. For instance, discovery and verification stages may be paired with a smaller model and execution with a larger one. Because these stages are static and predefined, pairing them with specific models is quite simple.

But where model selection fails in a loop is within the stages, especially execution. In the execution stage, the task agent will spawn subagents, that will each make their own model calls. Choosing the same model for all of them is inherently inefficient.

Consider the cost of this first. A loop runs unattended, often for hours, and that is precisely the point of building one. But it is also the danger. When a person runs a model interactively, they act as a natural brake or course corrector. A loop, however, has no such brake. Left running overnight, even a moderately priced model can accumulate real cost simply through volume and duration, and an expensive model does so far faster.

Quality is often lockstep with cost when it comes to model selection, as more capable models generally cost more. But beyond just cost, a single fixed model is simply the wrong size for most of a loop's calls. It is underpowered on the hard steps, where a stronger model would have done better, and overpowered on the easy ones, where the extra capability buys nothing.

Speed is a separate dimension that model choice alone tends to hide. A loop runs for a long time, and its steps do not all need the same pace. For some tasks, low latency is critical; for others, it matters far less. Latency, like capability, should be matched to the task rather than fixed once for the whole loop.

The solution lies in the inference layer

Every one of these wastes comes from the same missing decision, so that is where the fix has to go: something has to choose, for each call, which model should handle it.

That choice is model routing. Model routing sends each call to the model that best fits it, balancing quality against cost, instead of running every call through a single model. When done right, it lets each call cost roughly what it is worth, spending on the hard steps and saving on the easy ones. But it is hard to get right: the routing decision has to be fast enough not to add latency of its own, and spreading calls across many models can break the caching that keeps inference cheap in the first place.

The ideal model router for a loop is not hard to picture. It reads the actual call, so it can tell hard work from easy work rather than routing blind. It stays cheap enough to run on every call, so the routing never becomes the cost it was meant to cut. And it decides per call, across whatever tools the loop reaches through, rather than once per session or inside a single platform. We also think the ideal model router should be small, and at Fastino Labs that’s one thing we’re very good at.

Additional resources

• Loop Engineering blog