Loop engineering: why agent loops beat prompt engineering

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and kind of figuring out what to do. My job is to write loops." That’s Boris Cherny who created Claude Code at Anthropic describing how he writes software in June 2026.

Days later, Peter Steinberger – creator of OpenClaw, founder of PSPDFKit, now at OpenAI – told engineers "you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Within the week, Addy Osmani, who spent 14 years at Google leading developer experience across Chrome and most recently as a Director at Google Cloud AI, gave the practice a name: loop engineering.

So now we have loop engineering as a practice. There’s a lot of validity to this approach when coding with AI agents, but a lot of what makes loop engineering work comes from decades-old practices.

From prompt engineering to loop engineering

Prompt engineering was the new AI skill of 2023–2025: write a good instruction, share enough context, read the code, type the next thing.

Now you wire those prompts into loops, so agents keep working without you, check their own output, and pick up where the last run stopped.

Osmani, who named it, defines the practice like this: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." A loop, in his framing, is a recursive goal. You state the purpose and the agent iterates until it's met.

• Prompt engineering is the words you use to describe what you want done
• Context engineering is everything the model sees: documents, history, the tools in reach. Shopify CEO Tobi Lütke's term, amplified by Andrej Karpathy in June 2025
• Harness engineering is the environment a single agent runs inside. HashiCorp co-founder Mitchell Hashimoto named it in February 2026
• Loop engineering sits on top: a small system that finds work, hands it out, checks the result, records what's done, and decides what's next

Instead of typing prompts over and over, you build the thing that types them. Your job becomes reviewing what comes back.

Graph engineering is the next layer of loop engineering

Six weeks after loop engineering got its name, Steinberger asked whether we were "still talking loops or did we shift to graphs yet?” Within hours Hamel Husain published "Loop engineering is dead. Enter graph engineering."

But loop engineering isn’t dead. LangChain, the vendor with the most to gain from declaring loops obsolete, described the relationship accurately: "Loop engineering isn't an alternative to graphs, so much as a simple version of them."

David Khourshid, who built XState, said it in fewer words. A loop is a directed, cyclic graph. One node, pointing back at itself.

Graph engineering draws the other nodes. You name each state the work can be in, wire the transitions between them, and decide what happens at every one. Nodes do the work, and a node can be deterministic code, a single model call, or a whole agent running its own internal loop. Edges decide what comes next, some fixed, some conditional on what the last node returned.

It's a state machine, an idea older than most of the engineers now rediscovering it.

The 5 building blocks of an agent loop

Osmani breaks the anatomy into five primitives plus memory. A year ago you built these from custom bash scripts and maintained them forever. Now Claude Code and OpenAI's Codex ship them natively. Every tool uses its own names for the same five things.

• Automations are the heartbeat. They run daily issue triage, CI-failure summaries, and commit briefings without you. Codex has automations; Claude Code has Routines, plus /goal, a run-until-done mode where a separate, faster model checks whether your stopping condition is actually true
• Worktrees keep parallel agents out of each other's files, and the collision rate is measurable. Across 33,596 agent PRs, researchers found a 19.8% merge conflict rate between same-agent PRs and 41.7% between different ones
• Skills write your project knowledge down once. An agent starts every session cold and fills gaps with a confident guess. A SKILL.md file holds the conventions, the build steps, and the "we don't do it that way because of that one incident" context it would otherwise invent
• Connectors and plugins reach your real tools. Built on internal connectors or Model Context Protocol (MCP), they're 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 when CI goes green
• Sub-agents split the maker from the checker. The model that wrote the code is too nice grading its own homework; a second agent with different instructions catches what the first one talked itself into

The sixth piece is memory: a markdown file, database, or Obsidian brain that lives outside any single conversation and holds what's done and what's next.

What agent loops look like in production at Cloudflare and Stripe 

