What Is Loop Engineering? A Complete Guide (2026)

Loop engineering is the practice of designing the system that prompts an AI agent for you - one that finds the work, hands it out, checks it, records what's done, and decides what's next - instead of typing each prompt by hand. You stop being the person holding the tool one turn at a time, and become the person who designs the machine that holds it. It's widely described as the 2026 successor to prompt engineering: the model writes the prompts now, so the scarce skill has moved from phrasing instructions to designing the cycle that keeps an agent correct and pointed at a goal.

This guide explains what loop engineering is, where it came from, the pieces a loop is built from, and - just as important - what it still doesn't do for you.

Loop Engineering, Defined

For about two years, getting value out of a coding agent meant a manual turn-by-turn conversation: you wrote a good prompt with enough context, read what came back, and typed the next thing. You were holding the tool the whole time.

Loop engineering replaces you as the one doing the prompting. You build a small system that surfaces work, dispatches it to agents, verifies the result, writes down what happened, and decides the next action - then you let that system poke the agents instead of doing it yourself. As Google engineer Addy Osmani framed it in the essay that named the practice, a loop is essentially a recursive goal: you define the purpose and the AI iterates until it's complete.

It's worth being precise about where this sits, because the popular summaries tend to blur it. Loop engineering is one layer above the "harness" - the environment a single agent runs inside. The harness is the room; the loop is the harness running on a timer, spawning helpers, and feeding itself.

Where the Term Came From

Loop engineering got its name in June 2026, almost overnight. Developer Peter Steinberger compressed the idea into a line - that you shouldn't be prompting coding agents anymore, you should be designing the loops that prompt them - and Osmani published an essay naming and structuring the practice the same week. Boris Cherny, who leads Claude Code at Anthropic, made the same point from the vendor side: that he no longer prompts the model directly, but instead writes the loops that drive it and decide what to do next.

Notably, Osmani himself introduced the idea with open skepticism - flagging that it's still early and that token costs can swing wildly depending on how you set a loop up. That caution is a real part of the original argument, and it's the first thing most secondhand explainers quietly drop.

The technique also predates the name. Earlier in 2026, engineer Geoffrey Huntley described running a coding agent inside a plain while loop: feed it the same prompt against a written spec, let it pick one task and implement it, then start a fresh instance and feed the identical prompt again - repeating until done. He called it "Ralph," and its non-obvious trick was the context reset: a long agent session degrades, so starting clean each iteration kept quality high.

The Five Building Blocks (Plus a Sixth)

Here's where accuracy matters. In the original framing, a loop isn't a five-step cycle - it's five components, plus a sixth for memory. Getting this right is what separates a working loop from a leaky one.

1. Automations - scheduled runs that do discovery and triage on their own. This is the heartbeat; it's what makes a loop an actual loop instead of a single run you did once.

2. Worktrees - isolated working directories so two agents running in parallel don't edit the same files and collide, the same way two engineers committing to the same lines without talking would.

3. Skills - project knowledge written down (typically a SKILL.md file) so the agent reads your conventions every run instead of guessing at them cold each session.

4. Plugins and connectors - built on MCP, these plug the agent into the tools you already use: the issue tracker, a database, a staging API, Slack. This is the difference between an agent that says "here's the fix" and a loop that opens the PR, links the ticket, and pings the channel once CI is green.

5. Sub-agents - one agent has the idea, a different one checks it.

And then the sixth thing: memory. A markdown file, a Linear board - anything that lives outside the single conversation and holds what's done and what's next. It sounds too dumb to matter, but it's the trick every long-running agent depends on: the model forgets everything between runs, so the state has to live on disk, not in the context. The agent forgets; the repo doesn't.

Both major coding-agent products - Claude Code and OpenAI's Codex - now ship all five components plus memory, which is why the practice stopped being a pile of bash scripts only you understood and became something you can assemble inside the tools.

The Verifier Is the Part That Matters Most

Of the five components, splitting the maker from the checker is the single most important structural decision - because a loop runs while you're not watching, and a verifier you actually trust is the only reason you can walk away.

The reasoning is simple: the model that wrote the code is far too generous grading its own homework. A second agent - different instructions, sometimes a different model entirely - catches what the first one talked itself into. This is also, under the hood, what a "run until done" primitive does: after each turn, a separate model decides whether the stopping condition is truly met, rather than the agent that did the work declaring itself finished.

The catch is that "done" is a claim, not a proof. Loops work best on verifiable tasks - formatting, dependency upgrades, well-scoped bugs, a test suite to keep green - where feedback is clear. On ambiguous work like architectural refactoring or UX judgment, the feedback weakens, and the one metric that keeps reliably growing is cost.

What One Loop Actually Looks Like

Put the pieces together and a single thread becomes a small control panel. One common shape:

An automation runs every morning on the repo. Its prompt calls a triage skill that reads yesterday's CI failures, open issues, and recent commits, and writes the findings into a state file. For each finding worth doing, the thread opens an isolated worktree, sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project's skills and existing tests. Connectors let the loop open the PR and update the ticket. Anything it can't handle lands in a triage inbox for you. The state file is the spine - it remembers what was tried, what passed, and what's still open, so tomorrow's run picks up where today's stopped.

The point: you designed that once. You didn't prompt any individual step. And it's the same loop whether it runs in Codex or Claude Code, because the pieces are the same pieces.

What Loop Engineering Still Doesn't Do for You

This is the part the "complete guides" tend to skip, and it's arguably the most important. A loop changes the work; it doesn't remove you from it. Three problems actually get sharper as the loop gets better:

• Verification stays on you. A loop running unattended is a loop making mistakes unattended. Splitting off a verifier makes "it's done" mean something - but your job is still to ship code you confirmed works.

• Your understanding rots if you let it. The faster the loop ships code you didn't write, the wider the gap between what exists and what you actually grasp - "comprehension debt," in Osmani's phrase. A smooth loop just grows that gap faster unless you read what it made.

• The comfortable posture is the dangerous one. When the loop runs itself, it's tempting to stop having an opinion and take whatever it returns - "cognitive surrender." Designing a loop is the cure when done with judgment and the accelerant when done to avoid thinking. Same action, opposite result.

When Should You Use Loop Engineering?

Reach for a loop when a single agent turn is no longer the bottleneck and the task is repetitive with a clear, checkable definition of done - keeping a test suite green, dependency upgrades, triaging incoming issues, fixing well-scoped bugs. Stay with direct prompting for one-off, ambiguous, or high-judgment work where you can't cheaply define what "correct" looks like. Prompting your agents by hand is still effective; the skill is finding the balance.

A good first exercise: pick one repetitive task this week. Before writing a single instruction, write down what "done" means in measurable terms. Then set the checks, choose your components, and let the loop run against your bar instead of the model's.

The Bottom Line

Loop engineering marks a shift in the developer's role from operator to architect. But the sharpest observation in the original framing is this: two people can build the exact same loop and get opposite results. One uses it to move faster on work they understand deeply; the other uses it to avoid understanding the work at all. The loop doesn't know the difference - you do. That's what makes loop design harder than prompt engineering, not easier. The work didn't get easier; the leverage point moved. Build the loop - but build it like someone who intends to stay the engineer, not just the person who presses go.