跪拜 Guibai
← Back to the summary

Stop Writing Prompts; Start Designing Autonomous Coding Loops

Recently, a term has been gaining traction in developer circles — Loop.

Jensen Huang said, "Prompting is becoming obsolete; Loop is the new paradigm." Boris Cherny, the founder of Claude Code, said he stopped writing prompts himself a long time ago and now lets a bunch of Loops do all the work for him. A tweet about Loop by Peter Steinberger, the founder of OpenClaw, racked up 1.5 million views.

This isn't some old concept being hyped up for no reason; rather, AI programming is undergoing its fourth paradigm shift — from Prompt to Context, to Harness, and now to Loop.

What exactly is a Loop?

Don't be intimidated by the name; the logic is quite straightforward.

In the past, using AI for programming meant having a back-and-forth conversation with it: you wrote a Prompt, it spat out code, you checked the result, and if you weren't satisfied, you wrote another one. Throughout the entire process, the human was always in the loop, supervising. The AI moved one step, and you pushed it one step.

What Loop does is pull the human out of the loop.

You give the AI a goal, it runs on its own, checks its own work when finished, and redoes it if it fails, only stopping when the job is done or the budget is exceeded. Your role shifts from being a "relayer of instructions" to a "rule designer."

To put it another way, before, you were teaching an intern how to write code, directing every single step. Now, you are designing an assembly line, and the intern just spins on it, handing over the finished product when done.

How is it different from an Agent?

Good question. Many people hear "Loop" and immediately say: Isn't this just an Agent?

An Agent is the "person" doing the work; a Loop is the management mechanism that allows this person to keep working without you having to supervise.

An Agent without a Loop moves only when you ask it a question; it's essentially still an obedient tool. An Agent wrapped in a Loop becomes a self-running system.

How does Boris Cherny himself work? He uninstalled his IDE back in November last year. Now, he has hundreds of small Agents running simultaneously — some scanning GitHub Issues, some reading Slack feedback, some monitoring CI failures. Each Agent works in its own isolated branch; one writes the code, another runs tests to verify it. Only the issues they can't handle land in his inbox.

According to him, since Opus 4.5, all his code has been written by Claude Code, and most of it was actually done directly on his phone.

Why is it gaining traction right now?

Actually, the concept of Loop has existed in academia for a while. Shunyu Yao's ReAct framework (Reason+Act) from 2022 was essentially a loop structure of "Think → Act → Observe → Think again."

So why is it only now exploding in the industry?

The tools have matured. A year ago, if you wanted to build this, you had to write a bunch of Bash scripts, scheduling systems, and state management yourself. Now, Claude Code and OpenAI Codex have built these capabilities directly into their products.

In Claude Code:

The most ingenious design is in /goal — the large model writes the code, and another independent, smaller model (Haiku) verifies it, each performing its own role. The principle that you can't grade your own paper has been baked into the product architecture.

OpenAI Codex's approach is closer to an "automated assembly line + multi-Agent parallelism," with up to 8 Agents working simultaneously in their own cloud sandboxes, finally aggregating the results.

The two products have different implementation paths, but the resulting forms are highly similar — both break down tasks, execute in parallel, and aggregate results uniformly. Their performance in public benchmarks is also already very close.

This points to one thing: the models themselves can no longer be dramatically differentiated; the real gap is in the upper-layer Loop orchestration.

Paradigm Shift: The Granularity of Control Keeps Moving Up

Pulling back the timeline, a clear evolutionary path emerges:

Essentially, the granularity of human control over AI is constantly moving up — from writing a single sentence, to providing information, to building a system, to designing a loop.

How can an average person "get Looping"?

A blogger on X named Codez published a 14-step practical roadmap. I'll pick out a few key points.

Step 1: Don't rush to build; first, do the "Four-Condition Test"

You can't just throw any task into a Loop. Before you start, ask four questions:

Only if all four pass is it worth building a Loop.

