Been doing something similar with a few personal projects and the token cost thing is no joke. My biggest learning: you need really solid exit conditions. Without them the agent will happily iterate on the same function for 40 minutes while you're not looking.
runaway loops are the easy case, you catch those. the ones that get you are loops that exit clean and hand back something confidently wrong. the stopping rule has to grade the output, not just notice the loop ended.
oh this is painfully accurate. catching an infinite loop is easy — the agent just burns tokens until you notice. the scary ones exit in 3 turns with a perfectly structured answer that's completely wrong. i've started spot-checking outputs against a quick manual sanity test before accepting anything, but it's ad-hoc. have you found any heuristics that actually work for grading output quality vs just checking for errors?
"Build the loop. Stay the engineer." - this is a great framing 👌
I think there is an very important aspect in all of this that defines the speed of the loop, and that is the backpressure mechanism i.e. the "verifiable stopping condition". It is the mechanics inside the loop: tests, types, linters, builds, browser checks, logs, and evals that push feedback to the agent before the human has to step in.
If loop engineering is the system shape, then backpressure is what lets agents self-correct before humans become the bottleneck.
backpressure just tells you the loop stopped, not that it worked. had a triage loop exit clean this week and fix exactly nothing. stopping condition and success condition are completely different problems.
the hard part isn't backpressure. it's when the loop exits cleanly and hands you a subtly wrong answer with full confidence. a runaway is easy to catch. a confident wrong result isn't.
running a fleet of these, the thing that actually breaks you is around result forty when everything looks clean and you just... stop reading it. execution scales, attention doesn't. you start trusting the format.
the sneaky failure mode isn't a crash, it's the week you stop reading the diffs because nothing blew up. exit conditions catch runaway loops. nothing catches your own attention drifting.
Yeah, constantly. If "done" is machine-checkable (tests pass, schema validates) the loop can own it. The second it becomes a taste call, it just circles confidently forever. Checkable work gets the loop, judgment calls stay on my desk.
The system around the model matters more than the model, yes, but loop engineering is a subset, not the whole discipline. You need someone to provision the identity, the context store, the capability registry, and the observability pipeline. The loop is not a component you can buy - it is a flow through the whole platform, the harness tunes within a turn, then the loop tunes between turns. Platform engineering as a framework and practice is what makes both work at scale across the enterprise!
Its Open source governance for autonomous coding agents, iliterally dont use any more loops without it, budget governed runtimes with hard caps, run receipts, audit trailes, failure taxonomy, no more blind retries, it literally solves all the loopp problems of today, check it out
I built a framework for creating your own governed loops (as opposed to naive loops). Separating planning, building, and QA agents is trivial with it, and making your own workflow loops is also really easy to do (with the help of a normal agent, of course).
Still working on it, but it's been in a solidly functional state for over a month now. Pretty token efficient too, all things considered. I'd be much obliged for any feedback you've got on it: pypi.org/project/millrace-ai/
Love it!
Thanks for reading!
Good stuff as usual!
Thanks Stephen!
Been doing something similar with a few personal projects and the token cost thing is no joke. My biggest learning: you need really solid exit conditions. Without them the agent will happily iterate on the same function for 40 minutes while you're not looking.
runaway loops are the easy case, you catch those. the ones that get you are loops that exit clean and hand back something confidently wrong. the stopping rule has to grade the output, not just notice the loop ended.
oh this is painfully accurate. catching an infinite loop is easy — the agent just burns tokens until you notice. the scary ones exit in 3 turns with a perfectly structured answer that's completely wrong. i've started spot-checking outputs against a quick manual sanity test before accepting anything, but it's ad-hoc. have you found any heuristics that actually work for grading output quality vs just checking for errors?
"Build the loop. Stay the engineer." - this is a great framing 👌
I think there is an very important aspect in all of this that defines the speed of the loop, and that is the backpressure mechanism i.e. the "verifiable stopping condition". It is the mechanics inside the loop: tests, types, linters, builds, browser checks, logs, and evals that push feedback to the agent before the human has to step in.
If loop engineering is the system shape, then backpressure is what lets agents self-correct before humans become the bottleneck.
I wrote exactly on the same topic yesterday here https://generativeprogrammer.com/p/stop-babysitting-your-coding-agent
backpressure just tells you the loop stopped, not that it worked. had a triage loop exit clean this week and fix exactly nothing. stopping condition and success condition are completely different problems.
the hard part isn't backpressure. it's when the loop exits cleanly and hands you a subtly wrong answer with full confidence. a runaway is easy to catch. a confident wrong result isn't.
Maybe a real world example to follow up?
I was working with Codex to systemize this exact workflow described in your post. Couldn't find a better framing / naming myself :) Thank you!
This is the part that stuck with me:
Loops are excellent for scaling execution, but terrible for scaling understanding.
The moment you let the agent understand the system for you, you are just scheduling future incidents.
running a fleet of these, the thing that actually breaks you is around result forty when everything looks clean and you just... stop reading it. execution scales, attention doesn't. you start trusting the format.
the sneaky failure mode isn't a crash, it's the week you stop reading the diffs because nothing blew up. exit conditions catch runaway loops. nothing catches your own attention drifting.
Isn't this the same concept as Dark Factory?
I see loop useful for daily triaging or routine checks but do people use it to implement features?
Yeah, constantly. If "done" is machine-checkable (tests pass, schema validates) the loop can own it. The second it becomes a taste call, it just circles confidently forever. Checkable work gets the loop, judgment calls stay on my desk.
Yes this is exactly the problem we should be focused on I created Orbit to solve this problem.
https://github.com/human-again/orbit
Hi @addy osmani. I created a loop but the sandbox link expires if I don’t view it as soon as possible
The system around the model matters more than the model, yes, but loop engineering is a subset, not the whole discipline. You need someone to provision the identity, the context store, the capability registry, and the observability pipeline. The loop is not a component you can buy - it is a flow through the whole platform, the harness tunes within a turn, then the loop tunes between turns. Platform engineering as a framework and practice is what makes both work at scale across the enterprise!
great insights
Anyone using loops today needs to try http://martinloop.com
Its Open source governance for autonomous coding agents, iliterally dont use any more loops without it, budget governed runtimes with hard caps, run receipts, audit trailes, failure taxonomy, no more blind retries, it literally solves all the loopp problems of today, check it out
I built a framework for creating your own governed loops (as opposed to naive loops). Separating planning, building, and QA agents is trivial with it, and making your own workflow loops is also really easy to do (with the help of a normal agent, of course).
Still working on it, but it's been in a solidly functional state for over a month now. Pretty token efficient too, all things considered. I'd be much obliged for any feedback you've got on it: pypi.org/project/millrace-ai/
@Addy FYI `adversarial code review` link is broken