In early June 2026, two of the most senior AI engineers in the world said the same strange thing, in the same week, in almost the same words.

Peter Steinberger — creator of OpenClaw, now at OpenAI — fired first:

You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

The next day, Boris Cherny — head of Claude Code at Anthropic — said the same thing a different way:

I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.

Two of the most senior engineers alive. One message. Most people read it and thought one thing: what does that actually mean?

Mogu real talk:

First, some context that gives this weight: Steinberger isn’t just talking. In May he posted a screenshot of an OpenAI API bill — $1.3 million in 30 days, 7.6 billion tokens, 100 coding agents running (Tom’s Hardware covered it). When a guy can describe $1.3M of spend with the verb “running loops,” his “my job is to write loops” isn’t a metaphor. It’s literal. Remember that number — we’ll come back to it when we hit the cost section.

The Old Way vs The New Way

For the last two years, working with an agent looked like this: you type a prompt, the agent replies, you review it, you fix what’s wrong, you prompt again. Notice something — in that flow, you are the loop. You’re the one going around and around: look, fix, send, look again.

The new way hands that loop off. Instead of telling an agent to “build a landing page” and babysitting every step, you set up a loop that handles discovery, planning, the work, the checking, and the fixing — until the goal is met.

The difference in one line: a prompt gives the agent an instruction. A loop gives the agent a job.

Mogu highlights:

This thesis isn’t new. Simon Willison said almost exactly this back in February — the new skill isn’t writing prompts, it’s “designing agentic loops” that brute-force their way through any coding problem (gu-log translated it here). The value of this piece isn’t being first — it’s pulling scattered ideas into one clean map. And the map is genuinely good… good enough that a sponsored ad is sewn into the middle of it, and you almost don’t notice the seam.

What Loop Engineering Actually Is

Strip the jargon and loop engineering is this: designing repeatable feedback cycles that take an AI agent from “attempt” to “verified result,” without a human in the loop the whole time.

It isn’t a feature of one specific tool. Almost any agent harness can run it — it’s a question of how you wire it up. The simplest version is one agent working on itself:

  • Research a round
  • Draft something
  • Check the draft against the goal
  • Fix the weak parts
  • Run the whole cycle again, until the work clears the bar

Simple or complex, every loop moves through the same five stages: Discover → Plan → Execute → Verify → Iterate. Pass verification → ship. Fail → loop again. That’s the whole idea. Everything else is just how you build that cycle properly.

Mogu 's hot take:

If those five stages feel oddly familiar — yeah, it’s because gu-log itself runs this way. This blog has a four-judge scoring system: every post gets scored, anything under 8 gets sent to a rewriter, re-scored, up to three rounds, and only then reaches the homepage. Discover → Plan → Execute → Verify → Iterate, not a word missing. So the stuff below isn’t theory to me — it’s the daily commute (⁠￣⁠▽⁠￣⁠)

One Agent vs A Fleet

There are two scales of looping.

Single-agent loop: one agent runs the whole cycle alone. Picture a person redoing their own draft — it discovers what’s needed, plans, executes, verifies quality, iterates if something’s off. Good for tight scope, simple goals, focused tasks. One brain, one loop, gets better on its own.

Fleet loop: the bigger version. You hand an orchestrator agent a goal. It breaks the goal into pieces, hands each to a specialist agent, and the specialists hand smaller jobs to their own subagents. The whole tree loops through discovery, planning, execution, verification, until the goal is met. Like a whole team running a project end to end:

  • The orchestrator owns the goal
  • Specialists own the steps
  • Subagents do the narrow work
  • Eval gates make sure the output isn’t slop

The difference in one line: a single-agent loop is one person redoing their draft; a fleet loop is a whole team running a project.

Open Loops vs Closed Loops: The Line to Understand in 2026

If you remember one distinction from this whole piece, remember this one.

Open loop: exploratory. Lots of room to move. You give the agent a goal and let it roam — it can try different paths, discover things, build something you never fully specced. This is the exciting end, and it’s what Steinberger and friends are doing at OpenAI. The catch? It burns tokens until your eyes water. For the 90% of people without an unlimited API budget, open looping isn’t practical yet. And pointed at a project with loose standards, it becomes a slop machine — fast, messy, expensive.

Closed loop: bounded. A human designs the end-to-end path first — a clear goal, defined steps, an evaluation at each step, a point where it stops or hands back to you. The agents still loop, but inside a framework you built. It gets better every round because each pass feeds the next; it runs on a normal budget because the path is tight; the standard keeps it honest. Without a quality gate, AI drifts. With one, AI improves.

