Loop Engineering: How AI Development's Mental Model Shifted

Loop Engineering: How AI Development's Mental Model Shifted

When Boris Cherny, who leads Claude Code at Anthropic, said he no longer prompts Claude directly, it was not a casual aside. Cherny described his job as writing loops: autonomous systems that decide when to prompt the model, what to prompt it with, and whether the result meets the bar. That description, offered in early June 2026, became one of the most-discussed quotes in AI developer circles within days.

Peter Steinberger put the same idea more bluntly in a post on June 7, 2026: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." That post crossed more than two million views. The next day, Google engineer Addy Osmani published an essay titled "Loop Engineering" that gave the emerging practice its anatomy and a vocabulary developers could actually build on. The timing was not accidental. By mid-2026, AI coding agents had become capable enough to run multi-step tasks for hours without human intervention. The question was no longer whether the models could do sustained work. The question was whether developers were designing systems that let them.

A Four-Step Progression

Loop engineering did not emerge from nowhere. Practitioners describe it as the latest layer in a progression that has been building for roughly 18 months.

The first layer was prompt engineering: optimizing the text you type, one turn at a time. The second was context engineering, a framing Andrej Karpathy popularized in mid-2025, which shifted focus from the prompt itself to what fills the context window around it. The third was harness engineering, designing the environment in which a single agent runs: what tools it gets, what counts as done, how errors are handled. Loop engineering sits one layer above the harness. Osmani describes it as the harness running on a timer, spawning helpers, and feeding itself.

The practical difference is meaningful. A harness equips a single agent for a single task. A loop decides which tasks to run, when to run them, whether the results are acceptable, and what to do next. The agent forgets each run. The loop, and the state file it maintains outside the conversation, does not.

What a Loop Actually Contains

Osmani's anatomy of a loop has six components. Automations handle scheduling and discovery: a cron job, a Git event, a CI signal, or a simple interval that fires the loop on a cadence. Worktrees provide isolated environments so parallel agents can work without colliding on the same files. Skills encode persistent project knowledge, typically as SKILL.md or AGENTS.md files that agents re-read at the start of each run, keeping a long-running loop from drifting off the original goal.

Connectors, built on the Model Context Protocol, link the loop to external tools: GitHub, Linear, Slack, and similar services. Sub-agents handle the maker-checker split, with one model implementing and a separate one verifying. External state, often as simple as a markdown file or a Linear board, persists across runs so tomorrow's loop resumes where today's stopped.

Both Claude Code and Codex support these components, with different interfaces. In Claude Code, developers use the /loop command to repeat a prompt on a cadence, schedule cron tasks, or configure shell commands that fire at specific points in the agent lifecycle. In Codex, automations run through a dedicated tab where developers pick the project, the prompt, and the frequency; runs that find work queue in a triage inbox, and runs that find nothing archive themselves.

OpenAI reportedly uses automations internally for daily issue triage, CI failure summaries, commit briefings, and bug detection. The /goal command, added to Codex CLI in late April 2026, extends this further: define a verifiable stopping condition and let the agent run until it is met.

Where the Leverage Actually Moved

One reason this conversation spread quickly is that it names something practitioners had already been doing without calling it anything. The vocabulary arrived after the practice. Simon Willison was writing about designing agentic loops in September 2025. What changed in mid-2026, as Osmani notes, is that the primitives stopped being personal bash scripts and started shipping inside the products, which is the moment a pattern stops being a hack and starts being infrastructure.

The more significant shift is what Cherny's statement implies about where a developer's highest-value work now sits. For the past two years, the dominant mental model was interactive: a developer prompts, the agent responds, the developer reads and prompts again. That model put a human on the critical path of every iteration. A well-designed loop removes the developer from the prompt-response cycle and repositions them as the person who designs the cycle itself.

Karpathy described the underlying logic: the goal is to remove yourself as the bottleneck, not to disappear from the process, but to operate one layer up, where decisions shape many runs rather than one at a time.