Step 2: Start with a Minimum Viable Loop

Don't try to be fancy on your first attempt. The core four-piece set:

The order is critical: First, run it manually successfully → write it into a Skill → wrap it into a Loop → finally, put it on a schedule. Skipping steps is the main reason Loops die in production.

Step 3: Code writing and code verification must be separated

This is the most important principle in Loop design. Use one model to write and another independent model to verify; the verifying model must not see the reasoning process of the writing model.

Why? Because when a model grades its own code, it's far too lenient. Any code that "looks good" to the writer will likely have a bunch of flaws picked out by an independent verifier.

Pitfall Avoidance Guide: Lessons from Others

No hard stop condition — The Loop runs until you see your bill and stop it. You must set a token limit, an iteration count limit, and a time limit.

State isn't persisted — An Agent's memory is short-term; what it learns today, it forgets tomorrow. State must be written to a state file and read back on every run.

Don't let the Loop touch tasks that require "judgment" — Architecture rewrites, authentication code, payment logic, product direction decisions — don't let a Loop touch these. Loops are suitable for tasks where "right and wrong are clear and machine-verifiable," such as automatic Lint fixes, dependency update PRs, and CI failure classification.

You must read the Diff — As Loops merge code faster and faster, your understanding of the codebase grows shallower and shallower. This is called "comprehension debt" — the real cost isn't the token bill, but the day you have to debug a system that no one on the team has ever read.

There's only one metric that matters: what is the average cost per accepted change. If your "acceptance rate" is below 50%, the Loop you built is losing money.

The Two Biggest Problems: Cost and Cognitive Surrender

Cost — This is the most realistic obstacle. Boris Cherny and Peter Steinberger both have companies behind them providing nearly unlimited token support, but the average person doesn't have that.

One developer calculated: Executing once per minute for 8 continuous hours means 480 API calls. Claude Code's current strategy is to impose limits: a minimum interval of 1 minute, a maximum runtime of 3 days, after which it automatically stops. Closing the terminal stops the Loop; it's not some persistent background task, precisely to prevent runaway bills.

Someone asked Peter Steinberger, "A $20 plan is simply impossible, right?" He replied with a blunt truth: "Correct. But is your time really worthless?"

Cognitive Surrender — This is a concept raised by Google engineering lead Addy Osmani. When a Loop runs more and more smoothly, it's very easy for a person to stop thinking. Over the long term, one might gradually lose the ability to form independent judgment.

He had a particularly good passage:

"Designing the Loop itself is not the answer. When you design it with judgment, it can become a solution; but when you use it to escape thinking, it becomes a catalyst that accelerates the problem. The same action can lead to completely opposite outcomes."

The Trend is Already Very Clear

Over the past three years, the human was always in the loop, the core driving the entire system. Loop engineering, for the first time, moves the human from the center of the loop to the outside — the human is no longer the driver, but has become the navigator.

For developers, the core competency becomes the ability to define problems and design acceptance criteria. For products, the iteration speed will further accelerate, because technology is no longer the bottleneck; judgment is.

Of course, all of this rests on one premise: the models must continue to get stronger. How many cycles a Loop can run and how complex the tasks it can handle ultimately depend on the model's foundational capabilities. If a model veers off course after just three or five steps, no matter how clever the Loop design, it's useless.

Fortunately, judging by this year's situation, model progress hasn't slowed down. GPT-5.5, Claude 5, GLM-5.2, DeepSeek V4 — in half a year, each company has updated a generation, and each generation has shown a clear improvement in Agent capabilities.

Models are getting stronger, Loops are running smoother, and humans are stepping further back.

This might sound like just an efficiency boost, but think about it carefully — it could be the key step in AI's evolution from a "tool" to a "collaborator." A tool is something you use, and you have to know how to operate it. A collaborator is someone you tell the goal, and it figures out how to get there on its own, and you accomplish things together.

We might be standing right at that inflection point right now.