Which one? Start closed. Build a tight, reliable system first, and once the quality gates are in place, open it up.

Mogu , seriously:

This is the most useful section in the whole piece, and the one I’ll happily co-sign. “Closed before open” isn’t timidity — it’s just engineering common sense. You wouldn’t point a brand-new, untested service straight at auto-deploy to production. Same here: an open loop with no eval gate is an intern who never gets tired, never sleeps, and will confidently wreck your entire codebase while you’re on vacation. gu-log’s four-judge system is a closed loop precisely because of that “no homepage under 8” wall — the wall is there, so no matter how the agent runs wild, it stays outside the door.

The Six Building Blocks of a Good Loop

Five stages is the concept. But what do you actually build to make a loop run? Six things. And Claude Code and Codex both ship all six now.

1. Automations (/loop, /goal): the heartbeat. This is what kicks Discover into motion. Define a prompt, a cadence, a goal, and the loop runs on schedule and brings findings to you — no more circling back to check yourself. Give it a condition like “all tests under test/auth pass and lint is clean,” then walk away.

2. Worktrees (git worktree): lets multiple Execute stages run in parallel without smashing each other. The moment you run more than one agent, files start colliding — two agents editing one file is the same disaster as two engineers committing the same lines without talking. A git worktree gives each agent its own isolated directory, its own branch, the same repo history, zero collisions.

3. Skills: makes Discover fast — the agent knows your project before it starts. A skill is a folder with a SKILL.md inside: project conventions, build steps, and that one line, “we don’t do it this way because of that incident.” Written once, read every round. Without skills, the loop re-derives your whole project from zero each cycle. With them, it compounds.

4. Plugins and connectors: makes Execute real — the loop acts in your actual environment, not just the filesystem. A loop that can only see files is a tiny loop. Connectors (built on MCP) let the agent read your issue tracker, query a database, hit a staging API, drop a message in Slack. It’s the difference between an agent that says “here’s the fix” and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green — by itself.

5. Subagents (split the checker out): makes Verify honest — the checker is never the maker. The model that wrote the code grades its own homework too kindly. A second agent with different instructions — sometimes a different model — catches what the first one talked itself into. The split that works: one agent explores, one implements, one verifies against the spec.

6. Memory (an external memory file): the spine of the whole thing. A markdown file, a Linear board, anything that lives outside a single conversation. The model forgets everything between rounds — the repo doesn’t. The memory file holds what was tried, what passed, what’s still open. Tomorrow morning the loop picks up where today stopped. It sounds too simple to matter; every long-running loop depends on it.

Mogu going off-topic:

Notice all six are already built into Claude Code and Codex — you’re not building wheels here. Automations are /loop and /goal, worktrees are git’s built-in worktree, skills are a SKILL.md folder, connectors are MCP, subagents are the Task tool, memory is a .md file. So “loop engineering is hard” is a little misleading: the hard part isn’t the tools, it’s the design — knowing which block goes at which step, where the quality gate sits. The tools are already free. What’s missing is judgment.

Wait — First, The Blocker Nobody Mentions

All of that sounds great, until reality shows up: loops are beautiful until the bill arrives.

One agent loop on a medium coding task: 50,000–200,000 tokens. A fleet loop with an orchestrator and three specialists: 500,000–2,000,000 tokens. A loop on a daily schedule: millions of tokens a week. At standard API pricing, a week of serious loop engineering costs more than most people’s whole monthly AI budget.

That’s why Steinberger’s replies filled up with “easy for you to say — you have unlimited OpenAI access.” They’re not wrong. Every retry costs. Every self-correction costs. Every subagent costs. Every verification pass costs. That free-roaming open loop? It burns tokens at a rate that makes your eyes water.

So the piece pivots to a solution — this is what Chinese LLMs solve. Models like DeepSeek, Kimi, MiniMax make agent loops economically viable. And DeepSeek V4 is “currently one of the cheapest frontier-level models for running loops at scale”: a 1M context window, 384K max output, Flash and Pro tiers, extremely low token pricing, tool calls and JSON output, up to 2500 concurrency on Flash. It lands on one closing line: “1.7 billion tokens for $20.”

Mogu 's hot take:

Okay, stop. I have to hit pause here, because this is the most worth-discussing part of the whole article — not because it’s wrong, but because it’s right in a suspicious way.

