Author: Wang Dapeng, Datawhale Member
A couple of days ago, we shared "Heavyweight! Loop Engineering Practical Manual Released", systematically organizing Loop Engineering's six core components and implementation methods.
Today let's talk about the supplementary content: first, completing Loop's evolutionary lineage; second, completing the understanding of Loop's essence. We'll start from these two judgments made recently.
In June 2026, Boris Cherny, head of Anthropic Claude Code, said something that made people pause:
"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."
Interestingly, most developers are still crafting perfect prompts, while the people building the tools have completely abandoned prompting.
That same week, OpenClaw founder Peter Steinberger expressed the same thing differently:
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
Two people, different occasions, different products, same conclusion. This doesn't feel like coincidence—it feels like engineering practice naturally reaching an inflection point.
This article discusses: Where does Loop come from? What problem does it actually solve? And for most people, should you start building one now?
I. Prompt → Context → Harness → Loop
To understand Loop Engineering, you first need to understand what came before, and what happened across the entire chain.
The story starts in 2024. Back then, collaborating with AI was simple: you write a prompt, the model returns a result. The term "Prompt Engineering" was invented in this phase—using phrasing + examples + formatting to get the model to output what you want.
This approach has a fundamental limitation: you must anticipate everything the model needs in a single message. You have to stuff background, rules, examples, constraints all in. The model knows what it sees, and can only guess at what it doesn't.
By early 2025, people realized the problem wasn't prompt phrasing—it was that the model had too little information. Context Engineering emerged—stop obsessing over how to "ask," and instead carefully construct what the model "sees": system prompt provides role and rules, few-shot examples calibrate output format, RAG retrieval injects real-time knowledge, structured input lets the model precisely understand requirement boundaries.
With context done right, the model stops guessing. But a new problem surfaced: even with perfect information, complex tasks can't be done in one shot. Refactoring a module requires reading code first, then changing interfaces, then updating callers, then running tests to verify—this isn't something a single prompt can handle. The model needs multi-step execution, needs tools, needs to observe intermediate results and decide the next step.
Enter Harness Engineering. The name is a bit odd, but it describes something concrete: give the Agent tools—shell commands, filesystem read/write, MCP connectors, sandbox environments—then give it a retry mechanism and permission control, so it can complete multi-step operations in one session. Claude Code, Cursor, Codex—these products are essentially harnesses. You give it a task, it plans steps, calls tools, observes results, retries on failure.
Harness solved the "execution capability within a single session" problem. But it didn't solve a bigger bottleneck—humans.
You have a well-equipped Agent. It can read code, write code, run tests, open PRs. But every morning, it's you opening the laptop, checking CI status, copying error logs, pasting them to the Agent, waiting for fixes, reviewing results, approving merges. Repeat tomorrow. By day three you're annoyed.
At this point, Agent capability isn't the bottleneck. Humans are.
Loop Engineering's starting point is exactly this: replace the human in the "human triggers Agent → human judges result → human decides next step" loop with an automated system. This system can trigger on schedule, verify results, remember where it left off, decide whether to continue, stop, or escalate.
You're no longer the person writing prompts. You're the person designing prompt systems.
II. What It Takes to Get a Loop Running
The industry-standard Loop has six components. Let's walk through a concrete scenario.
Suppose your team hits CI failures daily—some test fails, some type check errors. Without a Loop, the flow goes: open laptop in the morning, see CI red, copy error logs, paste to Agent, wait for fix, run tests, open PR. Repeat tomorrow.
With a Loop, the flow becomes: every morning at 8 AM, the system wakes up automatically. What happens next is a complete run loop—
1. Find work to do (Automations). The system checks CI status. All green? Do nothing. Failures? Read error logs, determine today's work target. This is the trigger layer—a Loop needs something to wake it up: a timer (cron), an event (CI failure triggers webhook), or the Agent's own heartbeat check. Without this, the Loop never starts on its own.
2. Isolate: spin up a clean workspace (Worktrees). The system launches the fix in an independent git worktree. Why not just edit on main? Because if you're running three fix tasks simultaneously, they can't overwrite each other in the same code directory. Each subtask needs its own copy, isolated from the others.
3. Read rules: don't start from zero (Skills). On startup, the Agent reads project knowledge files—Codex calls it AGENTS.md, Claude Code calls it CLAUDE.md, finer-grained skill files are SKILL.md. Whatever the name, they do the same thing: encode coding standards, architectural conventions, common pitfalls, so the Agent loads them automatically on every startup. Otherwise every session re-"learns" your project, wasting tokens and time.
4. Execute: connect to the real world (Connectors). After the Agent fixes code, it needs to open PRs, close tickets, notify you. This requires reaching external systems—via MCP connecting to GitHub, Linear, Slack, databases, interacting with or notifying the outside world.
5. Verify: get someone else to grade (Sub-agents). Run tests automatically after the fix. But here's a key design: the Agent that wrote the code cannot verify its own code—like a student grading their own exam, the errors it makes are exactly the ones it can't see. You need another Agent to check.
6. Remember: write down what happened today (Memory/State). Tests pass? Open PR and update state file. Tests fail? Write "what we tried today, where we're stuck" into the state file. Next time the Loop wakes, it reads this file and knows where last run left off, what failed. The Agent's context window clears every time, but disk can store the memory knowledge base.
That's one complete Loop run. When you open your laptop in the morning, you no longer see "CI is red"—you see "here's a PR awaiting your review" or "this issue has run for two days unsolved, needs your eyes."
You might ask: how is this different from a cron job? It looks like a scheduled task.
The difference: cron logic is fixed at write-time—if CI red then run fix script then commit, hardcoded if-else. The Loop's decision-maker is an LLM. Same "CI red" input, it might judge "this is a flaky test, skip it," or "this involves dependency changes across three files, needs phased handling." Its behavior is determined at runtime, because the decision-maker has judgment.
III. The Essence of Loop: Cybernetics
So far, most discussions of Loop Engineering treat it as an orchestration problem—use Worktrees for isolation, Connectors for connection, Memory for recall. These answer how to assemble, not why assemble this way.
Back to the CI triage example. Look closely at what that flow does: there's a target (all tests pass), an execution action (Agent fixes code), a check (test suite runs and reports deviation), a feedback (failure info fed back to Agent for another round).
This structure feels familiar. Home AC set to 77°F (25°C), compressor starts cooling, temperature sensor measures room temp, if not at 77°F keep cooling, stop when reached. Car cruise control set to 75 mph (120 km/h), engine adjusts output, speed sensor measures actual speed, too low → add gas, too high → ease off.
The essence is the same structure: Target → Execute → Measure Deviation → Feedback Correction → Re-measure.
This structure has a common name. Cybernetics / Control Theory—the discipline studying "how systems maintain target states through feedback," born in the 1940s, with one core question: how to make a system auto-correct back to target when disturbed. It breaks such systems into three roles: controller decides what to do, actuator does it, sensor checks how it went and feeds deviation back to the controller—three forming a closed loop.
First, the Controller.
A closed loop needs a decision center—read deviation signal, decide next correction. That's the Controller. In Agent scenarios, the controller is the entire orchestration logic: read validation results, judge if target met, if not, construct next prompt and run another round.
The controller faces two difficulties making good decisions. First, it doesn't know how your project works—coding standards, architectural conventions, tool usage, re-deriving every time is slow and unstable. So you write these rules down for the controller to grab on startup. That's why Skills exist. Second, it doesn't remember where it left off—context window clears every time, today doesn't know what yesterday tried. So you need persistent state living outside the session. That's why Memory/State exists.
Next, the Actuator.
A closed loop needs a role turning decisions into real-world actions. That's the Actuator. In Agent scenarios, the actuator is the tool-calling layer—file edits, shell commands, API calls.
The actuator faces two difficulties for precise operation. First, it can't reach the outside world—controller says "open a PR," it must actually connect to GitHub. So the actuator's reach must extend far enough. That's why Connectors (external services via MCP protocol) exist. Second, multiple Agents running in parallel overwrite each other—so you need isolated operation spaces. That's why Worktrees exist.
Finally, the Sensor.
A closed loop needs a role measuring results post-execution, reporting deviation. That's the Sensor. In Agent scenarios, the sensor is validation, outputting error signals—how far from target.
The sensor faces a structural difficulty: independence. If the doing Agent also acts as verifier, errors are correlated—the blind spot that caused the bug is exactly the blind spot that prevents seeing the bug. Like checking your work with the same reasoning, you probably won't catch the error. So you need another Agent, even another model, to check. That's why Sub-agents exist.
There's one more thing not belonging to any of the three: Automations (timers, event triggers, heartbeat checks). It's the loop's start condition—who presses the start button to get the circuit turning. Without it, the three roles can be perfect but never self-start.
Now, Loop Engineering's six components have their place. They're not cobbled parts—they're the infrastructure control fundamentally needs. Because the controller needs knowledge and memory, we have Skills and Memory; because the actuator needs reach and isolation, we have Connectors and Worktrees; because the sensor needs independence, we have Sub-agents; because the loop won't self-start, we have Automations.
Now ask a question control engineering has long asked: once this closed loop runs, what happens?
AC controls a stable plant—heating power vs. temperature relationship doesn't suddenly change. But you're controlling a language model—same input twice, completely different output possible. The more randomness, the more indispensable feedback correction becomes.
Running a Loop on this system has three outcomes.
Converge to correct state—Agent hits target, validation passes, validation didn't lie, no hallucination. The only good outcome.
Converge to wrong state—Loop stops because sensor reports "pass," but sensor was wrong: tests pass because tests themselves are wrong, build passes because broken paths weren't executed, review Agent passes because it's too agreeable. Worse than never stopping, because it stops with confidence.
Diverge—Loop can't reach sensor-acceptable state, drifts further off course, eventually hits limits and exits.
When you want AI to do more complex things but still demand quality, you cannot control this system with a "fixed plan." Control theory gives the framework: increase probability of "converge correct," or limit damage from the other two outcomes.
In these three roles, who determines convergence speed? The sensor.
Same validation task: one sensor returns only pass/fail, controller only knows "not good yet," doesn't know where, next correction is near-blind guess. But if sensor returns "which test failed, which assertion failed, which diff introduced it," controller isn't guessing—it's targeting a specific defect. Search space compresses further.
Most people's intuition is backwards: spend big on the strongest model to write code, then use simple chat for validation, end up hallucinating repeatedly, drifting further from target. The high-leverage way is designing good sensors to return richer signals, not just obsessing over smarter models.
This logic is: "Great prompt + weak verification" will fail; "mediocre prompt + strong verification" will converge. The sensor IS the design.
IV. How to Judge Whether You Need a Loop
Since the sensor is key, judging "should you build a Loop" becomes a more concrete question:
Can you write an automated check that rejects bad output without you watching?
Yes—you have the prerequisite for a closed loop. No—"done" is just subjective judgment.
Even if you can close the loop, a few real constraints remain. The task must repeat—at least weekly to justify automation, otherwise you're building an expensive one-off script. Token budget must tolerate waste—Loops re-read context, retry failed paths, every exploration step burns tokens regardless of output. Agent must have sufficient tools to observe results, otherwise it's blind repair.
A common mistake: designing for goals that can't be measured. "Help me refactor this code to be more elegant," "write a good technical blog," "design a good API"—these have no objective pass/fail standard. "Elegant," "good" are subjective judgments. Even with another LLM scoring, LLM scoring itself is unreliable—it tends to give high scores, and standards drift. In this case you build a Loop, sensor says "passed," but without objective standards, that "pass" is a fake closed loop.
If you judge you meet the conditions, the startup sequence is: first write Skills (clarify intent, so Agent doesn't re-derive your standards every time), then write the sensor (ensure you can precisely define "what counts as done"), only then wrap with cron trigger. Build the Inspector first, then the Loop.
The Loop doesn't care who operates it. It just runs "read sensor → judge → another round." But the sensor is written by you—how deeply you understand the system, how precisely the sensor can be written. The Loop amplifies your judgment.
Appendix: References
1. Loop Engineering: The New Way to Use Claude Code & Codex (https://medium.com/towards-artificial-intelligence/loop-engineering-the-new-way-to-use-claude-code-codex-c55dd65ecc61) — Addy Osmani
2. Loop Engineering Is NOT What Everybody Thinks It Is (https://medium.com/@agentnativedev/loop-engineering-is-not-what-everybody-thinks-it-is-6719a0f4f83f) — Agent Native Dev
3. How Claude Code, Codex, and Cursor Do Loop Engineering (https://medium.com/ai-all-in/how-claude-code-codex-and-cursor-do-loop-engineering-28b444968673)
4. Loop Engineering (https://medium.com/@cobusgreyling/loop-engineering-62926dd6991c) — Cobus Greyling
5. Why Is Loop Engineering Trending (https://medium.com/generative-ai/why-is-loop-engineering-trending-2acb7029af0c)
6. Loop Engineering Is Replacing Prompt Engineering (https://medium.com/coding-nexus/loop-engineering-is-replacing-prompt-engineering-why-the-best-developers-dont-prompt-ai-anymore-639c944be3ee)
7. What is Loop Engineering? How it is different than Harness Engineering (https://medium.com/gitconnected/what-is-loop-engineering-how-it-is-different-than-harness-engineering-0e764f373fb1) — Akshay Kokane
8. Loop Engineering Is Here. Most of You Should Not Build One Yet (https://medium.com/@alirezarezvani/loop-engineering-is-here-most-of-you-should-not-build-one-yet-part-1-d56f63acda00)
9. How To Build a Claude Loop Engineering Better Than 99% of People (https://medium.com/data-science-collective/how-to-build-a-claude-loop-engineering-better-than-99-of-people-3ab8701d176c)Give it a "Like" — three-in-one ↓