In the first week of June 2026, three people said roughly the same thing within days of each other. Peter Steinberger: "you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny of Anthropic's Claude Code team: "I don't prompt Claude anymore. I have loops running that prompt Claude… My job is to write loops." And on June 7, Addy Osmani published the earliest post I can find that uses the exact phrase — "Loop Engineering": "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." He placed it "one floor above the harness." Nine days later LangChain formalized it in "The Art of Loop Engineering".
I read all of this with an odd feeling. Since mid-April I had been running a system that matches these descriptions almost clause for clause: an append-only changelog with 97 entries in ten weeks, a pre-change guidance doc with an intervention ladder and evidence thresholds, an eval suite, and a coding agent that loads all of it automatically at the start of every session and executes the process on my behalf. I didn't have a word for it. I called it "the process."
So here is my claim, up front. The practice is older than the name — not just my ten weeks older, but years older. And the parts of the practice that have mattered most for me — evidence gates, append-only memory, measuring whether the process is being followed at all — aren't in the name. They aren't in most of the June posts either.
Where the name came from
The lineage everyone recites goes: prompt engineering, then context engineering (2025), then harness engineering, then loop engineering. Harness engineering got its canonical post in February 2026, when OpenAI described the harness as "everything except the model" and offered the memorable design principle that "the best harness components are designed to be deleted." Loop engineering, in the June framing, sits above that: not the scaffolding around one agent run, but the system that decides when runs happen and what to do with the results.
The ancestors are older. Anthropic's "Building Effective Agents" (December 2024) defined agents as "LLMs using tools based on environmental feedback in a loop" — the loop was the definition from the start. Geoffrey Huntley's Ralph loop (July 2025) was the reductio made real: literally while :; do cat PROMPT.md | claude-code; done, and it shipped working software. Simon Willison's "Designing agentic loops" (September 2025) named the skill without coining the phrase.
There is a backlash worth taking seriously. It goes, roughly: loop engineering is just software engineering. Feedback loops, verification steps, versioned process, incident writeups — none of this is new, and dressing it in a new coinage mostly generates conference talks. I think the backlash is right about the mechanics and wrong about the economics. The mechanics are old. What changed is that the machine executing your process now costs cents per invocation and doesn't get bored, which changes which processes are worth writing down. A weekly review checklist that no human reliably runs becomes a different artifact when an agent runs it every session.
Two senses of the same phrase
The phrase is already circulating in two sizes, and they get conflated.
The dominant June sense is the outer orchestration layer: systems that prompt, schedule, verify, and re-trigger agents so that a human no longer does. Steinberger's and Cherny's quotes are squarely in this sense. It is about removing yourself from the dispatch position.
LangChain's post goes further. They describe a four-loop stack: the agent loop (the model calling tools), the verification loop (checking outputs), the trigger loop (deciding when to run), and a fourth loop that "runs an analysis agent over those traces and uses the findings to rewrite the harness." Their summary line is the one that made me sit up: "The first three loops automate work. The fourth automates improvement."
Only LangChain folds the improvement flywheel into the term. And that fourth loop already had names — established ones, with practitioners. Hamel Husain has been arguing for years that "error analysis is the single most valuable activity in AI development". Eugene Yan was writing about eval-driven development in 2023. Shreya Shankar and NVIDIA's platform teams have both written about the data flywheel. The fourth loop is those practices, executed by an agent instead of a person.
To be explicit: when I say loop engineering in this post, I mean the LangChain-extended sense, fourth loop included. The narrower sense — orchestration without improvement — is a different and, I'll argue, less interesting thing.
What I built in April, in June's vocabulary
The system underneath all this is a production data agent: users ask plain-English questions about an operational dataset, and the agent answers from pre-computed metrics or falls back to generated SQL. From mid-April, I ran a disciplined improvement loop on its harness. Mapped onto LangChain's stack:
Loop 1 existed from day one — the agent's own tool loop, choosing between the metric store and the SQL path.
Loop 2 is the eval suite: a fixed question set scored by a multi-dimensional judge, so a change to the harness produces a number, not a vibe.
Loop 4 is the changelog-driven hill climb. Every change follows the same shape: a signal (eval regression, user report, trace anomaly), a root-cause investigation, one scoped change at the lowest effective rung of an intervention ladder, then verification against the suite. Each cycle becomes a changelog entry — 97 of them in ten weeks. The whole procedure lives in a guidance doc that the coding agent loads automatically, so the process runs even when I'm tempted to skip it.
Loop 3 I did not build. My loop runs when a human starts a session. The guidance doc contains a "weekly review" section that is, honestly, a promise written in prose — there is no trigger, no schedule, nothing that fires without me. In the June taxonomy this is the layer I'm missing, and I think that's the correct reading: it's the system's real gap, not a badge of artisanal restraint.
Here is what having the loop bought me. This week my eval pass rate collapsed from 67% to 32% between runs. The reflex — my reflex, in April — would be to assume an agent regression and start bisecting prompt changes. But the guidance doc's first rule for any regression is: verify ground truth before diagnosing. So the first step was checking whether the questions were still answerable at all. They weren't. The test tenant's data had vanished from the environment. Diagnosis took one session; zero changes were made to the agent; the eval run was rerun against a tenant with real data and passed at the old rate.
That rule isn't wisdom I imported. It was extracted from an April failure in which I chased a phantom regression through four changelog entries — four investigations, four scoped changes, four verifications — before anyone checked whether the underlying data existed. The failure went into the changelog. The rule went into the guidance doc. The loop rewrote its own harness. That is the fourth loop doing exactly what LangChain says it should, two months before their post said it.
The quadrant the name leaves out
The June discourse centers on automating work: spawn agents, verify their output, re-trigger on events, scale the fleet. That's real. But the underexplored quadrant is pointing the loop at the harness itself, and everything durable in my system lives there.
Concretely, four things:
Versioned process docs. The guidance doc carries a version number, and changes to the process get changelog entries like any other change. The process is an artifact under the same discipline as the code.
Evidence thresholds that vary by change type. A deterministic code change needs one reproducible failure and a test. A prompt or prose change needs multiple independent failures before it's allowed, because prose changes are cheap to make, hard to verify, and prone to fixing one case while silently breaking three. Same loop, different gates.
Append-only memory that keeps its mistakes. Reverted changes stay in the changelog, marked reverted. The four wasted April entries were never cleaned up — they're the evidence that justifies the ground-truth rule. A memory that only remembers successes can't teach the loop anything.
Measuring the process, not just the agent. Periodically I count what fraction of changes landed at each rung of the intervention ladder. If everything is landing at the prompt-edit rung, the discipline is drifting, whatever the eval number says. The eval measures the agent; the layer mix measures me.
None of this appears in the name "loop engineering," and most of it doesn't appear in the June posts. Which matters, because loops that only automate work amplify whatever process you already have. If your process is "edit the prompt until the vibes improve," a trigger loop gives you that at machine speed, unattended, at 3 a.m. Loops that audit the process are what make the amplification safe.
Names do matter. A name makes a practice discussable, teachable, and hireable-for; "prompt engineering" was a job title within a year of being a phrase, and I expect "loop engineer" postings before this year is out. I'm glad the name exists. But if you're waiting for the discourse to settle before building one of these, the whole point of my ten weeks is that you shouldn't. A changelog, a rules doc, an eval, and an agent that reads all three at session start — that's an afternoon of setup and it compounds from the first entry.
The name arrived in June. The loop had been paying rent since April — and the rent was paid in the parts the name leaves out.