Loop Engineering When You Stop Prompting the Agent and Start Building the System That Does

For about two years, getting useful work out of a coding agent meant sitting in the chair. You wrote a prompt, read what came back, judged it, and typed the next thing. You held the tool the whole time, one turn after another. That was the job, and people got good at it.

Sometime in mid-2026 the job changed names. The thing people now call loop engineering is the shift from being the person who prompts the agent to being the person who designs the system that prompts it. Instead of you typing the next instruction after every response, a small system finds the work, hands it out, checks the result, writes down what got done, and decides what to do next. You build that system once. Then you let it poke the agent instead of poking it yourself.

This post walks through what the term actually means, where it came from, who is pushing it, how the pieces fit together, and where it goes wrong. We will also be honest about the part most of the hype skips: a loop running unattended is a loop making mistakes unattended, and that changes what your job is rather than removing it.

Loop engineering is building a system that prompts your agent on a schedule and against a goal, instead of typing each prompt yourself. The leverage moves from the quality of a single prompt to the design of the system that generates and verifies prompts.

A useful way to picture it: a coding agent already runs an inner loop on every turn. It reasons about what to do, takes an action like editing a file or running a test, observes the result, then loops back and reasons again against the new state. That perceive, reason, act, observe cycle is the agentic loop, and it has been there all along.

Loop engineering sits one floor above it. You are no longer steering each turn by hand. You are building an outer loop that runs on a schedule, spawns helpers, feeds itself work, and keeps going across many of those inner cycles without you in the seat for each one.

It helps to see loop engineering as the third layer in a stack that has been building for a few years. Each layer wraps the one inside it, and each one moves the point of leverage a little further from the raw model call.

Prompt engineering came first. You optimized how you phrased a single instruction. The unit of work was one turn you typed by hand.

Context engineering came next. You stopped obsessing over the wording of the prompt and started managing everything else in the window: the docs, the history, the tool definitions, the files the model could see. The unit of work became the conditions around one answer.

Loop engineering is the layer on top. You optimize the system that decides what to prompt and when, and whether the result is acceptable. The unit of work is a self-running cycle across many turns.

You cannot tell the story of loop engineering without telling the story of Ralph, because the fancy version is just Ralph with better tooling.

In July 2025, the engineer Geoffrey Huntley named a pattern after Ralph Wiggum, the Simpsons character who is not especially bright but never quits. A Ralph loop is a coding agent running inside an infinite shell loop. Each iteration reads the same prompt file, modifies the codebase on disk, and uses the file system instead of conversation history as its memory. Every iteration starts with a fresh, clean context window. State survives between iterations through the codebase itself, a TODO file, and git history.

“

Dumb things can work surprisingly well.

- the lesson of Ralph, as the technique spread through the agentic-coding community in mid-2025

The reason it works is the part worth keeping. Ralph stores state in the external file system and git, not in the context window. That one decision decouples the life of the loop from the limits of the model's memory.

That makes the pattern unusually good at long jobs that no single context window could hold: large refactors, library ports, legacy migrations. There is one more trick that makes Ralph more than a toy. Coding agents like to declare victory early. They stop the moment they decide the task is done, whether or not it actually is. Ralph implementations get around this by refusing to take the agent's word for it.

The Ralph pattern stayed a community technique through late 2025. The broader name showed up in June 2026, popularized by the Google engineer Addy Osmani in an essay called "Loop Engineering." He built on a line from Peter Steinberger, who argued that you should be designing loops that prompt your agents rather than prompting them by hand, and on comments from Boris Cherny, the Claude Code lead at Anthropic.

“

I no longer prompt the model directly. I write loops that run and prompt the model and figure out what to do - and writing those loops is now the job.

- the Boris Cherny framing, paraphrased

The thing to notice is what he is not saying. He is not saying coding got easier. He is saying the highest-value work moved. A well-designed loop multiplies a good engineer. A badly designed loop multiplies a bad decision just as fast, with less of you watching.

A loop that holds together needs five things, plus one place to remember state. The names differ between tools, but the shape is the same everywhere.

Put the pieces together and a single thread turns into a small control panel. A sensible first loop looks like this.

This is the part the breathless takes skip, so we will spend real time on it. A loop changes the work. It does not delete you from it. Three problems actually get sharper as the loop gets better.

“

Two people can build the exact same loop and get opposite outcomes. One moves faster on work they understand deeply. The other stops understanding the work at all. The loop cannot tell the difference. You can.

Here is where the pattern stops being a developer curiosity and starts being an operations question, which is the part most of the coverage misses.

A loop is easy to stand up and hard to keep honest. Standing one up is a weekend project. Keeping it producing reliable work for the next year, without quietly accumulating risk, is a different discipline entirely. It needs verifiers you actually trust, sensible limits on how often it runs and how much it spends, captured knowledge that stays current, and the security plumbing to let an autonomous process touch real systems without becoming a liability.

That is the same gap that swallows most AI projects. They stall not because the model was wrong, but because no one built the operations, instrumentation, and governance to sustain it after go-live. A loop makes that gap concrete. The demo is the bash script that ran once and produced something impressive. Day Two is the loop still running in March, touching production, spending tokens, opening pull requests while you are asleep, and either earning its keep or compounding small errors into large ones.

This is the People, Process, Platform order, applied to autonomy.

“

A loop built by someone who intends to remain the engineer is leverage. A loop built by someone trying to stop thinking is a slow-motion incident.

If you take one thing from all of this: build the loop like someone who intends to stay the engineer, not just the person who presses go.

You do not need a platform to try this. You need a small, well-specified, mechanical task with a clear pass or fail condition. A file you have meant to clean up. A migration with a test suite that tells you when it is done.

Get those habits right on something small, and the larger version is the same shape with more pieces. Get them wrong, and a bigger loop just gets you to the wrong place faster. The technique is genuinely useful. The discipline around it is what decides whether it pays off.