Loop Engineering: The Loop Is the Cheap Part
Also available in German: Loop Engineering: Der Loop ist der billige Teil.
Part 2 of Loop Engineering: When the Prompt Is No Longer the Unit of Work. That’s where the theory lives. Here it gets concrete, on my own repo, with green and red tests.
In Part 1 I stood at the threshold and didn’t dare. Half the industry is shouting “stop writing prompts, write loops”, and I hadn’t yet dared my first serious loop. By now I’ve built it. The surprise was what my hesitation had really been about: not the loop. The loop was never the hard part.
What got built
My test subject was FunkParcours, a radio-drill tool I’d vibe-coded in one sitting. Architecture and spec were solid, the game core even tested. What was missing was the verification surface. The server made central promises that nobody secured: the receiving team must never see the template, the timer runs server-side. No CI, no real lint, no contract forcing a new game-type plugin to make itself checkable.
Every gap became an issue, with acceptance criteria, architecture notes, and a definition of what “checked” means. The whole bundle then went to Claude Code in a single run, no longer prompt by prompt. Out came a CI gate with Postgres that blocks on red, an AGENTS.md holding the invariants, ESLint, server integration tests, and a registry-driven contract test. In the end: 141 green tests in the core, 80 of them the contract alone.
Honestly framed: this was not an autonomous loop running by itself overnight. It was an agentic run against a clear plan, with me as the verifier. And that’s exactly the point.
The loop is cheap, the verifier is the work
For months I’d been in awe of the wrong thing. I thought the courage I lacked was the courage to give up control: to let the while run without sitting next to it. But the while is the cheapest part of the story. A dozen lines.
The work sits elsewhere, in writing the verifiers. In defining what “correct” and “done” even mean in this project. That’s the one task no agent takes over, because it’s the very question the agent gets measured against. An agent doesn’t grade itself; ask it whether it’s done, and it says yes. The verdict has to come from outside, and building that verdict is the real engineering work.
This fits the cost math from Part 1. What makes a loop affordable and what earns it trust are the same thing: a hard, checkable stop condition. Without a verifier there’s no affordable loop, and certainly none I’d trust. The expensive thing isn’t letting go. The expensive thing is the verifier that has to exist first.
Coding is the easy case
This insight carries an uncomfortable aftertaste that Louis Bouchard (Towards AI) nails in his video “Loop Engineering Explained”. A deterministic goal, all tests green, CI clean, is checkable, so the loop halts. A subjective goal, “make it good”, has no target. The loop rewrites endlessly, version 55 and no end in sight, because nobody tells it when to stop. Without a check you don’t get a loop, you get, in Bouchard’s image, a very confident token furnace.
That’s why FunkParcours runs autonomously at all: because its goals are deterministic. “The perfect answer scores 1.0” and “the team never sees the template” are things a machine can prove. Coding is the easy case for exactly this reason. But once the goal is “better product strategy” or “nicer design”, the target is gone, and no while in the world replaces the human who decides what “good” means.
The verifier that changed the architecture
The contract test shows this best. A single test walks every registered game type and checks five laws: the same seed produces the same template, the perfect answer yields accuracy 1.0, a wrong answer less, the value stays between 0 and 1, and the generator stays free of frontend and I/O.
The law “perfect answer yields 1.0” had a consequence I didn’t see coming while writing it. To check it, every type has to be able to say what its perfect answer looks like. So a samplePerfectAnswer method migrated onto the shared interface, and with it into all thirteen existing types. Since then, a new game type won’t compile unless it can explain how to solve it.
To me, that’s the core of Loop Engineering, far more than the while: the verifier dictates the design. I didn’t “add a few tests”, I forced the system to make itself checkable, and that changed the interface. Every future plugin inherits this contract and is therefore safe by construction. That’s the work that moves up a floor.
What broke
The 141 unit tests were green. The end-to-end wasn’t. In the e2e run, which plays through the whole stack, the team got stuck immediately, not on logic, but on a station’s help dialog that lies over the playing field on first open and swallows every click. No unit test sees that: every function on its own is correct. It only breaks where the real building blocks meet in the browser, in the order a human clicks them.
The lesson in one sentence: different verifiers catch different truths. The contract test secures pure logic, cheap and fast. The e2e test secures integration, expensive and slow. Build only the cheap one and you’ll mistake a green project for a finished one that stumbles in the browser.
The invariant I never trust blindly
One check deserves more distrust than all the others. It’s written verbatim in the AGENTS.md the run produced: “A green route is not enough – the test must assert the property, never just status 200.”
It’s about the platform’s central promise: the receiving team never gets the template through the software. The channel is the radio, not the app. A lazy test checks whether the route responds. The real test reconstructs the true template server-side and then asserts that it appears in the response to the team in no form at all: not as a field, not in the heatmap feedback after submitting, not in the snapshot after a reconnect. This verifier isn’t friendly, it’s adversarial. It assumes the answer could leak, and actively goes looking for it.
This is where my governance reflex from Part 1 kicks in. For a security property I trust neither an agent’s self-report nor a green checkmark that only proves reachability. Such tests should be read, not just run, ideally by a second pair of eyes that didn’t build the solution itself.
When a loop pays off, and when it doesn’t
Before I ask how autonomously a loop may run, I ask whether it pays off at all. I like Bouchard’s rule of thumb: start simple, add autonomy only when it earns its keep. A one-off task I just prompt, no scaffolding needed. If the work repeats and has a clear pass or fail, the loop that takes over exactly that dull repetition pays off. If the goal is vague, it doesn’t belong in a while loop but a step back: first sharpen a better goal with humans.
On top of that, the hard cost side. Self-prompting and retries burn tokens, millions fast, and that per run. The brakes are unglamorous and mandatory: a maximum iteration count and a daily budget in tokens or euros. Without a checkable stop target, both run into the void; the furnace just heats up more expensively.
Inside a project, too, there’s no smooth autonomy, just a clear edge. Where the verifier is cheap, deterministic, and complete, like the contract test for a new plugin, a loop may run overnight. Where it checks a security or fairness property, it runs too, but I read the verdict afterward. And before anything ships to production, I take a last look myself. Every loop’s reach ends where “done” can no longer be proven by machine.
That’s also my sober answer to whether such loops replace teams. The value never migrated into the loop. It stays in the three things above it: knowing what “correct” means, well enough to write it as a test; noticing when an agent stamps itself green even though it checked the wrong thing; and deciding where a human absolutely has to step in. This judgment work has grown, not shrunk.
Where the path leads
The threshold is crossed, just at a different spot than I thought. The courage I needed wasn’t the courage to give up control, but the discipline to build the inconspicuous half first: the checks that define what good is. Putting the while in front of it afterward is an afternoon.
The next step is clear, and this time without the queasy feeling: have a real autonomous loop build a new game-type plugin, with the contract test as judge, overnight, with a cost brake. Because the verifier exists, that’s no longer a leap into the dark but a controlled run against a gate that doesn’t lie. That’s what Part 3 is about.
One more note on AI transparency on this blog: the code run was done by Claude Code, the prose is written with AI assistance. What was not outsourced, and not outsourceable, was the decision about what should be checked in the first place. That was the work. The rest is typing.
Repo to follow along: github.com/achildrenmile/funkparcours. Conceptual basis in Part 1. The image of the deterministic vs. subjective goal comes from Louis Bouchard’s “Loop Engineering Explained” (Towards AI); Addy Osmani’s original post remains the best single reference point.
Transparency: This post was created with AI assistance. I reviewed it and take responsibility for the content. More under AI Transparency.