What is Loop Engineering?

Why loop engineering is just management

Hi friends,

This week Pete and I got into a question that's been lighting up X after the creater of Claude Code announced he’s stopped prompting his agents entirely. What are loops, and is this actually new? That's what this week's essay gets into.

Three things in AI for SMEs this week: why the cheapest way to scale your output is one you already know how to run, what the new wave of agent platforms means for businesses willing to move now, and the quiet failure mode that turns an unattended AI process into a liability.

Now to this week's Good Stuff.

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.

Three Things in AI for SMEs.

1. The agents that pay off are the narrow, repeatable ones — Margin Up

The 2026 question isn't whether to use agents but which ones return anything, and the answer is consistent - one predictable process, given real structure, with a human kept on the exceptions. A small agent setup can free 10 to 15 hours a week within 30 days for a typical SME, at under €200 a month. The rule for the year is to automate the predictable, delegate the repeatable, and keep humans on the genuinely novel. DominikgaborDominikgabor

What it means for you: The margin comes from structure, not a smarter model. Take the one process you couldn't hand a new starter without explaining, write that explanation down once, and you've built the agent's instructions and a reusable operating manual in the same stroke.

Dominik Gabor →

———————————————————————————

2. The bottleneck is now whoever can describe the work, not who can code — Capital Up

Building an agent no longer needs an engineer. No-code platforms let analysts and ordinary business users build and iterate through visual editors and plain language, without an engineering queue, a shift driven by a real shortage of engineers who can ship production systems. The scarce input is now the ability to describe your own processes clearly enough to hand them over. Rasa

What it means for you: The advantage is in the encoding. Every hour spent writing down how your business actually works becomes infrastructure you keep, and unlike a trained employee, an encoded process can't walk out the door.

Rasa →

———————————————————————————

3. The danger isn't the agent that crashes, it's the one that quietly drifts — Risk Down

Hand AI a whole process and the failure mode doesn't announce itself. Outputs can look confident while being wrong, and because they're acted on automatically and repeatedly, small errors compound. Oversight hasn't kept pace: Deloitte's 2026 survey of 3,200+ leaders found only 21% have a mature governance model for their agents, even as adoption approaches universal. Saidot Plain English

What it means for you: You can take the upside without wearing the risk. Build checkpoints into anything you automate, moments you pick in advance where the work stops and shows you what it's done, the way a manager holds a standup rather than watching every keystroke. This week's essay digs into why that drift happens. Unattended is not the same as hands-off.

The Compounding Problem →

That's all for this week.

If this resonated, we’d love for you to forward this newsletter to someone who might enjoy exploring these ideas too. See you next week!

Cheers,
Pete & Andy