A few years ago, I was integrating with an API that shall remain nameless. It told me almost nothing — no error messages, no logs worth reading. Just HTTP status codes and a dashboard with exactly one metric: failed requests over total requests.
It started at 1/1. Then 2/2. Then 13/13. Then 32/32. A perfect record of failure.
I was deep in it. Change something, re-send, change something else. Then I looked up, and the dashboard read:
I had no idea. Somewhere in the last hour of frantic edits, one combination of changes had produced a success, and I had kept editing right past it. No log of what I'd tried. No commits between attempts. Just a number telling me I'd already solved the problem and thrown the solution away.
Here's what I understood only later: none of that debugging required creativity.
It required repetition with memory. Try one variation. Observe the result. Write it down. Narrow the space. Repeat.
That's not a job that needs a human. It needs something that doesn't get tired, doesn't forget what it tried on attempt #12, and doesn't edit past a working version without noticing.
Then, reading the output, spotting what's wrong, and typing a correction. Then another. This is prompt engineering — asking really precisely, once, and hoping.
You don't write the fix, and you don't evaluate each attempt. You define what success looks like in a way a machine can check, hand over the ability to check it, and let the thing iterate until the condition is met.
Loops that work all have these. Loops that fail are usually missing one. An exit condition that the machine can verify. Not "make it work." A command that returns something unambiguous — a passing test, an HTTP 200, an exit code 0. If the agent can self-assess subjectively, it will, and it will grade itself generously. Feedback that can actually be read. The loop is only as smart as the errors it is given. Full response bodies, real stack traces, and actual test output. If your verification step prints "FAILED" and nothing else, you've built a loop that guesses. Boundaries. Which files may it touch? One change per attempt. Keep a log. Commit each attempt. Without these, you get a working solution buried inside forty unrelated "improvements." A budget. Max attempts, then stops and reports. This isn't about token cost — it's so a genuinely stuck loop escalates to you with a log instead of quietly redecorating your codebase for an hour.
Here's the shape of a loop I'd hand to an agent for exactly my 67/68 situation today:
The verify script is an exit condition the agent can't fudge — it has to print a real status code. One-change-per-attempt plus attempts.md is the memory I didn't have at 2 AM. Commit-every-attempt means "which one worked?" is answered by git log instead of two days of archaeology. And the boundary keeps an enthusiastic agent from "fixing" my database config while it's in there.
A loop does not make the AI's code more trustworthy. Individual attempts still fail — that's the entire premise; most attempts fail. What changes is where your trust lives.
I don't need to believe attempt #14 is correct. I need to believe my verification script can't be fooled.
That's a much smaller thing to trust. And unlike the model, it's a thing I wrote and fully understand.
That shift — from trusting the generation to trusting the checking — is what makes any of this workable at scale. Everything else (rules files, review passes, permissions) is elaboration on the same idea.
Worth being honest about the limits, because "just loop it" is becoming its own kind of hype.
Anything without a cheap, honest verification. If the only way to know it worked is a human looking at it, you don't have an exit condition — you have a wish. UI polish, copy, architecture decisions: these don't loop.