The father of Claude Code deleted the IDE, eliminated prompts, and only wrote loops.

I hadn't opened it for a month, so I simply deleted it.

In November last year, Boris Cherny uninstalled his IDE with his own hands.

During that month, he submitted 259 PRs, and not a single line of code was written by himself. It was all written by Claude Code.

So, a person who created Claude Code with his own hands dismantled his own cockpit.

That's not all. In an interview on June 2nd this year, Boris dropped another bombshell that went viral in the global developer community:

I no longer write prompts for Claude. It's the loops that are running. They are prompting Claude and figuring out what to do on their own. My job is to write the loops.

A few days later, Peter Steinberger, the father of OpenClaw and now at OpenAI, dropped the second bombshell.

He wrote on the X platform: Stop writing prompts for programming agents. You should design the loops that prompt the agents for you.

Meanwhile, Addy Osmani, a senior engineering director at Google and former head of Chrome developer experience, gave a name to this term that has set the entire AI programming community ablaze in a blog post: Loop Engineering. He believes it could become the way we collaborate with programming agents in the future.

So, the loop, an old programming concept, has been reinvented overnight and suddenly become the center of the AI development paradigm shift in 2026. And the era of editors, which has dominated programming for decades, is coming to an end.

But will loop engineering really wipe out the prompt engineering you've painstakingly learned over two years overnight?

From Writing Prompts

To Writing Loops

In the past two years, the way people interacted with programming agents was in a turn-based manner.

You'd type a prompt, read its response, and then type the next one. In this process, humans were both the dispatcher and the quality inspector. In essence, humans were the loop itself.

What loop engineering aims to do is to let you build a small system. It will find tasks on its own, assign them, check if they're done, record the progress, and then decide what to do next.

Then you can let this system command the agents to work while you step back.

In Osmani's words, loop engineering is "replacing the person responsible for prompting the agents and instead designing the system that prompts them for you." And the loop itself here is a recursive goal. You set the goal and let the AI iterate round by round until it's completed.

He puts loop engineering "one level above" the harness engineering he previously proposed. Harness engineering manages an agent to run a single task, while the loop decides which tasks to run, when to run them, and what counts as completion.

The New Stack gave a more understandable analogy: It's like moving from "operating a machine tool" to "designing the entire production line where the machine tool is located."

Prompts Aren't Dead

They've Moved into the Loops

Does the arrival of loop engineering mean the death of prompt engineering?

No.

Let's first see how the loops work.

Claude Code has two commands: /loop and /goal. Codex can do the same thing with /goal and its Automations.

/loop makes a prompt run repeatedly at the interval you set. /goal makes the agent keep working until the condition you write becomes true. After each round, an independent small model determines "whether it's completed or not." The model writing the code isn't allowed to grade itself.

Prompts aren't dead. They've just moved from your hands into /loop and /goal. You no longer type them one by one. Now you write them into the loops and reuse them repeatedly. So, the prompts you've practiced so hard aren't wasted. Instead, they're more valuable.

You Might Have Been Using It Already

You Just Didn't Call It a Loop

Don't be intimidated by the word "engineering."

Claire Vo, the founder of ChatPRD, has a very down-to-earth judgment on it:

If you've set a scheduled task in Claude Cowork, then congratulations, you've already written a loop.

This isn't a brand-new concept just proposed. Simon Willison, the co-creator of the Django framework and an independent AI researcher, wrote about "designing agent loops" as early as September 2025.

In 18 months, developers have moved from prompt engineering to context engineering, then to harness engineering, and now it's loop engineering's turn.

A year ago, if you wanted to build a loop, you had to write a lot of bash scripts by hand. And even after you were done, you had to maintain it forever, always worried that it might break down.

Now, the components needed to build a loop are directly built into Codex and Claude Code.

Replicate Boris's "Hive"

You Can Build It in Your Claude Code Now

Boris hasn't made his configuration public. A developer on X named @Av1dlive rebuilt a complete system configuration called "THE HIVE" from scratch based on Boris's public interviews.

And an ordinary person can also build such a self-running system. All the components it needs are in your Claude Code.

The entire "Hive" has three layers.

The first layer is the local loop, which relies on /loop. It keeps working while the session is open, running at a minimum interval of once a minute, and stops when you turn off your computer.

The second layer is the cloud routines, which Anthropic launched in April this year. They run on the cloud in newly cloned repositories and keep running even when you turn off your computer, with a minimum interval of once an hour.

The third layer is the cluster, which relies on /batch and dynamic workflows. It distributes tasks all at once, with hundreds or thousands of worktree sub-agents running in parallel. Each stays in its own isolated code checkout and doesn't interfere with others.

@Av1dlive also compiled seven loops that you can directly copy.

Seven slash commands, seven parallel loops: Monitor PRs, dig for Slack feedback, clean up zombie PRs, classify issues, precipitate the rules you've repeatedly corrected into CLAUDE.md... They're all session-level and stop when you close the terminal. This is the most basic layer of the "Hive."

