Sign in Subscribe
news

Loop Engineering Went Mainstream

Mid-2026, and "loop engineering" is now the phrase you keep seeing 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 age

Sebastien Dubois

Sebastien Dubois

— 3 min read

Canonical version: Loop Engineering Went Mainstream.

Mid-2026, and "loop engineering" is now the phrase you keep seeing 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.

Those posts were the spark. The pile-on since then is the real signal. 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. When the tooling, the curricula, and the "I was doing this before it was cool" videos all show up in the same month, the label has landed.

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 land some punches too. The scheduling layer really is just cron. And as the control-theory crowd points out, one stochastic model reviewing another stochastic model is not automatically a control system; we have plenty of loops and not enough control. What cron never had, though, 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 rest is plumbing.

And the bottleneck actually moved. Claude Opus and Fable now complete tasks with 10+ hour horizons, up from ~1h40 a year ago. Models run long enough and recover reliably enough that the constraint is no longer the model. It's the harness. It's the loop design. Harnesses make a tremendous difference.

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 are spending most of your AI time crafting individual prompts and almost no time thinking about triggers, verifiers, stopping conditions, and sandboxing, you are missing all the fun.

Two things keep that fun honest. First, loops only pay off with a deterministic validation gate. Without one, an agent agreeing with itself on repeat is not autonomous work; it produces wrong answers faster. Second, loops burn 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.

One more idea worth keeping from Ng's letter: the human doesn't leave the loop, the human moves up a loop. The agent handles the minutes-scale build-test cycle. You handle the hours-scale product decisions and the weeks-scale user feedback. Your advantage is context: you know things about your users the AI doesn't. That, not "taste", 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. The pattern is consistent: the builders who get reliable results from agents are the ones who treat loop design as a first-class engineering problem, not a prompt-quality problem.

The label may be new. The lesson is not: design the system, not just the message.

References

About Sébastien

I'm Sébastien Dubois, and I'm on a mission to help knowledge workers escape information overload. After 20+ years in IT and seeing too many brilliant minds drowning in digital chaos, I've decided to help people build systems that actually work. Through the Knowii Community, my courses, products & services and my Website/Newsletter, I share practical and battle-tested systems.

I write about Knowledge Work, Personal Knowledge Management, Note-taking, Lifelong Learning, Personal Organization, Productivity, and more. I also craft lovely digital products and tools.

If you want to follow my work, then become a member and join our community.

Ready to get to the next level?

If you're tired of information overwhelm and ready to build a reliable knowledge system:

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.