Father of Lobster's One Tweet: Is the Loop Era Over?

"Are we still talking about loops, or have we moved on to graphs?"

On July 18, 2026, Peter Steinberger quietly declared the end of the loop engineering era with this single sentence on X. The post garnered 2.6 million views within two days of its publication.

Six weeks earlier, he earned 8.4 million views with the phrase "design loops that prompt agents," making developers worldwide realize that the era of prompt engineering is passing and loop engineering is the new direction.

The two posts, with a combined view count of over 11 million, pushed the hottest discussion in the AI programming field to the next milestone.

The Rise of Loops

Over the past month, "Loop Engineering" has rapidly become a popular concept in the AI programming space.

But its true origins trace back a full year. In July 2025, software engineer Geoffrey Huntley proposed a method he called "Ralph" — a simple Bash loop that makes Claude repeatedly execute tasks until the goal is achieved:

while :; do cat PROMPT.md | claude-code ; done

The core of the Ralph method lies in bypassing the limitations of the context window. Back in mid-2025, the maximum context window size was 200,000 tokens. This was far insufficient for more complex tasks, so it became necessary to split agent execution into smaller runtime units and run them one by one.

Against this backdrop, the Ralph method operates as follows:

• Set a goal for the project, then keep running or re-running the agent until the goal is achieved.
• Persist completed work to the file system in a "compressed" form, such as saving it as logs or an updated plan.
• Launch the agent with a completely fresh context to minimize "context corruption".
• Allow each agent to add or modify the "overall plan" when necessary.

Huntley used this method to build a programming language from scratch, proving its feasibility. But it only spread rapidly among developers after more powerful models emerged.

The explosion of interest in loops also involved some core developers from Anthropic and OpenAI. It first started at Anthropic's developer conference, where Boris Cherny, the creator of Claude Code, stated: "I don't prompt Claude anymore. I run loops that prompt Claude and decide what to do next. My job is to write loops."

Shortly after, Peter Steinberger posted a call to developers to stop directly prompting programming agents: "Monthly reminder: you should no longer prompt programming agents yourself. You should design loops that prompt agents."

Former Google engineer Addy Osmani later wrote a dedicated article titled "Loop Engineering", summarizing it as: "Loop engineering is about stepping away from personally prompting agents, and instead designing a system that does that work for you."

With the concept and name in place, supporting infrastructure quickly followed.

From April to May 2026, Codex, Claude Code, and Hermes successively launched the /goal command, turning manually written loops into a single production-grade instruction.

About six months after Ralph began to be widely used, Codex released the goal feature

The Codex documentation states: "Goals are persistent objectives in Codex that allow a conversation thread to keep moving toward a clear outcome across multiple rounds of interaction. A Goal provides Codex with a completion condition: what state should be true, how to check for success, and which constraints must always be preserved."

The documentation specifically notes: "A regular prompt says: do this next. A Goal says: keep working until this outcome is true."

In a regular request, Codex processes the current instruction, reports the result, and waits for the next step. When using a Goal, a persistent objective is attached to the thread. After one execution round, it can check the current evidence and determine if the goal is completed. If the answer is no, and the Goal is still active and the budget has not been exhausted, Codex can continue working from the latest state.

For example: "Reduce the p95 latency in the checkout benchmark to under 120 milliseconds, while ensuring the correctness test suite always passes."

This is a sufficiently clear "stopping criterion" that can be handed directly to an agent. The agent will then split tasks on its own, create sub-agents, and keep running until the work is done. The Codex team drew inspiration from the Ralph loop idea to build the underlying infrastructure: coordinating multiple agents to prevent them from interfering with each other, managing state, running tests, starting and stopping agents, and later adding features like budget settings.

Architecture of the Goals feature

How Developers Are Using Loops

So what are developers actually using loops for? Based on community feedback, the most common scenario is handling periodic work.

But the capabilities of loops go far beyond that. What truly demonstrates the value of loop engineering are more complex, long-term tasks that require continuous iteration.

For example, completing large-scale code migration. Startup founder Rafel Mendiola needed to convert a React app to React Native. The traditional approach would be to create a large Epic and then split it into 50 to 100 tickets, and just setting up the infrastructure was daunting.

His alternative solution was to create a Skill that lets the agent identify migratable code blocks on its own, complete the conversion, and track progress, then put this Skill into a Cron scheduled task that runs every 30 minutes. Compared to managing a huge migration plan, this approach is much less cognitively demanding.

Next Stop: Graph

The question in Peter's tweet actually points to an evolutionary path.

A year ago, prompt engineering was the core skill. By 2025 to early 2026, the focus shifted to designing loops. And now, what Peter is pointing to is even further ahead: designing graphs made up of multiple loops — where each agent runs its own loop and is connected to others through dependency relationships.

The best reply in the thread under his tweet came from Luis Catacora: "Loops have a lot of fault tolerance. Graphs force you to acknowledge how much of the workflow isn't really modeled at all."

This statement captures the difference between the two paradigms. Loops let you postpone architectural design: let one agent handle all the work first, until it can no longer cope. Graphs require you to declare the entire structure upfront — who is responsible for what, which tasks depend on which other tasks, and what to do if a branch fails. Loops are delayed decisions; graphs are upfront decisions.

Shubham Saboo, senior AI product manager at Google and author of the Awesome LLM Apps repository (over 124,000 stars on GitHub), provided another breakdown, distinguishing two layers: "The long-lived Org Graph defines who is responsible for which domain and retains context; the Work Graph defines what needs to be done now, and can be split, merged, reordered, or disappear entirely based on evidence."

What on earth is a Graph, anyway?

Loops make agent behavior programmable. Graphs make agent organizations programmable.

One step further is dynamic agent organizations: during task execution, the graph rewrites its own structure.

Preston Holmes: There are at least two types of Graph that matter. The first is the one you showed, made up of long-lived agents that each cover a zone like a zone defense. The second is the Graph formed by the work that needs to get done. It's dynamic and constantly changing.

Shubham Saboo: The long-lived "Org Graph" determines who is responsible for each area and is in charge of retaining context. The "Work Graph" determines what tasks need to be completed now. As new evidence emerges, it can split, merge, reorder, or disappear entirely.

This is the key to production-grade multi-agent systems: there are actually two graphs running simultaneously.

Org Graph: Defines "who is responsible for what". It consists of long-lived agents, each responsible for a fixed domain, retaining the context, expertise, and tool permissions for that domain. The Org Graph is relatively stable, similar to the organizational structure of a company.

Work Graph: Defines "what needs to be done now, and how tasks flow". It constantly changes as tasks and new evidence emerge, and can be split, merged, reordered, or canceled entirely. The Work Graph is more like a project plan generated in real time.

Preston Holmes also believes both graphs are important, and they operate on different timescales. The Org Graph is pre-designed and deployed; the Work Graph is dynamically generated for each task and discarded after the task is completed.

If loops make agent behavior programmable, then graphs make agent organizations programmable. One step further is dynamic agent organizations — during task execution, the graph rewrites its own structure.

From writing prompts, to designing loops, to building graphs, the capability focus of AI programming is continuously shifting upward. Developers increasingly no longer need to worry about how to talk to a single agent, but instead need to think about how to design the collaborative structure between agents.

References:

https://x.com/i/trending/2077885008564646115

This article is from the WeChat official account "InfoQ" (ID: infoqchina), written by Tina, and published by 36Kr with authorization.