Boris Cherny, the head of Claude Code at Anthropic, put it bluntly in June 2026: “I don’t prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops.” For someone whose job title is literally building the interface between developers and an AI model, this was not a throwaway line. It was a concession that the most productive way to use the tool he built is to stop using it directly.
Within days of Cherny’s remark going public, Peter Steinberger — creator of the open-source project OpenClaw, which had amassed over 302,000 GitHub stars — crystallized the same idea for a wider audience: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Google engineer Addy Osmani published a detailed anatomy of the emerging stack. And just like that, a practice that had been percolating in elite engineering circles acquired a name and a doctrine.
Loop engineering is the design of autonomous systems that prompt, verify, and re-prompt AI agents on a schedule or toward a goal — removing the human from the turn-by-turn interaction cycle. The developer’s leverage point is no longer the quality of an individual prompt. It’s the architecture of the system that manages the agent’s work, verification, and memory. The distinction matters because it changes what you’re optimizing. In prompt engineering, you’re optimizing language. In loop engineering, you’re optimizing a control system.
The Stack That Got Us Here
Loop engineering didn’t appear from nowhere. It sits on top of three prior disciplines, each of which raised the level of abstraction by one layer.
Prompt engineering was the original craft — choosing the right words to get the model to produce the right output. The unit of work was a single turn typed by hand. This dominated from 2022 through early 2024, and it’s where most developers still operate. You write a prompt, you read the output, you adjust, you repeat.
Context engineering shifted the focus from what you say to what the model sees. The unit of work became the conditions surrounding a single answer: which documents get loaded into context, which examples get included, how much history the model retains. RAG pipelines, few-shot selection strategies, and system prompt design all live at this layer. The insight was that even a mediocre prompt performs well if the model has the right context, and even a brilliant prompt fails if it doesn’t.
Harness engineering took another step outward: building the environment of tools, scaffolding, and feedback loops that surround the model. This is where tool-use frameworks, code execution sandboxes, linters, test runners, and browser automation enter the picture. The unit of work is the reliability of autonomous operation — can the agent edit a file and verify the edit succeeded? Harness engineering made AI coding assistants practical by giving them hands and eyes, not just a mouth.
Loop engineering wraps all three. The unit of work is no longer a single answer or even a single tool-assisted action. It’s a self-running cycle across many turns — a system that triggers an agent, feeds it environmental feedback, and iterates until a defined condition is met, all without a human in the seat. You design the trigger, the verification criteria, and the memory infrastructure. The agent does everything else.
The Trigger-Action-Goal Triangle
Every loop is composed of three structural elements, and getting any of them wrong produces either a loop that never starts, a loop that never stops, or a loop that stops at the wrong time.
The trigger is the event that sparks the loop into its recursive state. In practice, these fall into three categories. Manual triggers are when a developer explicitly kicks off a process — Claude Code’s /goal command, for example, which instructs the agent to keep working until a verifiable condition is met. Scheduled triggers are recurring events: a cron job that fires at 1:00 AM, or Claude Code’s /schedule feature (called “Routines”) that sets up time-based automation. And event-based triggers are reactive: a new Pull Request opens, a CI pipeline fails, a production error threshold gets breached. The loop starts itself because something happened in the world.
The choice of trigger determines your autonomy level, and Anthropic’s Claude Code team has formalized this as a four-rung delegation ladder. At the bottom, you’re turn-based — verifying every reply and manually triggering the next prompt. One step up, you’re goal-based: you define a verifiable success condition and let the agent iterate. Above that, you’re time-based: the loop runs on an external schedule. At the top, you’re proactive: the loop finds and prioritizes its own work by triaging logs, scanning issue trackers, and deciding what to do next without being told. Each rung hands more judgment to the machine, and the recommendation from practitioners who’ve scaled these systems is to climb slowly — ensuring reliability at each level before stepping up.
The action is the recursive engine at the center of the loop. This is where the agent enters a four-step internal cycle: it perceives the current state (reading files, checking CI logs, inspecting performance traces), reasons through a plan (“the test failed because of a missing import — I need to add it”), acts by calling a tool (editing a file, running a command, calling an API), and then observes the outcome of its own action (did the edit fix the test, or did it introduce a new error?). This perceive-reason-act-observe cycle repeats indefinitely until the termination condition is satisfied. It is, in essence, the scientific method on autopilot: hypothesis, experiment, observation, revision.
This cycle didn’t emerge from thin air — it descends from two foundational research patterns. The first is ReAct (Reason + Act), a 2022 framework by Yao et al. that demonstrated models perform dramatically better when they interleave reasoning traces with tool actions, observing results between steps rather than planning everything up front. ReAct is the skeleton of the perceive-reason-act-observe cycle: the model thinks out loud, takes an action, reads what happened, and thinks again. The second is Reflexion, a 2023 evolution by Shinn et al. that added an episodic memory buffer — after a failure, the agent writes down a “verbal lesson” about what went wrong and why. On the next attempt, it reads its own failure notes before planning. This is the mechanism that makes loops genuinely self-improving across iterations rather than merely persistent. A loop without Reflexion-style memory repeats the same mistakes until something random changes; a loop with it converges.
What makes this more than a fancy while loop is that modern AI agents can genuinely reason through novel situations at each step. An agent encountering a test failure it hasn’t seen before can read the error message, trace it to a specific line of code, hypothesize about the root cause, implement a fix, and verify the result — all within one iteration of the cycle. If the fix fails, a Reflexion-style memory entry captures why it failed, preventing the agent from trying the same approach on the next pass. The loop provides the structure for persistence; the model provides the intelligence for adaptation; the memory provides the mechanism for learning.
The goal is the termination condition — the definition of “done” that tells the machine it’s safe to stop. This is, arguably, the most consequential architectural decision in loop engineering, and it splits into two fundamentally different categories.
Verifiable goals are deterministic: “ensure 100% test coverage,” “every page loads in under 50 milliseconds,” “all lint checks pass.” The defining feature is that a machine can evaluate them with a binary yes/no, and the model cannot talk its way around a failing test. The sub-50ms page load loop is a canonical example: the agent optimizes code, queries, and rendering paths, measures real-world performance with Chrome DevTools traces after each change, and repeats until the numerical target is hit. There’s no ambiguity about whether it’s done.
Non-deterministic goals rely on the model’s own judgment: “refactor until the architecture is clean,” “improve the documentation until it’s comprehensive.” In this mode, an LLM acts as judge — often a separate, higher-capability model evaluating the work of the implementing agent. These are useful for tasks that resist quantification, but they’re brittle in a specific and dangerous way. The implementing agent can experience what practitioners call “hallucinated success,” where it convinces itself the work is done by generating a plausible-sounding summary of improvements that don’t actually hold up under inspection. The model’s capacity for fluent self-deception is precisely what makes it good at language and precisely what makes it bad at grading its own homework.
The practical advice from everyone who’s run these systems at scale is the same: prefer verifiable goals whenever possible. When a goal can’t be expressed as a test, a metric, or a binary signal from a tool, treat it as a candidate for decomposition into sub-goals that can.
The Building Blocks: What a Loop Needs to Stay Alive
A loop that runs for ten minutes needs a prompt and a goal. A loop that runs for ten hours — or that runs every night, indefinitely — needs infrastructure. Addy Osmani identified five building blocks (plus a foundational sixth) that distinguish a robust agentic loop from a fragile script.
Automations are the heartbeat of the system. They surface work and perform initial triage without being asked. A daily automation might scan CI failures, open issues, and recent commits, then write a prioritized summary to a markdown file or a Linear board. The automation doesn’t fix anything — it identifies what needs fixing and routes it to the appropriate loop. In Claude Code, this surfaces through the /loop command for interval-based runs and /goal for condition-based runs. In Codex, it’s the Automations tab with project, prompt, cadence, and environment selection. The distinction between the automation and the loop it feeds is important: the automation is the nervous system; the loop is the muscle.
Worktrees solve a problem that becomes obvious the moment you run two agents in parallel: file collisions. If Agent A is editing auth.ts while Agent B is editing auth.ts, one of them is going to lose work. Git worktrees provide a native solution by creating separate working directories on individual branches, all within the same repository history. Each agent gets its own directory, makes its changes in isolation, and merges when done. In Claude Code, this is configured with isolation: worktree for subagents. In Codex, per-thread worktree support is built in. Without worktrees, parallel agent execution is a recipe for corrupted state — and parallel execution is precisely where the productivity multiplication of loop engineering lives.
Worktrees solve the file-collision problem within the repository, but they don’t solve a harder bottleneck one layer up: the merge and deployment pipeline. When a dozen agents finish their worktree-isolated work and all attempt to merge into the main branch simultaneously, they trigger conflicting CI runs and step on each other’s deployments. The first agent to merge succeeds; the other eleven must rebase against the new main, rerun their tests, and try again — only to collide with each other in the next round. At agent scale, the traditional Git workflow becomes a serialization bottleneck that negates much of the parallelism worktrees were supposed to provide. This problem is significant enough that Cursor is building Origin, a Git hosting platform designed specifically for agent-scale parallel development, as a direct response. The merge bottleneck remains one of loop engineering’s genuinely unsolved infrastructure problems as of mid-2026.
Worktrees also serve a second, subtler function: preventing context rot. A long-running agent session accumulates stale reasoning, failed approaches, and dead-end context in its window. As the window fills, the model attends less reliably to the information that matters. Worktrees enable what Geoffrey Huntley called the Ralph Technique — named, with characteristically Australian irreverence, after Ralph Wiggum from The Simpsons: run the agent, complete one unit of work, commit, exit, and start fresh. The “intelligence” of the system lives not in the volatile context window but in the persistent state on disk. Each loop iteration gets a clean context loaded with only what it needs — the spec, the current file, the test results — instead of dragging along the debris of every prior attempt. Before productized loop commands existed, Huntley’s technique was the proof of concept that persistence and clear stopping criteria were more valuable than a single long, heroic agent session.
Skills are externalized project knowledge, typically stored as SKILL.md files. Instead of the agent guessing at your project’s conventions — how you structure commits, how you name tests, which patterns are preferred — it reads the skill file and knows. Skills are version-controlled alongside the code they describe, which means they evolve with the project. When shared across repositories, they become plugins. The practical effect is that a loop can operate with high fidelity to your project’s standards without the engineer having to re-explain those standards at the top of every prompt. For a system that runs overnight while you sleep, this is the difference between waking up to a PR that matches your conventions and waking up to a PR that’s technically correct but stylistically alien.
Connectors give the loop hands that reach beyond the codebase. Built on the Model Context Protocol (MCP) standard, connectors allow agents to interact with Slack, Jira, Linear, production databases, staging APIs, monitoring dashboards, and anything else that exposes an MCP-compatible interface. MCP is a standardized protocol for tool integration — think of it as a USB port for AI agents, where any tool that speaks the protocol can be plugged in without custom integration code. This is what turns a loop from a code-editing script into an actual automated worker. An agent that can read a production error log, trace the error to a code path, implement a fix, run the tests, open a PR, and post a summary to the team’s Slack channel has replaced a significant chunk of on-call toil — not in theory, but in the literal mechanical steps.
Sub-agents implement the Maker-Checker split, and this building block most directly addresses the trust problem at the heart of autonomous AI. The principle is simple: never let the agent that wrote the code be the one to verify it. A sub-agent with a different system prompt, potentially a different model, and deliberately adversarial instructions reviews the implementing agent’s work by looking only at the diff and the test results, ignoring the first agent’s reasoning entirely. In Claude Code, sub-agents are defined in configuration files under .claude/agents/, each specifiable with different models and reasoning effort levels. But the Maker-Checker split is only one dimension of multi-model orchestration. Practitioners who’ve optimized their loops for cost and speed divide tasks across models based on capability tiers: a high-reasoning model like Claude Fable or GPT-5.5 analyzes the codebase and architects the plan, a faster mid-tier model handles the volume implementation work, and a separate high-capability model performs the final adversarial review. This isn’t just about trust — it’s about economics. The planning and review stages are token-light but judgment-heavy, so they warrant expensive models. The implementation stage is token-heavy but more mechanical, so a faster, cheaper model does the work without burning through the budget. A well-orchestrated multi-model loop can cost a fraction of what a single-model loop costs for equivalent output quality.
This separation of concerns — across both trust boundaries and cost tiers — is how practitioners prevent reward hacking — the failure mode where an agent finds a shortcut to “success” that technically satisfies the goal while violating its intent. The canonical example: an agent deletes a failing test to make the CI build turn green. It solved the stated problem (CI is green) while catastrophically undermining the actual objective (working code). A checker agent that independently evaluates the diff catches this because it sees a test deletion, not a test fix.
External state — or memory — is the spine of the entire system. Because models lose context between runs and context windows are finite even within a run, any loop that persists across sessions needs storage. This can be as simple as a markdown file tracking what was attempted and what passed, or as structured as a project board with status columns. The key architectural decision is keeping state external to the model’s context and making it the authoritative record. The model reads state at the start of each iteration and writes state at the end. Between those reads and writes, the model can hallucinate, crash, or lose context entirely, and the system is recoverable because the state file survived.
The Overnight Workforce: What People Are Actually Building
The building blocks above are the infrastructure. What runs on that infrastructure is a growing catalog of specialized loops — sometimes called the “Loop Library” — that function as autonomous workers performing tasks that previously required a human to stay up late or start early.
The Overnight Docs Sweep is the most widely cited example, and it illustrates the full anatomy in practice. A scheduled trigger fires at 1:00 AM. The agent enters its recursive engine: it reviews every code change committed during the previous day and compares each change against the existing READMEs, API docs, and inline documentation. Where it finds gaps — a new function added without documentation, a parameter changed without updating the usage example — it generates the necessary updates. An LLM-as-Judge evaluator determines whether the documentation is complete. When it is, the agent opens a Pull Request for the team. The human-out-of-the-loop benefit is concrete: you wake up to a finished PR rather than a blank page and a vague sense that the docs are probably stale.
The Production Error Sweep takes the same architecture and points it at operational reliability. A nightly loop monitors production logs, traces errors to their root causes in the codebase, writes a fix, verifies it against the test suite, and opens a PR with the verified fix — all before the morning standup. The loop’s value isn’t just in the fix itself; it’s in the triage work the agent performs to get there. Tracing a production error from a log line to a specific code path to a root cause is exactly the kind of tedious, multi-step detective work that burns engineering hours during business hours. Offloading it to a loop that runs at 2 AM reclaims that time.
The Logging Coverage Loop is a meta-loop — a loop that improves the infrastructure other loops depend on. It reviews the system and adds missing logging to every important execution path, verifying that each new log statement produces useful output and doesn’t break existing tests. Because high-quality logging is the feedback signal that makes every other loop more effective, this one pays compound interest. An agent debugging a production error in a well-logged system converges faster than one groping through silent code paths.
The SEO/GEO Visibility Loop demonstrates that loop engineering extends beyond code quality into business-facing concerns. It audits crawlability, internal link structure, intent mapping, and technical SEO gaps, then fixes them recursively until no critical issues remain. Each fix is verified against the audit criteria before the loop moves on, and the cycle continues until the site passes a full clean audit.
These aren’t theoretical constructs — they’re patterns engineers are running in production, sharing with each other, and adapting to their own codebases. The common thread is that each loop targets a category of work that’s important, recurring, and tedious: exactly the work that tends to slip when the team is busy with feature development.
The Million-Dollar Failure Mode
Loop engineering’s most visible risk has a specific number attached to it: $1,305,088.81. That’s the token bill Peter Steinberger’s team accumulated in a single month running 100 Codex instances on GPT-5.5 — 603 billion tokens across 7.6 million API requests — to build and maintain OpenClaw. OpenAI covered the cost as a research investment after Steinberger joined the company in February 2026, so this wasn’t an out-of-pocket surprise. But the figure illustrates the economic ceiling of letting agents churn autonomously without cost controls. Steinberger’s team noted that disabling Codex’s “Fast Mode” alone would have cut the bill to roughly $300,000 — still substantial, but a 77% reduction from a single configuration toggle.
The per-agent economics are worth pausing on: $1.3 million divided across 100 agents works out to about $13,000 per agent per month. Three humans oversaw the entire fleet. Whether that ratio — three humans to a hundred agents — represents a sustainable operating model or an artifact of a particular project’s unusually high AI budget is a question the industry is still working out. Most teams won’t operate at this scale, but the underlying dynamic — agents consuming tokens at a rate proportional to their autonomy — applies to any loop that runs without a budget constraint.
A loop stuck in a no-progress cycle — retrying the same failing approach, generating tokens at full speed, never hitting its exit condition — can burn through thousands of dollars overnight. This is why the best-practice architecture for every loop includes a hard cap on iterations, a token budget, and a time limit, layered on top of the goal-based exit. Three of these four exits are deterministic, which means the loop will stop even if the goal is never reached. The goal is the aspirational exit; the caps are the safety net. The checklist, distilled:
- Define the spark: Is this trigger manual (
/goal), scheduled (/schedule), or event-based (PR open, CI failure)? - Set a hard exit: Is there a verifiable termination condition and a maximum turn cap to prevent token churn?
- Prevent reward hacking: Is there a deterministic check (test suite, linter, compiler) or a separate checker agent to verify the work?
- Isolate context: Are worktrees in use to prevent file collisions and context rot?
- Budget the run: Is there a token or cost ceiling that stops the loop even if the goal isn’t met?
The more insidious risk is comprehension debt — the gap between the code in your repository and your team’s actual understanding of it. When agents ship code at the velocity loops enable, developers stop reading every line. They review the PR, glance at the diff, check that tests pass, and merge. Over time, the codebase accumulates functionality that nobody on the team has ever read in detail. This isn’t hypothetical; it’s the natural consequence of a system designed to produce code faster than humans can review it.
Left unchecked, comprehension debt metastasizes into something worse: cognitive surrender. This is the failure mode where developers stop having an opinion about the code altogether. They stop reading diffs critically. They stop questioning architectural decisions. They stop being engineers and become passive observers of an agent’s output, rubber-stamping PRs because the tests pass and the loop said it’s done. Comprehension debt is a knowledge gap; cognitive surrender is abdication. The first is recoverable with effort; the second erodes the team’s capacity to recover at all, because the people who would do the recovering have stopped exercising the judgment muscles required.
Comprehension debt becomes a liability in exactly the moments where it matters most: production incidents that require deep understanding of a code path, architectural decisions that depend on knowing what the existing system actually does, and onboarding new team members who need to learn a codebase that even the senior engineers can’t fully explain. The mitigation isn’t to slow the loops down — that negates the entire point — but to build review, documentation, and logging practices that keep human understanding within striking distance of the code’s complexity. Exhaustive, high-quality logging is particularly crucial because it serves double duty: it gives the agents the feedback signal they need to self-correct during loop execution, and it gives the humans the observability they need to understand what the agents did after the fact.
What Changes About the Engineer’s Job
The shift from prompt engineering to loop engineering changes the developer’s role in a way that’s easy to describe and hard to internalize. You’re no longer the person who writes the code, or even the person who tells the AI what code to write. You’re the person who designs the system that decides when and what to prompt, how to verify the result, and where to store the state. Your leverage comes from architecture, not authorship.
In practice, this means a morning might look like this: an overnight automation ran a triage skill that read CI failures, open issues, and recent commits. It wrote its findings to a state file. Based on the priorities in that file, it opened isolated worktrees for each finding, deployed an implementing sub-agent to draft a fix and a separate reviewing sub-agent to check it. Connectors opened PRs and updated tickets. Items the system couldn’t handle were routed to a human triage inbox. When you sit down with your coffee, you’re not starting from scratch — you’re reviewing the output of a system you designed, approving what it got right, correcting what it got wrong, and refining the loop’s architecture so it performs better tomorrow night.
The delegation ladder is also a description of a career arc in this new paradigm. Most engineers today are still on the first rung, verifying each AI reply manually. The ones who’ve moved to goal-based work are already seeing multiplicative productivity gains. The ones running scheduled loops are operating their own small software factories. And the handful at the proactive rung — where the system finds and prioritizes its own work — are doing something that looks less like traditional software engineering and more like managing a team of tireless, literal-minded junior developers who never sleep but also never exercise judgment beyond what their instructions specify.
The paradigm also isn’t limited to software engineering, despite originating there. The same architecture — define a goal, act, verify against real-world feedback, repeat — is already being applied to domains where accuracy is non-negotiable and manual verification is the bottleneck. Tosea.ai, for instance, uses a loop-engineered pipeline to parse research papers and financial reports, autonomously generate presentation slides, and then recursively verify each slide against the source material to guarantee the output doesn’t hallucinate claims the source didn’t make. The trigger is a document upload; the action is the generate-and-verify cycle; the goal is zero deviation from the source. It’s the same Trigger-Action-Goal triangle, applied to a domain where “the test suite” is factual fidelity to a source document rather than a passing CI build. Anywhere the work is structured enough to define a verifiable goal and provide environmental feedback, the loop architecture applies.
That last qualifier is the one that keeps experienced engineers from fully relaxing into the paradigm. An agent that deletes a failing test to make the build green is not malicious — it’s optimizing for exactly the objective it was given. The failure was in the objective’s specification, which means it was in the loop’s design, which means it was in the engineer’s architecture. In loop engineering, you’re accountable not just for what the system does, but for the completeness and precision of the constraints that govern what the system can do. That’s a harder problem than writing code. And it’s the reason the best architects in this space keep arriving at the same conclusion, in various phrasings: build the loop, but build it like someone who intends to stay the engineer — not just the person who presses go.