At enterprise scale, this compounds. The pattern does not stay solitary. Loops reproduce because they are useful, and once there are several they start interacting in ways the single-loop picture never accounts for. The role that emerges is not the person who built the loops but the person who operates them, watching review rates, reading per-loop economics, and deciding which loops to promote or retire.

The Risks That Get Skipped

The conversation around loop engineering has been enthusiastic enough that Osmani's own warnings sometimes get lost in the retelling. He was careful on all three of the main failure modes.

The first is verification. An unattended loop is also an unattended mistake. The model that wrote the code is, in Osmani's framing, too accommodating when grading its own homework. The structural fix is a separate verifier sub-agent, but even with a checker, "done" is a claim rather than a proof. Verification burden stays with the developer, not with the loop.

The second risk is comprehension debt. The faster a loop ships code a developer did not write, the wider the gap between what exists in the repository and what anyone on the team actually understands. The debt is quiet and it accumulates faster as the loop gets smoother. A 2026 study on asynchronous coding agents found that gains came from isolation and verification, not from adding more agents. Georgia Tech's Vibe Security Radar traced more than 70 confirmed CVEs to AI coding tools as of mid-2026, and a separately published audit of 17,022 agent skills found 520 of them leaking credentials, roughly 74% due to debug logging. Loops ship code faster than humans can read it, and an agent optimizing for code that works is not optimizing for code that is safe.

The third risk is what Osmani calls cognitive surrender: accepting whatever the loop returns without judgment, because it keeps arriving looking finished. Greg Brockman has made the broader version of this point: as models improve, the bottleneck on output shifts from the model to the taste of the person directing it. Two developers can run identical loops and get opposite outcomes, one moving faster on work they understand deeply, the other using the loop to avoid understanding the work at all.

Token economics add a practical constraint that applies unevenly. Loops spend autonomously, and each sub-agent runs its own model with its own tool calls. On a consumer plan, an unbounded loop can burn through rate limits or generate a significant invoice quickly. Osmani warns that being "token rich or token poor" makes the same loop a wildly different experience. A loop without a token budget and an explicit stopping condition is not a productivity tool; it is a failure mode waiting for the right weekend to express itself.

What This Means Beyond Developer Tooling

Loop engineering is currently a coding-agent concept, but the underlying shift is not specific to code. The pattern, define a goal, build a system that pursues it autonomously, verify the outputs, and persist state across runs, applies to any domain where work can be specified precisely enough for an agent to take action on it. Research, document review, data analysis, and compliance monitoring all fit the shape.

The more consequential implication is structural. When the leverage in a workflow moves from executing tasks to designing systems that execute tasks, the skills that matter change. Writing a good prompt is now table stakes. Designing a loop that reliably produces good work, at scale, without accumulating errors or comprehension debt, is the skill that is actually scarce.

For enterprise AI teams, the governance questions arrive alongside the capability. Who owns the review bandwidth when loops run overnight? Who reads the per-loop economics? Who decides what a loop is and is not permitted to touch in a production environment? The practitioner community is ahead of the enterprise policy community on all of these questions, which is a gap with a predictable trajectory.

The Tony Hawk Paradox Lens

Loop engineering fits a pattern that I wrote about in my upcoming book "The Tony Hawk Paradox": capabilities that develop first among practitioners with advanced access before becoming the default operating model for a broader population.

The individual developer running loops overnight is the same figure as the skateboarder who masters a trick in the controlled space of a skate park before it reshapes how the sport is understood at large. What Cherny and Osmani are describing is a capability that the most advanced practitioners have already internalized. The building blocks, the scheduling primitives, the skill files, the sub-agent patterns, are now shipping in production tools at Anthropic and OpenAI. The distance between early-adopter practice and standard enterprise workflow has shortened considerably.

The four-stage progression, prompt to context to harness to loop, also follows the pattern. Each prior layer was absorbed rather than discarded. A loop still needs a well-designed prompt inside it. It still needs careful context management. The leverage moved up the stack without erasing what was below it. The next question, consistent with how these progressions tend to work, is what comes after the loop, and how long before that layer starts shipping in the tools too.