Video version https://youtu.be/pxnY6T98G14

You may not realize it, but most developers today sit at their keyboards running a manual while loop without realizing it. You write a prompt, read the response, decide what to ask next, and repeat, over and over again. All day long, you are the thing that keeps the process moving toward the goal. When you step away to grab coffee or answer a Slack message, the loop stops because you’re not driving it forward.

Loop engineering moves that while loop out of your head and into code. Instead of you nudging the agent forward one turn at a time, the agent iterates on its own: it acts, observes the result, reasons about what happened, and repeats until the goal is met.

Boris Cherny at Anthropic put it plainly: “I don’t prompt Claude anymore. I have loops running that prompt Claude.”

In this article, we’ll cover where loop engineering is, the five building blocks that make it work, the three loop types organized by how long they run, the commands that ship in tools like Claude Code today, and the gotchas that will cost you money and sanity if you ignore them.

Where This Came From

The idea started as a joke that turned out to be serious. In mid-2025, Geoffrey Huntley coined the “Ralph Wiggum method”: a bash loop that does nothing fancier than continuously nudge an agent back toward its objective. You “just” wrap your agent in a while loop, feed it the same goal on every pass, and let it grind. Crude, but it worked well enough that people paid attention.

By spring of 2026, the major platforms had turned that pattern into a first-class feature. Codex created Goals while Claude Code shipped a /goal command in May. What started as a shell script became a supported command.

“Loop engineering” has been called a hot buzzphrase right now, but the concept underneath is real and worth understanding. So let’s ignore the branding and focus on the substance.

This is still a relatively new concept, so this article might be out of date before we even publish it.

The Five Building Blocks

Again, this is brand new, so a lot of these concepts are in flux, but a working loop setup can be broken into five components.

Automations are scheduled discovery tasks. You can think of this as a daily or weekly triage run, or an agent that analyzes every CI failure the moment it happens. Nobody kicks these off; they fire on a timer or on an event. My favorite example is to grab all the errors from our logs and then create issues for them so we can triage the results (or just pass them on if they’re an exception).

Git Worktrees are separate working directories so multiple agents can run in parallel without stepping on each other’s files. If you’ve ever had two processes fight over the same file, you understand why this matters. Essentially, each agent gets its own sandbox.

Skills are reusable project context stored in SKILL.md files. They codify the knowledge an agent needs about your project so you stop re-explaining the same conventions and processes on every run. The gap between what you meant and what the agent understood is sometimes referred to as “intent debt”, and skills are how you reduce it.

Plugins and connectors use MCP to link agents to the tools you already use like your ticketing system, chat, and your database. The agent stops being trapped in a text box and starts touching real systems so you can better interact with it.

Sub-agents split the work across separate agents, one for ideation and one for verification. Using a different agent to check the work guards against a single model believing its own bad ideas.

Three Loops, Three Timescales

The clearest way to organize loops is by how long they run.

Fast loops take minutes and generally involve a retry loop around an atomic task with a clear pass or fail signal. “Make these tests pass” is the classic example. The agent runs the tests, reads the failures, edits the code, and runs again until green.

Medium loops take hours and follow a plan-execute-verify rhythm for multi-step work. Examples of this involve refactoring a module or adding a feature. An engineer can point a medium loop at a suite of flaky tests and create 13 pull requests on its own, each one stabilizing a different test.

Finally, slow loops run for days or weeks and often react to events. For example, converted a PHP app to a PHP Native app on 30-minute cycles, letting the loop chew through the conversion while you do other things. Another common pattern is nightly end-to-end tests that attempt their own fixes before anyone arrives in the morning, so you walk in to green builds instead of red ones.

We’ll have more after this word from our partners.

The Commands

The tooling is catching up, and most of it groups into a few commands.

The /goal command sets a persistent objective with a completion condition. In Claude Code, once you set a goal, it checks after each turn whether that condition is met and keeps going until it is. You state the destination once instead of steering every turn.

The /loop command handles interval-based execution for recurring tasks. Point it at a job and a cadence, and it runs on schedule.

Worktrees give you the parallel isolation from before, so several agents work at once without collisions.

Skills, written as SKILL.md files, get loaded automatically. The agent pulls in your project’s conventions without you pasting them into the prompt.

Gotchas

Loop engineering gets expensive fast. Every iteration is an API call, and at per-token pricing, a loop that runs unattended overnight can burn through real money. It’s best to set an iteration limit before you start and not after your boss gets the bill.

There’s a subtler cost, and it’s the one that will kill you six months from now. Shipping faster widens the gap between what your code does and what you understand about it. The loop doesn’t know the difference between “I understand this” and “I shipped this.” You do, and that difference is your job to protect. It’s best to have a pull request process where you review the code so you can understand it and make sure nothing “terrible” is happening.

Long loops drift. An agent grinding for hours accumulates stale context and slowly wanders from the goal you gave it. Short loops with clear termination conditions beat ambitious open-ended ones almost every time.

Passing tests is not the same as a good solution. Green checkmarks tell you the code does something. Whether it does the right thing in a maintainable way is still human work. Verification did not go away; it moved to you.