I checked: DeepSeek V4 is real (released 2026-04-24), and the specs are real too — V4-Pro is a 1.6T-parameter mixture-of-experts model with 49B active, 1M context, 384K output, MIT open weights, 80.6% on SWE-bench (tied for top among open weights). Cheap is also real — per output token it’s nearly 29× cheaper than Claude Opus 4.8. So this isn’t fabricated. DeepSeek V4 really is a strong, cheap car.

The problem is the seam in the narrative. Watch the move: a piece about loop architecture hits the cost pain point and suddenly cuts from “concept” to “spec sheet” — 1M context, 2500 concurrency, Flash/Pro tier names — then drops a round-number hook to close it out — “$20 = 1.7 billion tokens,” the kind of “sign up now” line every ad ends on. That rhythm is the same rhythm as an ad that interrupts the short video you were watching.

And that headline number doesn’t quite add up. DeepSeek V4 Flash output runs about $0.28 per million tokens, so $20 buys roughly 70 million output tokens; even at the cheapest input rate you don’t reach 1.7 billion. To hit “$20 = 1.7B” you’d need an average around $0.012 per million — that’s promo-period or referral-code territory, not list price. In other words: the model is real, but that pretty round number reads like marketing.

Calling this out isn’t dunking on DeepSeek — it’s genuinely good, and cheap closed loops are a 2026 gift. It’s because this is the 2026 content norm: real substance with one ad sewn smoothly into the middle, the seam clean enough you’ll swallow it if you’re not looking. gu-log’s job is to point at the seam — take the five sections of framework with you; read that “one of the cheapest frontier models” line as an ad, and go check the list price yourself (⁠¬⁠‿⁠¬⁠)

Prompt Engineer vs Loop Engineer: The Splitting Seam

A skill gap is cracking open in 2026.

A prompt engineer’s job is to write better instructions — that’s a language skill. A better prompt buys a better single output, but you still review the result by hand after every run. In that model, you are the feedback loop.

A loop engineer’s job is to design better feedback cycles — that’s a software-engineering skill. A better loop buys reliable, verified outcomes, and the system runs, checks, and self-corrects. In that model, the system is the feedback loop.

The bluntest contrast: a prompt engineer says “write me a function”; a loop engineer says “write → test → fix until green.” The first writes better English sentences, the second writes VISION.md; the first runs an agent once, the second builds a system that runs over and over; the first pays per single output, the second pays for a verified outcome.

Same tools, completely different mindset. Prompt engineers ask AI for output; loop engineers design systems that produce verified outcomes. The highest-paid AI engineers of 2026 aren’t writing prettier English sentences — they’re writing the logic that governs how an agent discovers, plans, checks its own work, and knows when it’s done.

Mogu butts in:

The buried message in that contrast is a little brutal: “prompt engineering” as a job title is past its freshness date. Not that writing prompts is useless — every step inside a loop is still held up by a prompt — but if your entire skill is “make English sentences flow better,” the agent will soon do that itself. What holds value is the layer above: designing feedback, designing stop conditions, designing who-verifies-whom. This echoes another piece gu-log translated — Anthropic defines Claude’s real steering wheel as “making a human understand what it just did,” not the prompt itself (Claude Code’s Real Steering Wheel). The steering wheel moved up a layer.

Closing: The Loop Doesn’t Know the Difference. You Do.

There’s one line, buried near the very end of the original, that I think carries the real weight of the whole thing.

Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop can’t tell them apart — it just runs. The only one who can tell is the person who built it.

That’s why loop design is harder than prompt engineering, not easier. Boris Cherny’s point was never that the work got easier — it’s that the leverage point moved. So: build the loop, but build it like someone who intends to stay the engineer, not like someone who just presses go and leaves.

Because one reliable loop really is worth a thousand perfect prompts. But only while the person pressing go still wants to be the engineer.

Mogu real talk:

I love that the author didn’t land this on “go subscribe to the cheapest model,” but on something almost moral. The real risk of loop engineering was never the bill — it’s automating away understanding itself. You outsource verification to a system that cares less than you do about being right, and one day you find nobody alive actually understands what the codebase does. Cheap tokens finally let you afford to build a loop. Cheap shouldn’t let anyone afford to stop understanding. Keep the framework, drop the ad, nail that last line to the wall (⁠๑⁠•⁠̀⁠ㅂ⁠•⁠́⁠)⁠و⁠✧