Loop Engineering describes a practice that spread quickly through the AI coding community in the first half of 2026: instead of giving an AI Agent instructions one at a time, you build a loop that finds its own work, dispatches it, and checks the results, so the Agent keeps running inside that loop.
The focus of the term isn't the model but the ring around it. Who decides what happens next, how the output gets accepted, what happens on failure, and who calls a halt when things drift — those are the questions Loop Engineering is about.
Grab It in One Sentence First
Loop Engineering replaces "you repeatedly prompting the Agent" with "a system repeatedly prompting the Agent," leaving you responsible for that system's goals, boundaries, and acceptance criteria.
An everyday analogy is going from ordering à la carte to writing a shift schedule. Before, you ordered one dish when you got hungry and ordered the next one after finishing it; now you write a schedule and a quality standard, and the kitchen preps, cooks, tastes, and redoes on its own, while you only show up at the pass and when something goes wrong. The dishes are the same; what changed is who pushes the next step.
Why This Term Emerged
In early June 2026, Peter Steinberger posted a widely shared line on X, roughly: stop prompting coding agents, and start designing the loops that prompt your agents. He supplied the provocation but not the name. Addy Osmani then published a long post titled "Loop Engineering" that organized the practice into a named pattern with a structure, and the term stuck.
Boris Cherny, who leads Claude Code at Anthropic, said something similar — that he no longer prompts Claude directly, that he has loops running which figure out what to do, and that his job is to write loops. Those statements landing together is what pushed the term into wide circulation in mid-2026.
The reality behind it: the quality of a single coding-Agent run is already good enough, and the bottleneck has moved to "one person can only watch one session at a time." When a model can work for tens of minutes straight but a human can only sit beside it clicking confirm, taking the human out of every step of the loop becomes the natural next move.
flowchart LR
Goal["Your goal and acceptance criteria"] --> Discover["Discover work<br/>schedule / queue / issues"]
Discover --> Dispatch["Dispatch to Agents<br/>isolated workspaces, in parallel"]
Dispatch --> Run["Agent executes"]
Run --> Verify["Verify<br/>tests / evals / review"]
Verify -->|fails| Dispatch
Verify -->|passes| Ship["Ship and record state"]
Ship --> DiscoverWhat It Usually Includes
Addy Osmani's post breaks a complete loop into several pieces. The first is scheduled tasks that discover and triage work on a cadence, so the loop starts with a schedule rather than with you typing. The second is isolated workspaces, so several Agents can run in parallel without overwriting each other's files — commonly one git worktree per task.
The third is codified knowledge: the project conventions you'd otherwise re-explain every time, written down as reusable skill files instead of pasted anew. The fourth is external connections, wiring Agents to issue trackers, CI, databases, and browsers through standard interfaces such as MCP. The fifth is subagents, separating the one that proposes from the one that finds fault, so a single context isn't grading its own work.
There's one more piece that gets overlooked and matters a lot: external state. Once a loop has run for a while, progress, open items, and failure reasons can't live only in conversation history; they need to land in markdown files, a board, or a database, so the loop can pick up where it left off after a restart.
The Difference from Prompt Engineering and Harness Engineering
The three terms sit at different layers. Prompt Engineering is about "how to say it clearly this time." Harness Engineering is about "what environment should surround the Agent while it works" — context, tools, permissions, verification. Loop Engineering sits one layer further out: who decides whether there's a next run at all, and what it should be.
Think of it this way: the harness is the venue built for one execution, and the loop is the scheduling that gets the venue used over and over. Osmani's post also distinguishes the inner loop from the outer one — the inner loop is the think-act-observe cycle the Agent already runs each turn, while the outer loop is the layer you build: waking the inner loop on a cadence, feeding it work, checking output, deciding what's next.
Its Relationship to Agents and Automation Scripts
An Agent is the role doing the work inside the loop; the loop is the mechanism that keeps giving it work and checking the results. Traditional automation scripts are loops too, but every step in a script is deterministic, whereas here each step is judged by a model on the spot — which makes the verification stage carry far more weight than it does in a script.
For exactly that reason, Loop Engineering in practice is almost always tied to evals, tests, and code review. A loop without automatic acceptance isn't a loop; it's unsupervised bulk generation.
Where It's Easy to Misunderstand
The most common misreading is treating it as "let the AI take over completely." Osmani specifically warns about three things: the burden of verification stays with humans, and unattended loops make unattended mistakes; chasing shipping speed alone builds up "comprehension debt," where code lands in the repo that nobody actually understands; and the most dangerous one — surrendering judgment and accepting whatever the loop produces. His point, roughly, is that the same loop produces opposite outcomes in the hands of an engineer who still maintains understanding versus someone who automated away the responsibility along with the work.
Another misconception is that every task deserves a loop. The same Steinberger has also written a piece arguing for dropping ceremony and just talking to the model. The two positions don't conflict: for exploratory, one-off work where you change your mind as you watch, a loop is pure overhead; for repetitive work with a clear acceptance bar that can run unattended, a loop pays off.
How to Decide Whether to Use It
Start with three questions. Will this recur? Can "done" be written as a machine-checkable condition — tests pass, eval score above threshold, schema validates? Would a failure be irreversible?
Tasks where the first two are yes and the third is no are the best candidates: dependency upgrades, bulk lint fixes, backfilling tests, triaging a backlog of issues into actionable work. Conversely, when the requirements aren't settled, acceptance depends entirely on human eyes, or a mistake would touch production data and live configuration, don't rush to automate — get the harness and the acceptance criteria solid first.