On 7 June 2026, Peter Steinberger posted a sentence that named something I’d already stopped noticing I was doing: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” A few days earlier, Boris Cherny — the Anthropic engineer who built Claude Code — had said almost the same thing on stage: his job isn’t writing prompts anymore. It’s writing loops.

I’ve been running an agent named Hermes on my home server for the better part of a year. Somewhere in the last few months, without giving it a name, I stopped opening a chat window and typing a request. I started writing a goal, walking away, and letting the agent keep going — checking its own work, retrying, and stopping only when the goal was actually met. Now that habit has a name: loop engineering.

For the rest of us: what a “loop” actually is

Every step up this ladder has solved the same complaint: the AI kept needing a human to push it forward. Prompt engineering was step one — you type a request, read the answer, type the next request. Every improvement lived in how well you phrased the ask.

Context engineering was step two — instead of just a better-phrased question, you hand the model the right material before it answers: the relevant file, a search result, a note from last week. Better output, same rhythm: you still press go each time.

Harness engineering was step three — you give the agent an actual workspace instead of a blank chat box: a checklist it can update, tools it can call, something that catches it when it makes a mistake. It can now grind through a genuinely long task without losing the thread. But you’re still the one who presses “run,” and you’re still the one who has to notice when it’s done, or stuck, or wrong.

A loop, in the plain sense, is just a program that keeps repeating a step until a condition is met. Loop engineering applies that idea to the agent itself: instead of you deciding when to run it again, you write the condition — “keep going until every test in this repo passes,” “check for new CI failures every morning and open a PR if you find one” — and the system runs the agent, checks the result against that condition, and decides on its own whether to go again. Nobody has to keep pushing it forward. The system pushes itself.

Five pieces, not one trick

Addy Osmani, who gave the practice its name, breaks a working loop into five recurring pieces. Automations are the trigger — a schedule, a cron job, a webhook — that starts a run without a person deciding to start it. Worktrees give each run its own isolated copy of the codebase (via git worktree), so several loops can work in parallel without stepping on each other. Skills are codified knowledge — a SKILL.md file that tells the agent how this project wants a task done, so it doesn’t have to relearn the house style every run. Plugins and connectors, built on the Model Context Protocol, let the loop reach outside the codebase — into a ticket tracker, a deploy pipeline, a Slack channel. And sub-agents split the work: one agent drafts, a separate one verifies, so the loop isn’t grading its own homework.

Underneath all five sits one more requirement: persistent memory. A loop that forgets what it tried last time just repeats its own mistakes; the ones that work keep state — a memory file, a board, a log — across runs.

Claude Code and Codex both ship some version of this shape. Claude Code has /loop and /goal commands that run across turns until a condition you wrote is satisfied, plus scheduled tasks and GitHub Actions integration for the automation trigger. Codex has an Automations tab and a triage inbox that does the equivalent job with different names. Same primitive, different command.

Why this is one floor above the harness, not a bigger harness

The distinction matters because it changes who’s doing the work. Prompt, context, and harness engineering are all skills that make you better at directing the agent. Loop engineering removes you from that position entirely — you’re not directing a run anymore, you’re designing the system that will direct many runs without you. That’s a genuine change in what the job is, not just a bigger version of the same job.

It’s also why the caveats attached to this idea are sharper than the usual “AI moves fast” hedging. Osmani is explicit about three of them. Token costs compound fast when a loop can spawn its own sub-agents and keep going unattended — a bad stopping condition doesn’t fail loudly, it just burns money quietly. Verification is now the whole job: a loop running unattended is also a loop making mistakes unattended, and the discipline that used to go into writing a good prompt now has to go into writing a good check. And there’s a subtler cost he calls comprehension debt — the faster a loop ships code you didn’t personally write, the bigger the gap between what’s in your repository and what’s in your head.

There’s a fourth risk worth naming that’s less about engineering than about habit: the temptation to stop having opinions once the loop mostly works, and just accept whatever it produces because pushing back takes more effort than approving. That one doesn’t show up in a token bill. It shows up months later, when nobody on the team can explain why the system does what it does.

What this means for how you govern it

This is the part that connects to the architecture question I spend most of my research on. A harness that a human watches turn by turn is, in governance terms, still supervised — a person is in the room when something goes wrong. A loop that runs on a schedule, spawns its own sub-agents, and reports back only when it’s done is not supervised in that sense at all. Nobody is watching the individual steps; the entire safety case has to live in what the loop is allowed to do, not in someone catching it mid-mistake.

That’s precisely the shift from process maps to permission boundaries I’ve written about before: specify the behaviour was the old contract, bound the behaviour is the new one. A loop needs a budget it cannot exceed, an escalation path for anything ambiguous, and an audit trail that can reconstruct what it saw, decided, and touched — not because loops are unusually dangerous, but because “a human was watching” stops being true the moment the loop is the whole point.

If your organisation is experimenting with autonomous coding loops, agentic pipelines, or scheduled agent runs, the question worth asking isn’t “is a person reviewing this.” It’s: what are the bounds inside which this loop may act unattended, and would you actually notice if it quietly exceeded them?

References

  • Addy Osmani, “Loop Engineering” (addyosmani.com, 7 June 2026) — origin of the term, the five-primitive framework, and the token-cost/verification/comprehension-debt caveats.
  • Peter Steinberger, public post, 7 June 2026 — “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
  • Boris Cherny, Creator & Head of Claude Code at Anthropic — on-stage remarks, early June 2026, on writing loops rather than individual prompts.
  • keller-ai — related: Stop Putting a Human in the Loop. Put the Right Human in the Loop.