Loop Engineering: What It Is, What It Caught, What It Missed

We build Askpert with coding agents, and what decides which work those agents pick up, and in what order, is a system we designed rather than a person typing prompts. In June 2026 that practice got a name, loop engineering, and running it has taught us precisely what it is good for and what it is not. This is a report from inside the practice: what the term means, what our loop caught, what it let slip past, and the honest limit.

What is loop engineering?

Loop engineering is replacing yourself as the person who prompts the agent, and designing the system that prompts it instead. It arrived as the successor to prompt engineering and context engineering, and it names the orchestration that decides what the agent works on, which is a different layer from the execution cycle that runs each individual turn.

The term crystallised in early June 2026 out of several people describing the same shift at once, rather than from a single coinage. Boris Cherny, who created Claude Code at Anthropic, described no longer prompting the model at all but having loops that run. On 7 June, Peter Steinberger of OpenClaw posted the sharper form: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." It passed five million views inside a day. The underlying technique is older than the name: Geoffrey Huntley's Ralph loop had been doing this in practice since mid 2025.

The vocabulary this post borrows comes from Loop Engineering by Addy Osmani. It lists the structural components as automations, worktrees, skills, plugins and connectors, and sub-agents, plus persistent state, and names five risks in the practice: intent debt, comprehension debt, cognitive surrender, the verification split, and the orchestration tax. Everything that follows is what those abstractions looked like when we ran them on real work.

Is loop engineering the same as the agent runtime loop?

No. The runtime loop is the execution cycle inside a single turn: the model emits a tool call, the runtime executes it, and the result returns so the model can decide the next action. Loop engineering is the layer above it, the system of stages that decides what the agent works on and in what order. Same word, different layer, and the two are routinely confused.

The runtime loop is real, and it is where execution-level reliability mistakes hide, from unbounded iterations to a tool output that blows the context window. Those belong to a separate discussion of runtime budgets and truncation. Loop engineering is a different subject. It is about orchestration: which stages run, what consumes what, and who verifies a claim before the next stage trusts it.

How does the loop that builds Askpert work?

This is how we build our own platform. It is our engineering process rather than something Askpert exposes to sellers, and it is the reason a small team can put a change through exploration, planning, adversarial review, implementation and a red team without a person driving each step by hand.

In order, the loop is: pull the main branch, create a fresh isolated worktree and verify its base is level with the tip, run exploration agents that map the code, write a phased plan, send that plan to two adversarial critics before any code exists, implement with agents that run sequentially when they share a worktree, simplify, write tests, run browser tests across two viewports, and finish with a red team that reviews the finished change against a checklist written before the review began. Every stage hands its output to the next, and that is what makes the whole thing a loop rather than a list.

What did the loop catch?

Our loop caught a months-old production bug at the last stage before shipping. We planned a phase to add an image library to our sandbox. The plan survived two adversarial critics and a local container build. The red team then ran the untouched base image and printed the version, which nobody upstream had done.

The library had been installed the whole time. It arrived as a dependency of another package, so it was never in our own install step. Our documentation had been telling sellers for months that importing it raised an error. The red team was the first stage to run the real artifact and check the claim against it. One command turned a planned feature into the discovery of a false description we had shipped for months.

What did the loop miss?

The more useful lesson is the miss. An exploration agent reported that our continuous integration never builds the container image. That sentence was copied into three planning documents as established fact, and a whole verification argument was built on it. It was false, and a single command disproved it. Neither adversarial critic questioned it.

Both critics read those documents and neither challenged the claim, because a critic's job is to attack the plan's reasoning, and by the time a finding reaches the plan it has become a premise rather than a claim. Adding adversarial review to a loop hardens the argument, not the premises. Verification has to be placed deliberately at the point where one agent's reading becomes the next stage's fact, and in our process that edge is exactly where nothing was checking. Drawing the pipeline as a graph makes those edges visible.

How do we treat "done" as a claim, not proof?

We require every implementer to prove its own tests can fail. It breaks the implementation deliberately, confirms the new tests go red, restores, and reports that it did so. A suite that was never shown to be capable of failing is not evidence, regardless of how green it runs.

On one change this rule surfaced a real defect: a security assertion covered only one of the two elements it claimed to protect. The test passed against the first element and said nothing about the second, which is exactly the failure a green-only suite would never expose. Proving a test can fail converts the suite from a promise into a checked claim.

What does the orchestration tax cost us?

The human stays the merge gate. Agents run the loop to green continuous integration and stop, and no agent merges. Review bandwidth is the real constraint, and we have not solved it. We have only made the work that arrives at a human more trustworthy, which is the honest definition of what the loop buys us.

Osmani names the orchestration tax as one of the costs of the practice, and we have felt it directly. The loop multiplies what a small team can produce, and it does not remove the human from the end of the process. Every change still stops at a reviewer, and that reviewer is the bottleneck. We have not changed the size of the bottleneck. We have only raised the quality of what reaches it.

How do we keep the loop from relitigating?

Our plans live in files beside the code, and every critic finding is recorded as accepted or rejected, with the reasoning, including the findings we rejected and why. That record is what stops the next session from relitigating a decision that was already settled.

State is the part of a loop that is easy to forget, because the loop's stages are ephemeral and the model that runs each stage starts cold. Persisting the plan and the verdicts next to the code means the next session inherits the reasoning, not just the outcome. The value is not the file itself. It is that a settled argument does not have to be argued a second time.

What is the honest conclusion about loop engineering?

Loop engineering multiplies output, and it does not replace judgment. The loop is better than prompting by hand mostly because it turns the job into a system with stages and checks. The evidence from our own runs is that the loop is strong at catching what lives in the artifact and weak at checking the premises it inherits.

Our catch was real: a bug that had shipped for months died at the last stage. Our miss was more instructive: a false premise sailed through two critics because nothing in the pipeline owned the edge where a reading becomes fact. The honest reading, and it is close to Osmani's own, is that the loop is a force multiplier, not a substitute for a judgment that knows which claims to verify and which stage to verify them in.