Loop Engineering Is the Next Rung After Prompting Coding Agents

In early June, the AI world was ignited by a single sentence

On June 7, 2026, OpenClaw author Peter Steinberger posted on X:

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

In just a few words, the post's views quickly surpassed 8.2 million. On Tech Twitter, some called it "the shortest controversial sentence of June" — posts of support and skepticism flooded screen after screen. Firecrawl's blog put it bluntly: A six-word sentence has tech Twitter in a chokehold this month.

The controversy hadn't cooled when Google engineer Addy Osmani published a long article the next day, Loop Engineering, formally naming this fermenting concept and breaking it down into an actionable framework.

In the following week, teams like MindStudio, AlphaMatch, and Firecrawl published their own interpretations — a new term, almost overnight, went from "big-shot quote" to "the methodology for AI programming in 2026."

And Steinberger's sentence didn't come out of nowhere.

Earlier, on June 2, Anthropic's Claude Code lead Boris Cherny said almost the exact same thing at WorkOS's Unplugged event — a clip that was later cut into a short video and widely circulated on X:

I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops.

By March 2026, the Claude Code project itself was 100% autonomously maintained by Claude Code. According to his disclosure, about 4% of public GitHub commits at the time came from Claude Code. This workflow, from "hand-coding" → "prompting an agent to write code" → "writing loops so the agent prompts itself" — three leaps in abstraction level, all happening in less than a year.

Osmani quoted both of them in his blog and gave his own definition:

Loop Engineering = Using system design to replace you acting as the agent's prompt operator.

A Loop is a recursive goal: you define the purpose and stopping condition, and the system iterates automatically until it's done. You design the "discover work → dispatch → execute → check → record → decide the next round" — instead of sitting in a chat window, typing turn after turn.

Cherny put it clearly: The work didn't get easier; the leverage point changed.

Before, the competition was about who wrote the best prompt; now it's about who designs the cleverest Loop. Osmani also cautioned: it's still early, token costs can differ by orders of magnitude, and verification relies on the engineer more than ever — but Codex's Automations, /goal, and Claude Code's /loop, hooks, Sub-agents, the skeleton has already grown into the products.

Once you see this shape, arguing over which tool to use becomes secondary; the key is whether your Loop can actually run.

---

What is Loop Engineering?

If you've just been reading up on Harness Engineering — setting up environments, rules, and feedback for agents — don't panic: many teams haven't fully digested it yet, and the Loop concept is already hot.

Osmani has a fitting analogy: Harness is the runway; Loop is the dispatch system on the runway. The former manages how a single agent runs safely; the latter manages who finds the work, who does it, who checks it, and under what conditions to clock out.

Osmani breaks a functional Loop into five building blocks, plus one piece of external memory. Don't bother memorizing tool names; first understand the division of labor.

Automations — The heartbeat of the Loop. Without scheduled triggers, a Loop is just a script you ran manually once. Automations are responsible for rhythmically discovering work: CI failed last night, Issues piled up, a certain module was modified last week. Codex has an Automations panel, Claude Code has /loop and cron; the essence is the same — let the Loop find work itself, instead of you opening your IDE every morning thinking "what should I get the agent to do today."

Worktrees — Don't step on each other's toes when parallelizing. Two agents modifying the same file simultaneously is as troublesome as two people committing the same line without communication. Git worktree gives each task an independent checkout and branch; Codex has built-in per-thread worktrees, and Claude Code supports --worktree and subagent-level isolation. Parallelism is the multiplier for Loops, and worktrees are the prerequisite for parallelism.

Skills — Externalizing project knowledge. An agent cold-starts every session, and gaps in its context will be filled with confident errors. A Skill (SKILL.md) writes conventions, build steps, and pitfall records to disk, so the Loop can read them every round. Write the intent once, and the Loop reuses it every round, instead of repeatedly explaining the project from scratch.

Connectors — The Loop touches the real world. A Loop that can only read the file system is small. MCP and various Connectors allow the Loop to query Issues, read CI logs, send Slack messages, and call staging APIs. One step short of opening a PR, one step short of updating a ticket, and the Loop is still a semi-finished product.

Sub-agents — The writer shouldn't grade their own paper. Let the same model write code and then declare "no problem," and it will almost certainly favor itself. A common split in Loops is: one agent explores, one implements, one reviews. Claude Code's Task subagents and Codex's .codex/agents/ follow this idea. Separating Maker and Checker is the prerequisite for trusting the results when the Loop runs unattended.

State / Memory — Agents forget, disks don't. Progress, attempted solutions, what passed and what failed, must be stored externally — Markdown files, Linear boards, AGENTS.md, any form works. Models suffer amnesia across sessions; a Loop can relay tasks because of State, not chat history.

Putting it together: A Morning Triage Loop

Osmani gave a very concrete example.

Every morning, an Automation runs automatically: reads yesterday's CI failures, newly opened Issues, recent commits, and triages the items worth addressing.

Each item gets its own worktree. Sub-agent A drafts a fix, Sub-agent B reviews it against the Skill and existing tests.

A Connector is responsible for opening a PR and updating the ticket. What the Loop can't handle goes into a Triage inbox for a human to review.

