Loop Engineering 是什么：从 Ralph 循环到 /goal

“Loop engineering” has become a trending topic in the past month, after some high-profile folks at Anthropic and OpenAI revealed that they have stopped writing prompts, and started designing loops. At Anthropic’s developer conference, Boris Cherny, creator of Claude Code, said (emphasis mine):

“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

Soon after, Peter Steinberger, creator of OpenClaw, preached loop design in a post:

Source: Peter Steinberger

Elsewhere, Addy Osmani, formerly of Google, wrote an article, ‘Loop Engineering’:

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

That’s three mentions in quick succession of this new approach, which is a novel one and therefore pretty abstract to me. To find out more, I turned online to some of the folks who read these articles. In replies, you told me what “loop engineering” means to you and gave some examples of loops in your work.

Today, we cover:

• Where it began: “Ralph Wiggum” loop. A year ago, software engineer Geoffrey Huntley shared how he builds “loops.” In December, the approach went viral and “Ralph loops” were born.
• The /goal command ships in all major harnesses. By May this year, the major AI coding harnesses added support to run a loop from a single prompt, using the /goal command.
• Loops which devs use: triggers and cron jobs. I asked devs how they use loops. Most use cases involve responding to events or running scheduled jobs. They are useful, but don’t feel like brand new workflows.
• Helpful loops for devs. Open PRs for newly-recorded app issues, have notes ready when an oncall joins an outage Slack channel, “babysitting” and fixing nightly end-to-end tests, and more.
• Disappointment and “tokenmaxxing”. Several devs reject looping after trying it. Agents drifting, and the “human in the loop” having better results are some reasons. Also, at companies that pay API prices for tokens, loop engineering gets expensive fast.
• Was looping a hack while tooling caught up? Distinguished engineer Max Kanat-Alexander believes the “loop” might have just been a temporary hack while the harnesses added the ability to do the same from a single prompt.
• Does “context engineering” matter more for devs? Except for engineers building AI infra, there seems little benefit in going deep into loop engineering. Instead, becoming familiar with AI context windows – also part of building loops – could be more useful.

1. Where it began: “Ralph Wiggum” loop

Exactly a year ago, software engineer Geoffrey Huntley published the article ‘Ralph Wiggum as a software engineer’. The name references the naive son of the local police chief in The Simpsons, who is extremely eager to always be helpful. In engineering, “Ralph” is intended to continuously nudge the agent in the right direction. Geoff described it:

“Ralph is a technique. In its purest form, Ralph is a Bash loop:

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

Ralph can replace the majority of outsourcing at most companies for greenfield projects. It has defects, but these are identifiable and resolvable through various styles of prompts.

That’s the beauty of Ralph - the technique is deterministically bad in a nondeterministic world.”

The article expands on the idea of the Ralph loop:

• Start the agent with a prompt that captures the task and defines a goal
• Create a plan of work, each item with a success criteria
• Start the loop:
• Take one item per loop
• When the agent is done, check if the goal is achieved
• If not: start the agent again, with a clear context window
• Start loops if needed: spawn subagents as and when necessary

Geoff published the experiments he did with this approach, such as building a new programming language last summer, and said it requires skill:

“Engineers are still needed. There is no way this is possible without senior expertise guiding Ralph. Anyone claiming that engineers are no longer required and a tool can do 100% of the work without an engineer is peddling horses***.”

The “Ralph method” blew up late last year with the arrival of better models which were surprisingly capable of building ambitious projects. Software engineer Matt Pocock created a tutorial, ‘Ship working code while you sleep’ with the Ralph Wiggum technique. He said:

“One of the dreams of coding agents is that you can wake up in the morning to working code, where your coding agent has worked through your backlog. It has spit out a whole bunch of code for you to review, and it works.”

Before the Ralph loop, Matt did this in two steps:

• Ask the agent to create a detailed plan for the work, with tasks broken out
• Then, in a sequential order, have the agent complete each subtask in a separate run

Pre-Ralph: The agent completes one step at a time in a single context window. Source: Matt Pocock

A problem with this approach is there’s no easy way to add new tasks to the “masterplan”. Software engineers know that most plans do need to be modified, often while the work is ongoing. In contrast, with Matt’s take on the Ralph method, the “masterplan” is continuously updated in a “master PRD”. Here’s the prompt he gives the agent:

• Choose the next feature: Find the highest-priority feature to work on and work only on that feature
• Have tests pass: check that the tests pass (via pnpm test)
• Update the master tracker: update the PRD with the work done
• Log work: append your progress to the progress.txt file
• Commit: make a git commit of the feature

This style of working is more of a “dynamic Kanban”:

“dynamic Kanban” style of working. Source: Matt Pocock

The “Ralph method” is all about working around context window limitations. Back in mid-2025, the maximum size of a context window was around 200,000 tokens. That’s not enough for more ambitious tasks, so it’s necessary to break up agent runs into smaller ones and run them, one by one. In this context, here’s where the Ralph method works:

• Have a goal for a project, and keep running (or re-running) agents until this goal is reached
• Persist work done in a “compressed” manner on the filesystem (as logs or an updated plan)
• Start agents with fresh context to minimize “context rot”
• Allow each agent to add or modify the “masterplan” if needed

2. The /goal command ships in all major harnesses

For a few months, building a Ralph loop meant doing it yourself: setting up the loop, state tracking, deciding how the agent can add tasks and when to stop. But things changed once coding harnesses made it easy to run these loops.

April: Codex ships /Goals

About six months after the “Ralph technique” started gaining wider traction, Codex shipped the “Goals” feature in Codex. From the documentation:

“Goals are persistent objectives in Codex that keep a thread working toward a defined outcome across turns. A Goal gives Codex a completion condition: what should be true, how success should be checked, and what constraints must stay intact.”

Also from the docs (emphasis mine):

“A normal prompt says: do this next thing.

A Goal says: keep working until this outcome is true. In a normal request, Codex works through the immediate instruction, reports a result, and waits. With a Goal, Codex has a durable target attached to the thread. After a turn finishes, it can inspect the current evidence and decide whether the objective is satisfied. If the answer is no, and the Goal remains active and within budget, Codex can continue from the latest state.”

A visual representation:

Goals vs prompts. Source: OpenAI

Here’s an example of using a goal in Codex:

/goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green