ResearchAudio.io

Anthropic's Claude Code Lead Stopped Prompting Claude

Six parts turn one agent run into a system that runs itself.

Boris Cherny runs Claude Code at Anthropic. In June 2026 he said something that would have sounded like a joke a year earlier: "I don't prompt Claude anymore." Loops do the prompting. Writing those loops is the job.

Within a week the idea had a name, a parts list, and a fight attached to it. Here is what loop engineering actually is, which pieces already ship inside the tools you use, and the one number that decides whether any of it holds up.

Where the leverage moved

For roughly two years the interface was one turn at a time. Write a good prompt, paste enough context, read what came back, type the next thing. The agent was a tool and you held it for the whole session.

On June 7, 2026, Peter Steinberger of the OpenClaw project argued the skill had already shifted: stop prompting coding agents, start designing the loops that prompt them. The next day Addy Osmani, a Director at Google Cloud AI, published an essay that gave the practice a name and, more usefully, an anatomy. O'Reilly Radar republished it on June 22.

Osmani's framing: you stop being the person who types the prompts and become the person who designs the thing that types them. A loop is a recursive goal. You define a purpose, and the model iterates until the work is complete. The layer underneath is the harness, the environment a single agent runs inside. Loop engineering sits one floor above it: a harness that runs on a timer, spawns helpers, and feeds itself.

What changed in 2026 is that the parts stopped being yours to maintain. A year ago a loop meant a pile of bash you owned forever. Steinberger's list maps almost exactly onto the Codex app, and nearly the same list onto Claude Code.

The pieces, and where they leak

Automations are the heartbeat. In the Codex app you create one in the Automations tab and pick the project, the prompt, the cadence, and whether it runs on your local checkout or a background worktree. Runs that find something land in a triage inbox; runs that find nothing archive themselves. Claude Code reaches the same place through scheduled tasks and cron, hooks that fire shell commands at points in the agent lifecycle, and GitHub Actions when you want it running after the laptop closes.

Worktrees keep parallel from turning into chaos. A git worktree is a separate working directory on its own branch sharing the same repository history, so one agent's edits physically cannot touch another's checkout. Codex builds this in per thread. Claude Code gives you git worktree, a --worktree flag, and an isolation: worktree setting you attach to a subagent so each helper gets a fresh checkout that cleans itself up.

Skills stop the loop rederiving your project every cycle. Both tools use the same shape: a folder holding an instructions file with metadata, plus optional scripts, references, and assets. Osmani's argument from his intent debt essay applies directly here. An agent starts every session cold and will fill any gap in your intent with a confident guess. Without skills, the loop rebuilds your conventions from zero on every run. With them, runs compound.

Subagents split the maker from the checker. Osmani rates this the most useful structural move in a loop, and it is the one to build first. The model that wrote the code grades its own homework far too generously. A second agent with different instructions, sometimes a different model, catches what the first one talked itself into. Codex defines subagents as config files under .codex/agents/, each with a name, description, instructions, and optional model and reasoning effort. Claude Code does the same under .claude/agents/, with agent teams that pass work between them. Each subagent runs its own model and tool calls, so a second opinion costs real tokens.

The line that separates a loop from a schedule

Two in-session primitives look similar and behave nothing alike. /loop re-runs a prompt on a cadence. /goal keeps working until a condition you wrote is actually true, and after every turn a separate small model checks whether the work is done. The agent that wrote the code is not the agent that grades it. You hand it something like "every test in test/auth passes and lint is clean" and walk away. Codex ships the same primitive under the same name, with pause, resume, and clear.

Both primitives ship in Claude Code and the Codex app. Source: Osmani, Loop Engineering.

What one loop actually looks like

Osmani's example shape: an automation runs every morning against the repo. Its prompt calls a triage skill that reads yesterday's continuous integration failures, the open issues, and recent commits, then writes findings into a markdown file or a Linear board. For each finding worth doing, the thread opens an isolated worktree and sends a subagent to draft the fix. A second subagent reviews that draft against the project skills and the existing tests. Connectors open the pull request and update the ticket. Anything the loop cannot handle lands in the triage inbox for a human.

The state file is the spine. It remembers what got tried, what passed, and what is still open, so tomorrow's run picks up where today stopped. You designed that once. You prompted none of it.

The math that decides whether this holds

A loop running unattended is also a loop making mistakes unattended. Sonar's 2026 State of Code Developer Survey polled more than 1,100 professional developers, and the four numbers below are what a loop is being layered on top of.

Read the second and third bars together. Skepticism is near universal; verification runs at half that rate. Generation scaled and control did not, and a loop is a machine for widening exactly that gap. Osmani cites the 42% figure in his July follow-up and draws the conclusion: creation costs less every quarter, so the scarce resources are review, validation, understanding, and maintenance.

Two studies sharpen the point. In a randomized controlled trial from Anthropic on whether engineers leaning on AI understand code as well as engineers who write it, the AI-assisted group scored 17 percentage points lower on a comprehension quiz, 50 percent against 67 percent. A Wharton study found that when the AI was wrong, nearly three-quarters of people accepted it anyway, and felt more confident than they would have without it.

Osmani names three costs that get sharper as the loop gets better, not easier. Cognitive surrender, taking whatever the loop hands back without forming an opinion. Cognitive debt, the gap between the code that exists and the code you understand, compounding every run. And the orchestration tax: spinning up ten agents takes seconds, but your review bandwidth does not parallelize the same way. Worktrees remove the mechanical collision. You are still the ceiling.

What to take into your own stack

Agents run the inner loop

On July 15, 2026, Osmani published the written version of his AI Engineer World's Fair closing keynote, Own the Outer Loop. It is the follow-up that most summaries skip, and it is the operating model the June essay was missing.

Source: Osmani, Own the Outer Loop, July 15 2026.

He splits the human side into three terms. Quality is the set of checks installed before the system runs loose, and those checks are what produce evidence. Verdict is the production call: ship, block, redirect, narrow the response, add a guardrail, or reject. Answerability is being able to explain why, later, when someone asks.

The practical version: a human does not belong in the inner loop. A human belongs in the constraints loop (what inputs, architectures, and invariants to set), the sampling loop (how much output to review), the audit loop (what evidence to keep), and the ownership loop (which part of the production boundary is yours). Osmani's line for why: "The agent can ship more than you can review."

His prescription is autonomy with back pressure. Not as much autonomy as the agents can possibly exercise, but enough that you can still stop them, regulate them, and check the work. Type checks, tests, hooks, sandbox limits, audit logs, monitors: ordinary engineering signals, kept honest by an agent that keeps emitting them.

Five of the six pieces already ship inside the tools you use. The stop condition does not. That single line is where a loop stops being a productivity question and becomes an accountability one.