In July 2026, the AI programming field underwent a major shift. Peter Steinberger announced on X that the era of loop engineering had ended, guiding the industry toward graph engineering. Loop engineering originated from Geoffrey Huntley’s Ralph method, which bypassed context window limitations by keeping AI agents running continuously until a goal was achieved. Between April and May 2026, tools such as Codex and Claude Code introduced Goal features, commercializing loop-based approaches. The industry is now exploring more sophisticated graph engineering, involving the coordinated design of organizational graphs and workflow graphs.

Article author and source: WeChat Official Account InfoQ (ID: infoqchina)

Are we still discussing loops, or have we already moved on to graphs?

On July 18, 2026, Peter Steinberger quietly announced the end of the circular engineering era with a single post on X. The post garnered 2.6 million views within two days of being published.

Six weeks ago, he garnered 8.4 million views with "Designing Cycles to Prompt Agents," making developers worldwide realize that the era of prompt engineering is passing, and cycle engineering is the new direction.

Two posts, with a combined view count exceeding 11 million, pushed the most heated discussions in AI programming to the next level.

The Rise of Circulation

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

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

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

The core of Ralph's approach is to bypass the context window limit. In mid-2025, the maximum context window was 200,000 tokens, which was far insufficient for more complex tasks; thus, agent operations needed to be divided into smaller units and executed sequentially.

Under these circumstances, the way Ralph's method works is as follows:

• Set a goal for the project, then continuously run or rerun the Agent until the goal is achieved.
• Persist completed work to the file system in a "compressed" format, such as saving it as a log or an updated plan.
• Start the Agent with a completely new context to minimize "context corruption."
• When necessary, allow each Agent to add or modify the "overall plan."

Huntley used this method to build a programming language from scratch, validating its feasibility. However, it only gained rapid traction among developers after stronger models emerged.

Loop's popularity also stems from key developers at Anthropic and OpenAI. At Anthropic’s developer conference, Boris Cherny, the creator of Claude Code, said: “I no longer prompt Claude directly. Instead, I run loops that prompt Claude and determine what to do next. My job is to write the loops.”

Subsequently, Peter Steinberger also posted, urging developers to stop directly prompting programming agents: “Monthly reminder: You should no longer personally prompt programming agents. You should design loops that prompt agents.”

Former Google engineer Addy Osmani later wrote an article titled "Loop Engineering," summarizing it as: "Loop engineering means stepping out of the role of personally prompting an agent and instead designing a system that accomplishes this task for you."

The concept is established, the name is set, and the infrastructure is quickly following suit.

In April to May 2026, Codex, Claude Code, and Hermes sequentially introduced the /goal command, turning manually written loops into a single instruction.

Six months after Ralph began widespread use, Codex released the goal feature.

The Codex documentation states: "Goals are persistent objectives within Codex that enable a conversation thread to consistently progress toward a defined outcome across multiple interactions. A Goal provides Codex with a completion condition: what state should be achieved, how to verify success, and which constraints must always be maintained."

The document specifically states: "A regular prompt expresses: 'Do this next.' A goal expresses: 'Keep working until this outcome is achieved.'"

In a standard request, Codex processes the current instruction, reports the result, and then waits for the next step. When using a Goal, a persistent objective is attached to the thread. After each execution round, it can evaluate the current evidence to determine whether the goal has been achieved. If the answer is no, and the Goal remains active with sufficient budget remaining, 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 directly handed off to an Agent. The Agent will then autonomously break down the task, create sub-Agents, and continue running until the work is complete. The Codex team drew inspiration from the Ralph cycle to build infrastructure that coordinates multiple Agents, prevents them from interfering with each other, manages state, runs tests, and starts and stops Agents—later adding features such as budget settings.

Architecture of the Goals feature

How can developers use loops?

What are developers actually using loops for? According to community feedback, the most common use case is still handling periodic tasks.

But the power of circularity goes even further. The true value of circular engineering is demonstrated in more complex, long-term tasks that require continuous iteration.

For example, completing a large-scale code migration. Startup founder Rafel Mendiola needed to convert a React application to React Native. The traditional approach involved creating a large Epic and breaking it down into 50 to 100 tickets—just setting up the infrastructure was daunting.

His alternative was to create a Skill that enables the Agent to autonomously identify translatable code blocks, perform the conversion, track progress, and then integrate this Skill into a Cron job that runs every 30 minutes. Compared to managing a large-scale migration plan, this approach is far more cognitively manageable.

Next stop: Graph

Peter's tweet issue actually points to an evolutionary path.

A year ago, prompt engineering was a core skill. By 2025 to early 2026, the focus shifted to designing loops. Now, what Peter points to is even further ahead: designing graphs composed of multiple loops—where each agent runs its own loop, connected through dependencies.

The most insightful reply to his tweet came from Luis Catacora: “Cycles have a lot of tolerance for error. The diagram will force you to acknowledge how much of your workflow hasn’t actually been modeled.”

This sentence highlights the difference between these two paradigms. A loop allows you to defer architectural design: start with a single Agent handling all tasks until it can no longer cope. A graph, however, requires you to define the entire structure upfront—specifying who is responsible for what, which tasks depend on others, and what to do if a branch fails. A loop is about delaying decisions; a graph is about making decisions in advance.

Shubham Saboo, Senior AI Product Manager at Google and author of the Awesome LLM Apps repository (with over 124,000 stars on GitHub), provided another breakdown, distinguishing two levels: “The organizational chart defines who is responsible for which domain and retains context; the work chart defines what needs to be done currently and can be split, merged, reordered, or disappear entirely based on evidence.”

What exactly is Graph?

Loop makes an Agent's behavior programmable. Graph makes an Agent's organization programmable.

The next step is dynamic agent orchestration: during task execution, the Graph rewrites its own structure.

Preston Holmes: At least two graphs are important. The first is the graph you showed, composed of long-standing agents that each oversee a specific area, like a zone defense. The second is the graph formed by the tasks that need to be completed—it’s dynamic and constantly changing.

Shubham Saboo: The long-standing "organizational map" determines who is responsible for each area and ensures context is maintained. The "work map" determines what tasks need to be completed right now. As new evidence emerges, it can split, merge, reorder, or disappear entirely.

This is key to a production-grade multi-agent system: in fact, two graphs are running simultaneously.

Org Graph: Defines "who is responsible for what." It consists of persistent Agents, each assigned to a fixed domain, retaining context, expertise, and tool permissions for that domain. The Org Graph is relatively stable, similar to a company’s organizational structure.

Work Graph: Defines “what needs to be done now and how tasks flow.” It evolves dynamically with new tasks and evidence, allowing tasks to be split, merged, reordered, or canceled directly. The Work Graph functions like a real-time generated project plan.

Preston Holmes also believes both diagrams are important and operate on different time scales. The organizational diagram is pre-designed and deployed; the working diagram is dynamically generated for each task and discarded after the task is completed.

If loops make an Agent’s behavior programmable, then graphs make an Agent’s organization programmable. The next step is dynamic Agent organizations—during task execution, the graph rewrites its own structure.

The focus of AI programming is continuously shifting upward—from writing effective prompts, to designing loops, and now to building graphs. Developers increasingly need not worry about interacting with individual agents, but rather about designing collaborative structures between agents.