"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.
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.
Love it!
Thanks for reading!
Good stuff as usual!
Thanks Stephen!
I see loop useful for daily triaging or routine checks but do people use it to implement features?
Yes this is exactly the problem we should be focused on I created Orbit to solve this problem.
https://github.com/human-again/orbit
"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
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.
Isn't this the same concept as Dark Factory?