What it was for
Nothing with this exact shape — but it has a clear lineage. Loop engineering is the practitioner's name for the discipline the engine's outer loop implies: once agents can run for many turns, the leverage stops being how well you prompt and becomes how well you design the system that prompts itself. As Addy Osmani puts it, "loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
The verdict
EMERGES — and it is the operational floor under much of the rest of this ledger. The move is from directing a single agent, turn by turn, to building a loop with a written stop condition. Osmani's /goal "keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you are done, so the agent that wrote the code isn't the one grading it." That separation — writer and grader as different models — is evaluation engineering made concrete, and it is genuinely new craft.
What changes
The ceiling moves from the tool to you: "your review bandwidth decides how many you can actually run, not the tool." The work becomes designing loops that are legible — that surface what they did fast enough to verify — and resisting the debts a smooth loop accrues: intent debt (the agent fills any gap in your intent with a confident guess), comprehension debt (the loop runs faster than you read), and cognitive surrender (taking whatever it returns without an opinion). The job, in Osmani's words, is still to "ship code you confirmed works."
The strongest objection
That this is just "an agent in a for-loop" dressed up. Contested: the distance between babysitting an agent and engineering a loop is the same distance the charter draws everywhere — between doing the work and specifying and verifying it. The loop is the artifact; judgment is what you build into its stop condition.
Falsification: downgrade to TRANSFORMS if loop engineering turns out to be ordinary automation and CI rescaled, rather than a new authoring discipline with its own verifier-separation and legibility constraints.
Corroboration — "Own the Outer Loop" (Jul 2026)
Osmani's follow-up sharpens the discipline from designing the loop to owning its boundary. His frame: the human owns the outer loop — the point where agent work becomes a production commit — because "the agent can ship more than you can review." Three things worth importing. The boundary decision is a verdict (ship, block, redirect, narrow, or reject), not a rubber stamp. It demands answerability: "someone must be able to explain exactly what changed, why it was safe, and what will happen if they're wrong." And capability is not agency — "only people can choose. Only people inherit consequence." Loop engineering builds the loop; owning the outer loop is who stands behind what it ships.
The benchmark under it (Ng, 2024)
The claim that loop design outweighs model choice has a number behind it. Andrew Ng's HumanEval comparison — GPT-3.5 zero-shot 48.1%, GPT-4 zero-shot 67.0%, and GPT-3.5 wrapped in an iterative agent workflow up to 95.1% — carries his own verdict: "the improvement from GPT-3.5 to GPT-4 is dwarfed by incorporating an iterative agent workflow." Read it honestly: a coding-only, 2024, "up to" figure aggregated across research teams, so it argues direction — architecture beats model capability — not a transferable effect size. But direction is the whole case for treating the loop, not the model, as where the leverage lives.
Loop or harness?
The two words get used for the same thing, and they shouldn't be. Google's May 2026 paper The New SDLC With Vibe Coding (Osmani, Saboo and Kartakis) calls the machinery around a model the harness — instructions and rule files, tools, sandboxes, orchestration, hooks, observability — and sums it up as "Agent = Model + Harness." It puts the feedback loop inside that machinery: when a test fails, the orchestration logic routes the error back to the model, and "the harness is what creates this automated 'think -> act -> observe' loop."
This entry draws the line somewhere else. The harness is structure: what the agent can reach, run and break. The loop is control over time: when it goes again, what it was handed, and who decides it's done. You can change one without touching the other. Put a new stop condition or a separate verifier on the same tools and you've done loop engineering; add a sandbox or a commit hook under the same iteration and you've done harness engineering. Most real work does both, which is why the terms blur — the Mozilla pipeline in the playbook (§4) mixes them freely. Keep them apart anyway, because they fail differently. A weak harness lets the agent do damage. A weak loop lets it stop in the wrong place, or never stop.