Cloudflare built one for code review and runs it company-wide. Their system runs up to seven specialized agents at every merge request, covering security, performance, code quality, docs, and compliance. A coordinator then dedupes the findings and filters false positives before anything reaches a human.

Over 30 days it ran 131,246 reviews across 48,095 merge requests in 5,169 repositories, at $1.19 per review and a median of 3 minutes 39 seconds. Engineers hit the "break glass" override on 0.6% of merge requests.

Stripe runs the maker side at similar scale, and the load-bearing part of engineering manager Cameron Bernhardt's description is the last four words: "Minions have progressed from concept to generating over a thousand pull requests per week. All code is human-reviewed."

New problems with loop engineering

Here's what most loop-engineering posts skip: three problems get sharper as your loops get better.

• Verification: A loop running unattended is also a loop making mistakes unattended. The maker/checker split makes "it's done" mean something, but done is a claim, not a proof, and the cost shows up in review depth. Anthropic, where Claude now writes roughly 80% of merged code, reports the share of PRs getting substantive review comments climbed from 16% to 54% – they more than tripled how hard they look as agent volume rose. More of what agents produce also gets thrown away: across 220,612 closed PRs, agent-authored PRs merged at 64–68% against 84–86% for humans.
• Token costs: Every sub-agent burns its own model and tool calls, and a loop on a timer spends money while you sleep. Anthropic's engineering team measured multi-agent systems using roughly 15x the tokens of a single chat. Uber burned its entire 2026 AI budget in four months and now caps spend at $1,500 per employee per month per tool. President and COO Andrew Macdonald named the problem precisely: "It's very hard to draw a line between one of those stats and 'okay, now we're actually producing like 25% more useful consumer features.' That link is not there yet."
• Comprehension debt: Osmani's term for the widening gap between how much code exists and how much any human still understands. His sharpest version: a junior engineer can now generate code faster than a senior engineer can critically audit it. GitLab's 2026 research puts numbers on it – 85% of developers say AI moved the bottleneck from writing code to reviewing it, and 43% can't reliably tell which code in their own repo an agent wrote. Meanwhile only 33% of developers trust the accuracy of AI output, and 46% now actively distrust it.

The case against going deep on loop engineering

Not everyone thinks this is a new paradigm. Gergely Orosz surveyed his readers about loops in July, came away unconvinced, and asked in his subhead whether this is a "here today, gone tomorrow" trend.

Four of his objections land:

• Loop engineering isn’t new. What his readers described as loops were mostly triggers and cron jobs, the same scheduled work engineers have been automating for thirty years. Oded Messer, a director of engineering, said it plainly: "Sometimes it feels like AI enthusiasts forgot automation was a thing before LLMs"
• Practitioners quit. Agents drift over long runs, and developers who stayed in the loop themselves got better results
• The economics break outside the labs. At companies paying API prices per token instead of working inside a flat-rate plan, loop engineering gets expensive fast
• The scaffolding may depreciate. Max Kanat-Alexander, an executive distinguished engineer at LinkedIn, thinks the loop was a temporary hack while the harnesses caught up – something you'll soon do from one prompt because the tool handles the looping itself

He's right about the mechanics. Cron, webhooks, and job schedulers predate the term by decades, and Zapier has been wiring triggers together since 2011. What changed is what sits inside the scheduled job: a step that can read a codebase, decide what to do next, and write the code. Your 2019 cron job could not do that.

Where engineering leaders should start

Start with one loop on one recurring chore your team already resents – issue triage, flaky-test hunting, CI-failure summaries.

Then:

• Write one skill that captures the project context
• Schedule one automation
• Split one maker from one checker
• Keep state in a markdown file
• Run it two weeks and measure what it caught, what it broke, and what it cost in tokens

That single loop will teach you more about your team's readiness than any vendor deck.

Every engineering org using AI agents for coding is already dealing with this. The only question is whether you design your loops deliberately or inherit whatever gets wired up ad hoc.