The real magic lies in the combination.

The cloud routines in the second layer write the discoveries into a file. The local loop in the first layer reads the file and continues the work. When it encounters a large task, it activates the third layer cluster.

The results flow back, and a routine distills and updates CLAUDE.md every week.

Once this flywheel starts spinning, your agents will be smarter every week than the previous one.

Codex and Claude Code Look Alike

That's the Real Signal

Osmani listed a comparison table in his blog. A complete loop can be broken down into these six components:

Automations are triggered regularly. They do the discovery and triage on their own and put the found items into an inbox for you to check.

Worktrees prevent conflicts. If two agents modify the same file at the same time, it's like two engineers submitting to the same line of code without communication, which will definitely cause conflicts. Git worktree gives each agent an independent checkout, so they won't interfere with each other.

Skills address the short - term memory issue. Write the project conventions, build steps, and pitfall experiences into SKILL.md once, so that the agent doesn't have to guess from scratch every round.

Connectors help the agents understand the real world. Based on MCP, they allow the agents to read your issues, query databases, and send messages to Slack. This is the difference between "telling you how to fix it" and "directly opening a PR and updating the work order for you."

Sub - agents separate writing and checking. The model writing the code is always too lenient when grading itself. Open another sub - agent with different instructions, preferably a different model, to pick on the faults, which can catch the problems that the first agent convinces itself to overlook.

Finally, Memory is just a markdown file. It records what has been done, what has passed, and what is left, so that the next round can continue from where it left off today.

These components don't sound new:

From ReAct in 2022, to AutoGPT in 2023, to the Ralph loop by Geoffrey Huntley in July 2025, which "repeatedly feeds the same prompt with a single line of bash," and then to the /goal in Codex and Claude Code this spring.

The novelty lies in the fact that the two products have almost exactly the same set of components.

The real competition is starting to shift to who can make it easier for people to write loops. This will be the deciding factor in the new round of competition between Codex and Claude Code.

Loops That Can Work on Their Own

Can Also Cause Trouble on Their Own

Being able to let agents work automatically sounds great, but it still faces the following challenges:

The first challenge is cost.

Multiple agents with sub - agents running on the latest models, and dynamic workflows can easily consume 5 to 10 times the expected tokens.

Steinberger can afford to do this because he self - mocks as "a person with unlimited tokens," which is OpenAI's perk that ordinary people don't have.

The second challenge is loss of control.

Anthropic itself has pointed out three common pitfalls for loops.

• Slacking off: Saying "done" after completing only 20 out of 50 security issues.
• Self - praise: Giving high scores to its own work.
• Drifting: After many rounds, the "don't do X" you wrote initially quietly disappears in the 47th round.

These three pitfalls are exactly the reason why the "maker" and the "checker" must be separated.

The third challenge is skepticism.

Many people on Reddit and in the developer community think that loop engineering is essentially just old concepts like ReAct, agent loops, and task scheduling with a new name and a layer of product packaging, like old wine in new bottles.

"I'm a prompt engineer" → disappearing into the bushes → "Prompt engineering is nothing. It's just a fancy way of speaking clearly" → "I'm a context engineer now." This widely circulated Simpsons meme reveals this round of skepticism: From prompts to context to loops, the titles keep changing. Could it just be the same person disappearing into the same bushes and coming out with a new name?

These doubts aren't all just sour grapes.

Even Anthropic itself admits that the so - called average daily code merge volume being 8 times that of 2024 "almost certainly overestimates the real productivity." The number of code lines measures quantity, not value.

So, in the end, loops don't equal fully autonomous AI. They still rely on stop conditions, verification mechanisms, and humans to set goals.

It's not a brand - new technology either and strongly depends on the scenario. It runs stably for tasks with clear acceptance criteria like coding and testing, but it can easily go off - track and waste computing power for open - ended tasks.

Being Able to Write Loops Is Your Moat

Although loop engineering still faces the above challenges, the direction won't change.

Claire Vo called this moment "the era of managers" in a live stream. You're actually designing a job. Writing loops is like onboarding a new employee. You're leading a digital team that's always at your service.

The models themselves are becoming more and more like utilities. Anyone can access them, and they're all the same. Every quarter, new models will render your excellent prompts from the previous quarter useless. What can really form compound interest is your loops, the skills you've accumulated, and the CLAUDE.md that's distilled every week.

This is also the confidence for Boris to uninstall his IDE. His output doesn't depend on a single conversation but on the system.

Osmani reminded in his blog that the stronger the loop, the more difficult three things become.

The first thing is that you still have to do the verification yourself. When the loop reports "completed," it's just its claim, not proof that it's really done correctly.

The second thing is that the comprehension debt keeps piling up. As the code written by the loop accumulates, your real understanding doesn't keep up. Every PR you merge without reading widens this gap.

The third and most dangerous thing is that the same loop can be a lever when used for tasks you understand, but it can accelerate your decline if used to avoid understanding.

Boris was able to delete his IDE not because he "stopped writing prompts" but because he moved the prompts from