A State file records "what was tried, what passed, what's left" — tomorrow morning, the Automation wakes up and picks up from the same page.

At this point, the Loop can already discover work, write code, review code, open PRs, and record state.

Sounds like a closed loop.

But think carefully about one question: How does it know it's "done"?

---

The Loop's "completion condition," where it usually stops

The /goal in Codex and Claude Code is the mechanism closest to "the Loop clocks out on its own": write a machine-checkable stop condition, and the Loop runs round after round until it's met — commonly lint is clean, all unit tests pass, type checking passes, and a Sub-agent adds another layer of diff review.

For backends, CLIs, and pure libraries, this is often enough.

But for Apps, Web, and cross-platform UI, "command exit 0" does not equal "the product is fine": is the interface correct, can it run on a real device, does the flow work — none of this is in the source code or terminal logs. So most Coding Loops actually stop at code is mergeable; the step of verifying the product is still done by a human compiling, installing, and clicking around.

The Loop is nominally running, but the verification branch is often still an open loop.

Has the product been verified, and who does it? Teams building Apps and Web will hit this problem first.

---

Coding Agents can't see the screen

Teams usually try three paths, but all struggle to form a verification sub-Loop — an automated branch next to the Coding Agent that can run itself, make judgments, and send evidence back:

1. Manual testing. The code Loop spins furiously, but you still verify the product one by one. A human isn't a Connector and can't be scheduled by /goal; the bottleneck just moved from prompting to tapping the screen.

2. Let the Coding Agent write Playwright, XPath. Scripts can enter CI, but they break when the UI changes, and the maintenance cost isn't low. More fatally: the agent writing the test and judging the test is often the same agent — earlier we emphasized "the writer shouldn't grade their own paper," but here it's precisely testing its own work. Entering CI doesn't make the Loop trustworthy.

3. Use cloud-based visual large models to watch frame by frame. Theoretically sound, but the number of screenshots from one full regression test is enough to halt the Loop on token costs before it finishes — verification is too expensive, the Loop can't afford to run, returning us to Cherny's rule.

Three paths either embed you back into the Loop, let the agent grade its own paper from the same source, or are too expensive for daily operation.

What we lack isn't a simple testing framework, but a verification sub-Loop. It needs at least three things — that is, what the previously mentioned Connector, Sub-agents, and State should each do when "verifying the product":

• Connector — can connect to a real device/browser, automatically send results back to the Coding Agent after verification, no need for a human to screenshot and paste.
• Sub-agents — the one clicking and the one judging are not the same agent; it can't just say it passed on its own.
• State — what was verified, which step failed, written to a file; don't just leave it in the chat history.

In other words, to close the loop of AI-driven development, AI must achieve E2E testing. This is especially critical in the mobile domain.

This is also the reason I made the open-source project Munk AI.

---

Putting it together: A feature delivery Loop with "product verification"

I started working on Munk AI a few months ago. Its function is simple: Let AI control Android and iOS to do real-device E2E testing.

It can connect to the daily development workflows of Cursor, Claude Code, and Trae, running on your local machine.

Let's use an example — developing a "delete account" feature, where lint, unit tests, and real-device verification all pass before opening a PR.

---

1. First, you describe the requirement in natural language, for example: "Users can delete their account on the settings page, return to the login page after confirmation, and old data is invisible upon logging in again."
2. The Coding Agent writes code based on this, installs the app on a phone or browser — this step is the same as usual.
3. Next, hand it over to Munk. It first reads the requirement, then the code diff summary, then operates on the device following the user path: Settings → Account → Delete → Confirm. It then hands the operation record to another agent to judge: whether the test passed.
4. It might not pass the first time. For example, the confirmation popup is blocked by the keyboard, and "Confirm" can't be tapped. At this point, the judging agent doesn't just throw back a "failed": it packages which step it got stuck at, what the screen looked like at that moment and sends it back to the Coding Agent. The Agent modifies the code, reinstalls, and automatically continues verifying — if the condition isn't met, it doesn't stop.
5. The second time it passes, the Coding Agent then opens the PR.

The entire chain is: You clearly state what you want → The system runs automatically → What it can't handle comes back with evidence → The next round continues. The difference is that the completion condition now includes one more item — the product has actually been verified on a real device.

---

Final words

Whether it's Harness Engineering or Loop Engineering, their ultimate goal is to:

• Make AI work performance more stable;
• Make AI work duration more persistent;
• Make AI work more autonomous;

Munk AI's goal is: to connect the link of AI real-device testing on mobile.

For Loop Engineering to land more stably on mobile, AI real-device testing is indispensable.

Munk AI is our open-source attempt at the "mobile AI testing" branch, still in its early stages.

If you are also using AI to write code and are tired of always having to click around yourself, welcome to try it out:

• 👀 Installation experience, documentation, and updates: munk.sh
• ⭐ Star the open-source repo: github.com/chaxiu/munk-ai
• 🐦 Follow on X / Twitter for follow-up practices and updates: x.com/iBoyCoder
• 📮 Follow the WeChat official account "朱涛的自习室": Notes on Loop Engineering, AI testing, and Munk's implementation will be updated gradually · *