Loop Engineering Went Mainstream

Canonical version: Loop Engineering Went Mainstream.

In mid-2026, "loop engineering" became a common phrase in AI conversations. Boris Cherny from Anthropic (creator of Claude Code) said it directly: "I don't prompt Claude anymore. My job is to create loops." Peter Steinberger made the same point in his own words: stop prompting coding agents, design the loops that prompt them. Jensen Huang said something nearly identical.

Others followed. Andrew Ng dedicated a letter of The Batch to his three product-development loops. A 19-page Google paper on the topic pulled 670k views in a day on X. Matt Van Horn's explainer did 3.6M views and spawned a sequel cataloging the fifteen loops people actually run. GitHub repos now ship CLIs that score your "Loop Readiness". Kent C. Dodds published a video pointing out he's been doing this naturally for months.

So is this a real evolution or just hype?

I think it's both. What Simon Willison described as "something that runs tools in a loop to achieve a goal" has been the working definition for years. If your reaction to "loop engineering" is "isn't this just agentic design with a new name," you are not wrong. The skeptics make fair points too. The scheduling layer really is just cron. And as people with a control-theory background point out, one stochastic model reviewing another stochastic model is not automatically a control system. What cron never had is a decision-maker inside the loop: something that reads the state, acts, checks whether it worked, and decides whether to keep going. That part is new; the scheduling around it isn't.

Claude Opus and Fable now complete tasks with 10+ hour horizons, up from ~1h40 a year ago. With models that run that long and recover from errors, the harness and the loop design limit the results more than the model does.

Context Engineering took over from prompt engineering a while ago. Loop engineering is the next layer up: the trigger, the tools, the verifier, the stopping condition, the budget. Context still matters, but the way the harness drives the models and tools is where results get decided now. If you spend most of your AI time crafting individual prompts and almost no time on triggers, verifiers, stopping conditions, and sandboxing, move some of that time to the loop.

Loops only pay off with a deterministic validation gate. Without one, an agent that keeps agreeing with itself produces wrong answers faster. Loops also cost money: Uber capped its engineers at $1,500 per AI tool per month after burning through its annual budget in four months. Every loop needs a verifier and a budget. And if human review is already your bottleneck, adding a loop just floods the queue.

Ng's letter also argues that the human moves up a loop rather than leaving it. The agent handles the minutes-scale build-test cycle. You handle the hours-scale product decisions and the weeks-scale user feedback. According to Ng, your advantage is context: you know things about your users the AI doesn't, and that is why you stay in the system.

I have been tracking this through Agentic loops, Harness Engineering, and AI Agent Harnesses (MoC) for a while now. What I've seen so far: the builders who get reliable results from agents treat loop design as an engineering problem rather than a prompt-quality problem.

Update (September 2026): studies and tooling

By September 2026, three papers had measured how agent loops are built and how they fail.

A study published on arXiv in August mined 36,710 open-source repositories and confirmed autonomous agent loops in 217 of them. Claude Code runs 87% of those, and almost all of them are triggered by GitHub Actions. The study found no machine-checkable stop condition in the standard vocabulary, no verifier subagent referenced anywhere, no committed budget or cost log, and committed state files in 2 repositories out of 36,645.

Two other papers measured the risks. One found 68 confirmed infinite agentic loops across 47 agent projects (loops with no effective bound, burning money and repeating side effects). Another found exploitable verifiers in 16% of agent benchmark tasks. So even when you do write a verifier, the agent may find a way around it. Red-team your checks before you trust them.

The tools added loop features in the meantime. Codex has /goal, Claude Code has /goal, /loop, /schedule, dynamic workflows and now Claude Code Projects, and Cursor's Ralph plugin ships a detector for loops that spin without making progress. Loops also got cheaper to run: Claude Opus 5.5 finishes command-line tasks with about 40% fewer calls, and decision models like Jev can answer the small in-loop questions ("is the agent stuck?") in milliseconds.

My conclusion hasn't changed, and the August study backs it: a loop needs a committed verifier and a budget, not only a trigger and a prompt.

The full picture (studies, tooling, and the critique) is in my Loop Engineering note.

References


About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe