A few years back the skill had one name: prompt engineering. You rewrote a sentence until the model did the thing. Last year the same corner of the job picked up a new name, context engineering. This year the threads call it loop engineering, and the line repeated under it is the verifier is the bottleneck, not the model anymore.
Every rename draws the same reaction from the same developers: is this a real shift, or the same work with fresh paint so someone can sell a course. That reflex is usually right. Most AI-tooling vocabulary turns over faster than the problems it describes.
So here is the read, one rename at a time. At each step, the thing you were actually engineering changed. What changed was the unit of work, not the marketing around it. The problems the newest name points at have a dated, public record. The dates are on the articles; the arithmetic is yours to do.
The unit was a prompt
Call it 2022 through 2024. The unit of work is a single prompt. You engineer the wording of one request: few-shot examples, a role frame, think step by step, the ordering of the ask. The entire surface you controlled was the text of one message, and the craft was getting that message right.
That discipline is not gone. It is no longer the whole job, because the whole job stopped fitting in one message.
The unit became the surface
Around mid-2025 Andrej Karpathy put a name on what people were already doing: context engineering. The unit stopped being a message and became everything in the window: the system prompt, the retrieved documents, the tool definitions, and the CLAUDE.md / AGENTS.md instruction files that ride along on every single turn. You are no longer tuning a sentence. You are curating a surface.
That surface has a property developers kept rediscovering the expensive way: most of what you put on it does not couple to behavior. The State of AI Instruction Quality pointed a deterministic analyzer at 28,721 repositories and found the median instruction file carries 50 content items and 12 actual directives, and the rest is headings, context, and structure the model is free to ignore. A sharper failure mode got its own writeup. Do NOT Think of a Pink Elephant shows how a constraint phrased as a negation (do not use mocks) can raise the odds of the exact thing it forbids, for the same reason the title just did to you.
Both of those are context-engineering problems, measured and published.
The unit is the loop
June 2026, the term is loop engineering, popularized by Addy Osmani synthesizing Boris Cherny and Peter Steinberger, and everywhere on the timeline within a few weeks. The unit is now the running loop: generate, check, steer, retry, stop. The prompt is one node in it. The context surface is the state it carries between iterations. The claim repeated across every explainer is that the model is no longer the limiting part. The check that decides good enough, stop is.
Take the name generously. It points at something the two earlier names left implicit: the mechanism that decides whether an iteration was any good and whether to run another. That mechanism was always present; every agent that retries has one. Loop engineering's contribution is making it the object you engineer instead of a default you inherit.
Prompt engineering tuned node one. Context engineering curated the state feeding it. Loop engineering points at the diamond, and that is where the interesting question hides.
A verifier that checks what, exactly?
The verifier is the bottleneck is a good slogan and an incomplete one. It names the bottleneck without saying what the verifier is supposed to check, and that gap is the engineering problem the slogan skips.
There are two kinds of check, and they are not interchangeable. A deterministic check runs the code, asserts the exit status, scans for the forbidden import, and returns the same verdict for the same input every time, with no judgment in the middle. A model-graded check asks another model is this good? The second reaches criteria the first cannot express, like is this explanation clear or does this read as rude, and it pays for that reach by inheriting the exact unreliability the loop was built to contain. You have put a probabilistic judge in charge of deciding when the probabilistic generator is finished.
Watch where they diverge on a real loop. An agent is told to refactor a module and stop when the work is done. A deterministic verifier can prove the test suite still passes and no banned import crept in. Those are facts, checkable on every iteration, with no argument about them. It cannot decide whether the refactor was worth doing, so a model-graded check gets bolted on to answer that, and now the stop condition rests on one model grading another's taste. The loop terminates when the judge is satisfied, and the judge is the same class of component the loop exists to supervise. Neither check is wrong. They answer different questions, and confusing which question you asked is how a loop stops confidently on the wrong iteration.
That trade-off, what the check actually checks, is the content of the verifier, and it is not a new problem. Green Tests Don't Mean Better Software works the CI version of it: a green test proves the code conforms to its spec and says nothing about whether the change improved the system. The check answered a question you never asked. Aim the same distinction at an agent loop instead of a test suite and you have the loop-engineering question stated for a case every developer already trusts.
What the earlier articles measured
Three articles published earlier in 2026 each worked one piece of this problem.
CLAUDE.md: Check, Score, Improve & Repeat, 27 January 2026, describes a loop run over an instruction file: score it, change it, score it again. Do NOT Think of a Pink Elephant, 31 March 2026, shows a single steering instruction that produces the opposite of its intent, and names the mechanism behind it. The State of AI Instruction Quality, 21 April 2026, analyzed 28,721 repositories and found that most of a typical instruction file is content the model can ignore rather than directives it has to follow.
Between them they cover the three problems loop engineering now names: what the verifier checks, steering that drifts, and instructions that do not couple to behavior. None of the three used the term. The dates are on the links, and they are the whole of the evidence.
What the new name solves
Loop engineering gives you two things worth having. It makes the check an explicit object of engineering, something you design and revise on purpose instead of a default you inherit from whatever your agent framework happened to ship. And it gives the verifier question a name, so teams can argue about it directly: what should this check check, and can it be deterministic.
Both are important, and both have an edge worth stating plainly. The name hands you the object. Building the verifier is still yours to do, and it is most of the work: deciding what correct means for a task, then turning that into a check you can run.
Part of that work is choosing the kind of check. A criterion like is this explanation clear needs a model to judge it. A criterion like no banned import is a deterministic scan. The cost of picking wrong runs both ways: a model-graded check where a deterministic one would do buys unreliability for nothing, and a deterministic check standing in for a judgment it cannot make gives you a green light that means less than it looks like. The name makes that choice visible and leaves it in your hands.
Underneath the frame, the generator still guesses. What loop engineering adds is a place to put the check and a reason to take it seriously, which is more than the earlier names offered the same problem.
The loop, one part at a time
The vocabulary will change again. Harness engineering was an intermediate name for part of this, and something will come after loop engineering too. Each time the word changes, the useful question is the same: what is the new unit of work, and what is the hard part inside it?
For loop engineering the unit is the loop, and the hard part is the verifier: what it checks. The verifier is one component of several, and a name that points at the whole loop is easy to nod along to and harder to act on. So the plan from here is to take the loop apart a component at a time and put a measurement under each one. The questions this piece raised are the ones the next few pieces go after:
- A check that fires on the wrong thing comes back quiet, and so does a signal that was never there. They look identical from the outside. How do you tell a broken instrument from an absent one, before you conclude that the problem you were checking for does not exist?
- Not every rule in the loop is a verifier, and the rules that steer are not the rules that enforce. A prompt asks; a gate refuses. What belongs in the channel that can only ask, what belongs in the channel that can say no, and what breaks when a rule is filed under the wrong one?
- Everything on the context surface is paid for on every turn, whether the model needs it that turn or not. What does an instruction actually cost to keep loaded, and what changes when you load it only where it applies instead of putting the whole surface in front of the model every time?
Each of those is one part of the loop, looked at on its own, with the evidence attached. Same discipline as this piece: a claim is worth exactly what the measurement under it is worth, and no more.
I work on Reporails, deterministic diagnostics for the instruction files, rules, and prompts that steer coding agents. It reads the steering surface and tells you, with measured evidence, where it drifts. It does not run your loop; it checks the part of the loop you wrote down.
Top comments (1)
The rename-by-rename read is the honest version of this, and dating the evidence instead of selling the word is what makes it land. The verifier-is-the-bottleneck framing is right, and the deterministic-check versus model-graded-check split is the one people skip.
One kind of check hides between the two, and it is neither: consistency with what was already decided. A deterministic scan proves this iteration's tests pass and no banned import crept in; a model-graded judge rates the taste; neither can answer did we already reject this approach last week and why, because that fact is not in the current diff and it is not a matter of taste, it lives in a decision history the loop never carried. The context surface rides between iterations, but the decision trail usually does not ride between sessions, so the loop confidently re-opens a question a human already closed while both checks stay green.
That is your ask-versus-refuse channel one level up: a killed option or a hard constraint is a gate that can only say no, and it holds only if it persists as state with a status (open, settled, superseded), not as a steering line that ages out mid-loop. I build that layer for Claude Cowork and Code as plain readable files the loop reads before it acts, open-source if it is useful: cowork-os. Reporails checks the surface you wrote down; this is the decision-state that surface tends to leave out. When you take the loop apart component by component, is persisted decision-state part of what you plan to measure, or only the instruction and rule files written down today?