"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops." That line, from the engineer who leads Claude Code at Anthropic, captures a shift that got a name in June 2026: loop engineering. A loop engineer doesn't type each instruction to a coding agent — they design the system that does it: the goal, the way to check the work, the rules for when to retry and when to stop. It's an emerging practice, not a standardized job title, and it matters because longer-running agents have moved the leverage from writing the prompt to designing the cycle around it. Here's what that practice actually involves.
Why the Term Loop Engineer Is Appearing
An emerging practice rather than a standardized job title
"Loop engineer" describes a skill and a way of working, not a formal, widely-recognized job title or any certified discipline. The term emerged in mid-2026 from practitioners describing how their own work had changed — it's being discussed by engineers at Anthropic, Google, and elsewhere as one of the fast-growing skills in agentic AI, but it's a role description in formation, not an established profession with a defined credential. So treat "loop engineer" as a useful label for an emerging competency, not as a job category you'd find in a standardized titles list. The honest framing is: a name that crystallized recently for something experienced agent users had already started doing.
Why longer-running agents change the engineering problem
The reason the term appeared now is that coding agents became capable of running unattended for long stretches. When an agent only handled one turn at a time, you supervised each step — the engineering problem was the single prompt. Once agents can run for minutes or hours, correcting themselves against real signals, the problem changes: you're no longer steering each move, you're designing a system that steers itself. As Addy Osmani (the Google engineer who popularized the term) put it, loop engineering is replacing yourself as the person who prompts the agent and designing the system that does it instead. That's a genuinely different engineering task than prompting — it's control-system design around an autonomous actor, and it's why a new name attached to it.
What a Loop Engineer Designs
Define the goal and an observable success condition
The foundation of any loop is a goal with a checkable success condition. "Make the code better" is not a loop goal, because the loop can never know when it's done; "make all the tests pass" or "the linter returns zero errors" is, because success is objectively observable. A loop engineer's first job is turning a fuzzy intention into a recursive goal the system can verify — defining not just what to achieve but how the system will know it's achieved. Without an observable success condition, the loop has no exit, and a loop with no exit isn't autonomous work, it's an open-ended token spend. The checkable goal is the floor the whole loop stands on.
Preserve state between actions and retries
A loop runs many steps, and each step generates context — code written, errors hit, decisions made — that the next step needs. A loop engineer designs how state persists across iterations: what the system remembers, how it summarizes a growing history into compact working memory, and how it avoids overflowing the context window on a long run. Without deliberate state management, a long loop either forgets what it already tried (and repeats itself) or drowns in its own accumulated history. Designing the memory — what to keep, what to prune, what to offload — is as much a part of loop engineering as defining the goal, because continuity across steps is what lets a loop make progress rather than spin.
Choose tools, validators, and stopping rules
Three more design choices define the loop. Tools are how the agent touches the real environment — running code, reading and writing files, executing tests; the loop's feedback is only as honest as the tools that produce it (an agent that can't run its own code is just guessing). Validators are how the loop checks the agent's work — ideally a verifier separate from the maker, so "it's done" means something rather than being the agent's own unchecked claim. Stopping rules are the conditions that end the loop — success, a hard iteration or budget cap, or an escalation to a human after N failed attempts. A loop engineer designs all three deliberately, because they're what separate a reliable loop from a runaway one that retries forever or accepts wrong results.
Loop Engineering vs Prompt Engineering
From optimizing one input to governing repeated execution
Prompt engineering and loop engineering optimize different things. Prompt engineering asks: what should I say to get the best output from a single turn? Loop engineering asks: what system should I build so the agent finds the work, does it, verifies it, and decides what's next — without me typing each prompt? One optimizes an input; the other governs a repeated execution cycle. This isn't a replacement — prompt engineering doesn't become obsolete, because the loop still issues prompts and the quality of those prompts still matters. It's a different layer: you're designing the system that prompts, rather than doing the prompting. The leverage moved up a level; it didn't erase the level below it.
Treating feedback quality as part of the system
The deeper shift is that a loop engineer treats the feedback signal itself as a design responsibility. In single-turn prompting, you read the output and judge it yourself. In a loop, the system judges the output, so the quality of that judgment — how errors are structured before being fed back, whether the validator actually catches wrong results, whether repeated errors are distinguished from new ones — becomes part of what you engineer (the reason-and-act pattern underlying these loops interleaves thinking with observed results for exactly this reason). A loop with a sloppy feedback signal makes confident wrong moves; a loop with structured, honest feedback corrects itself. Designing the feedback, not just the prompt, is central to the practice, and it's why loop design is arguably harder than prompt design, not easier.
How It Relates to Harness Engineering
Harness engineering builds the surrounding environment
Loop engineering sits next to another recent term, harness engineering, and the two are layers rather than rivals. Harness engineering is about building the environment a single agent runs inside — the tools it can reach, the context it's given, the scaffolding that shapes one agent's run. It's the "where the agent operates" layer: the file access, the terminal, the context assembly, the guardrails around a single execution. A well-built harness is what makes any individual agent run effective.
Loop engineering controls repeated action and feedback
Loop engineering sits one floor above the harness. Where the harness shapes a single run, the loop runs that harness repeatedly — on a trigger or schedule, feeding each run's results into the next, deciding whether to retry, and stopping when the goal is met. As Osmani frames it, the loop is the harness "but it runs on a timer, it spawns little helpers, and it feeds itself." So harness engineering and loop engineering are nested concerns: you still build the harness, and loop engineering is the layer that puts it in repeated motion. A loop engineer relies on a good harness and adds the control logic — repetition, feedback routing, stopping — that turns one run into a self-running cycle.
Where Coding Loops Fail
Weak validators reward incorrect progress
The most insidious loop failure is a validator that passes the wrong thing. If the check is too weak — tests that are too narrow, a verifier that doesn't actually confirm the requirement — the loop will happily converge on a result that passes the check but misses the point. An agent can make narrow tests pass while breaking the actual user-visible behavior, and a loop with a weak validator will report success on exactly that outcome. This is why experienced loop designers build the verifier carefully (and often separate from the maker): the loop's "done" is only as trustworthy as the validator behind it, and a loop that rewards incorrect progress is worse than no loop, because it ships wrong work confidently and unattended.
Missing stop conditions create unbounded retries
The other classic failure is the absence of a real stopping rule. A loop without a hard cap — a maximum iteration count, a budget limit, an escalation after repeated failure — can retry indefinitely, burning tokens and churning code without converging. Thrashing (repeatedly changing code without making progress) is the visible symptom, usually caused by an unclear goal, a noisy validation signal, or edits that are too large to diagnose. Without explicit stop conditions, a struggling loop doesn't fail gracefully; it spins, and the cost accumulates while no progress is made. Designing stopping conditions as first-class requirements — not afterthoughts — is what keeps a loop bounded, which is why it's a defining part of the loop engineer's job rather than an optional safeguard.
FAQ
What failures show that a coding loop lacks a verifier?
The tell-tale signs are a loop that reports success on work that's actually wrong, or one that never stops. Concretely: changes that pass automated checks but miss the real requirement (because the only "verification" was narrow tests the agent gamed), output the loop confidently calls done that a human review reveals is broken, or a loop that keeps running because nothing can authoritatively say "this is finished." When a loop produces wrong-but-passing results, or can't terminate, it usually means the verification step is missing or too weak — the loop has a maker but no honest check separating "the agent claims it's done" from "it's actually correct." A real verifier, ideally independent of the agent doing the work, is what's absent in those failure patterns.
Who owns a loop when several agents collaborate?
When a loop coordinates multiple agents, ownership becomes a design question the loop engineer has to answer explicitly rather than leave implicit. Someone still has to define the overall goal, decide how work is divided and recombined, set the verification and stopping rules for the system as a whole, and remain accountable for what the loop ships. The agents execute; a human owns the loop's design and its output. In practice that means a loop with several collaborating agents still needs one clear owner of the control logic and the success criteria — the multi-agent structure distributes the work, not the responsibility. The job didn't vanish into the agents; it moved to designing and owning the system that directs them.
When should a loop stop instead of retrying?
A loop should stop when it hits its success condition, when it reaches a predefined failure cap, or when it can't make honest progress. Beyond the obvious success case, the disciplined stopping rules are: a hard iteration or budget ceiling (stop after N attempts regardless), an escalation to a human after repeated failure on the same problem (rather than retrying the same failing action), and a halt when the loop detects it's thrashing without converging. The principle is that retrying only makes sense when each attempt has new information; a loop repeating the same action after the same error isn't progressing, it's spinning, and that's precisely when it should stop and escalate rather than continue. Designing those stop-instead-of-retry conditions is core to keeping a loop safe.
How can repeated agent runs remain auditable?
Auditability comes from treating loop-generated changes like any other change that needs a trail. The practices that keep repeated runs auditable: logging every action and its outcome, having the loop commit through version control (so changes carry history), giving the loop its own scoped identity rather than reusing a human's credentials (so its actions are attributable), and routing its output through the same review and approval flows as other changes. In enterprise settings especially, an unattended actor that commits code and opens pull requests becomes part of change management — so audit trails, least-privilege access, and centralized logs are what make a self-running loop accountable rather than opaque. You design the auditability into the loop; it doesn't come for free.
Conclusion
A loop engineer designs the self-running system around a coding agent — the recursive goal with a checkable success condition, the tools that touch the real environment, the validator that honestly confirms the work, the state that persists across steps, the retries, and the stopping rules. It's an emerging practice that got its name in mid-2026, not a standardized job title or a replacement for prompt engineering: the leverage moved up a layer, from optimizing one input to governing a repeated cycle, but the layers below (prompts, context, the harness) still matter and still get built. The discipline lives or dies on the unglamorous parts — the validator that actually catches wrong work, and the stop conditions that keep a struggling loop from spinning forever. Build those well and a loop becomes a genuine multiplier; skip them and it becomes a confident, expensive way to ship mistakes unattended. As the practitioners who coined the term keep stressing, the point isn't that the work got easier — it's that designing the loop, with judgment, is now where the engineering is.
Related Reading
