I already run a loop. It's not fancy. Every 24 hours, a scheduled job reads the bug reports sitting in my database, spawns a sub-agent per open issue, drops each one into its own isolated work tree, and lets it take a shot at a fix. If it opens a PR, I review it. If it can't figure it out, the issue stays open for me. It's been running for a while. It's genuinely useful.
I didn't think of this as "loop engineering." I thought of it as a task runner with an LLM in the middle. But apparently that distinction matters now, because "loop engineering" just became the term everyone is rallying around the idea that you stop prompting agents manually and instead design systems that do the prompting for you on a schedule or trigger. Reasonable concept. I'm on board.
What I'm not on board with is how it's being taught. Every framing I've seen is focused on how to start a loop. Almost none of it talks about how to stop one. That omission is where loops actually break.
Here's the math that's missing from the conversation. Suppose your agent is accurate 95% of the time per step which is already generous for anything non-trivial. String together 10 steps and your probability of a clean, correct run is 0.95 to the power of 10. That's roughly 60%. One in three runs is producing garbage even with a 95% per-step accuracy, across 10 steps. Extend that to 20 steps on a medium-sized codebase refactor and you're below 36%. The errors don't just accumulate they compound. Each bad step hands the next step a slightly broken context. The agent doesn't know the foundation is cracked. It keeps building.
This is the core failure mode of what you might call the "let it loop" approach: treating a while-true with a vague goal as an engineering solution. "Keep improving the architecture until it's clean." There's no exit condition. There's no quantifiable signal for done. The agent will produce something that looks like progress, and you won't know it's wrong until you look closely or until production tells you.
The fix isn't to avoid loops. It's to build loops where the exit condition is the first thing you design, not an afterthought. The stop is the architecture. Everything else is just scheduling.
The loops that actually work in practice are bounded. A review loop with a real exit condition: run the linter, run the tests, have a second agent check the diff against the project's coding standards stop when all three pass, or stop after N attempts and surface the failure. That's a for-each, not a while-true. You're iterating over a predefined set of checks, not improvising toward a fuzzy destination. The exit is concrete. The agent can hit it. A bounded migration loop works the same way: process each file in the queue, track what passed and what didn't, stop when the queue is empty. Not "stop when the codebase feels better."
When the goal is subjective or unquantifiable, the loop becomes a token-burning machine that eventually produces something plausible-looking. Plausible-looking and correct are not the same thing. An agent that optimizes a renderer from 88ms to 2ms sounds like a win until you realize it optimized for the metric and broke what the metric was supposed to measure. The loop converged. It converged on the wrong thing.
There's also a deployment angle to this that nobody in the loop discourse is taking seriously. Rollbacks work today for a specific reason: you release software slightly slower than it takes you to detect something is wrong. That gap is your safety margin. If your agent loops are opening PRs continuously faster than your monitoring can catch regressions every rollback now has to fight through multiple conflicting changes that landed on top of it. The loop made deployment faster. It also made recovery exponentially harder. Speed is not free. The whole system has to move together.
For my bug-loop, the exit conditions are explicit: the agent either opens a PR or it doesn't. PRs sit in draft until I merge them. Nothing lands in production without me seeing it. That's not because I don't trust the agent it's because the loop's exit condition is my review, and without that gate, the deployment problem above is live. The loop handles triage and first-pass implementation. The judgment call about what's safe to ship stays with me.
This is the architecture worth talking about: not loops as a productivity unlock, but loops as delegation with defined handoff points. What work does the loop own completely? Where does it stop and wait for a human signal? What's the retry limit before it surfaces the failure instead of spinning on it? These are engineering decisions. They're not defaults you get from the framework.
The concept of loop engineering is legitimate. Agents running on schedules, reacting to triggers, managing their own context across runs this is real and it's genuinely changing how solo developers and small teams operate. But the skill being sold right now is "design the loop." The actual skill is: design the stop condition, set the retry ceiling, define what failure looks like, and build the handoff back to yourself for everything the loop can't resolve cleanly.