WTF Is Loop Engineering?

This week, X has been abuzz over loops. Boris Cherny, the creator of Claude Code, came out and said that he doesn't prompt his agents anymore. He builds loops that prompt the agents for him. Peter Steinberger, the creator of OpenClaw, also declared that prompt engineering is officially dead and the idea of 'loop engineering' started to gain momentum.

So this week on The Good Stuff, Pete and I dived into a question. WTF are loops?

Peter Steinberger, creator of OpenClaw

What are Loops?

It's worth slowing down on some of these definitions though, because once you drill down into it, the underlying practice is far older than the new vernacular suggests, and the interesting question is why it's surfacing now.

For the last couple of years we've tended to work with agents by focusing on writing good prompts, sharing as much useful context as possible, and then holding the agent's hand as it did the work. You prompt, it sends you some work to review, you write a new prompt and so on. Some people like to call this Prompt Engineering.

According to Cherny and Steinberger, that's over now.

Loop engineering is replacing yourself as the person who prompts the agent. Instead, you design the system that does the prompting for you. So, a loop in this context can be thought of as a recursive goal where you define a purpose and the AI continues until some termination condition is met, i.e. a task is complete, a stopping criterion triggers, or the agent determines it can't go any further.

In other words, loop engineering replaces manual prompting with goal-based automation.

A loop essentially bundles four things. There's a trigger that starts the work, a goal written as a condition the agent can check, a procedure the agent repeats, and a test that decides when the output is acceptable.

You build the loop once, and then the loop runs without you. You stop attending the work. You don't stop owning it.

It's natural too that loop engineering is emerging around coding.

Coding is naturally iterative. Even the best coders don't tend to write flawless code on their first try. They run it, identify the errors, fix them, and then run it again. An agent that generates code once and stops can't do that. A loop gives the agent the same run-and-fix cycle that the coder always had.

Loops aren't only for code. They apply anywhere work repeats and has a checkable definition of done, an inbox that needs triaging, a weekly report that needs assembling, invoices that need chasing until they're paid.

So, loop engineering is the discipline of designing iterative work you won't personally be present for.

Loops Aren’t Actually New

What's interesting is that we've always had a name to describe this kind of work, organisational design, the discipline of specifying how work should run when you can't check every decision yourself.

Job descriptions, standard operating procedures, definitions of done, escalation rules and review cadences are all the same artefact, judgement compressed into something that runs while the author is elsewhere.

The loop engineers have, as Pete put it on the pod, discovered being a team leader.

Herbert Simon built half of modern organisation theory on the observation that attention is the scarce resource in any delegation. A founder who could attend every decision wouldn't need management at all. Decisions multiply faster than attention, so intent has to be compressed into documents and rules that keep working when the person who wrote them isn't around.

Ronald Coase asked in 1937 why companies exist at all, when in theory you could hire every task on the open market. His answer was that the market route is exhausting. Every task would mean finding the right person, agreeing a price, and writing a contract. Companies exist because it's cheaper to hire people and simply direct their work.

Stafford Beer's management cybernetics made the engineering version of this explicit in the 1960s, modelling the firm as a set of nested feedback loops, complete with sensors, comparators, and correction signals. Sixty years ago, the firm was already being drawn, literally, as a set of loops.

If this is just management, why did nobody build loops before, and why does it feel like an invention to the people doing it?

The answer is, we did. Every piece of management wisdom was worked out under old conditions.

A worker cost a salary, a feedback cycle took a fortnight, and hiring and firing were slow and painful. AI has changed those conditions.

A worker now costs whatever the tokens cost, a feedback cycle takes minutes, and you can spin an agent up or shut one down without a single hard conversation.

What Loops Won’t Do

There are a few things loops won't do. They will change how you work but you still have an important role to play in that work, just like the team leader.

You still need to check the work. Every decision an agent makes inside a loop is a coin toss, and a loop running unattended can make hundreds of tosses before you see anything. Most will land fine. A few will be slightly off, and slightly off compounds.

Good loops handle this with checkpoints, moments you pick in advance where the loop stops and shows you its work. A manager runs the same play. They don't watch anyone type, they hold a standup. The checkpoint is your standup, you just scheduled it before the loop ever ran.

Judging what comes out of the loop is still human work, and it didn't get any cheaper while generation collapsed in price. The bottleneck has moved from generation to selection, and the job splits cleanly into the two halves managers should recognise, designing the loop up front and reviewing what it produces.

You Already Know How to do This

One implication of all of this is an inversion of the expected skill hierarchy.

The prompt engineering era rewarded people who were good at talking to models. The loop era rewards people who can design operating systems for work, and that capability lives disproportionately in experienced operators, ex-managers, and process designers.

Their prior art transfers almost intact.

So do the failure modes. Loops that outlive their purpose will reproduce bureaucratic sclerosis. Termination tests that proxy for quality will be gamed by agents exactly as metrics are gamed by employees, a straight application of Goodhart's law. One human reviewing fifty concurrent loops will likely hit span of control limits that organisational theorists identified decades ago, somewhere around seven direct reports.

The best loop engineers in the country have probably never heard the term. They're running teams, writing procedures, and onboarding graduates, and almost all of it transfers. Boris Cherny stopped prompting and became a manager. He just didn't call it that.

We got into this and more this week in the Big Episode 61 of The Good Stuff.