For a long time my first instinct, whenever something broke with a language model, was always the same: fix the prompt. Add another line of instruction. Add an example. Add a warning about the edge case that just bit me. The prompt grows, gets more defensive, and for a while it works better.

Then the next edge case shows up. And the next. At some point the prompt has become a wall of rules trying to anticipate every possible future at once — and still missing. That's usually the sign that I'm solving the wrong problem.

There's another way. Instead of making the model guess the right answer in one shot, you put it in a loop: let it act, let it see the result, let it correct itself. That's the difference between a prompt and a loop.

while (!done)
{
    var step   = model.Decide(context);   // act
    var result = Execute(step);           // observe
    context    = context.Add(result);     // remember
    done       = result.IsComplete;       // or go around again
}

The prompt approach bets on anticipation. One exchange with the model, a carefully staged context, and you hope you've covered everything. The loop approach bets on feedback. The model doesn't need to be right the first time — it only needs to notice it was wrong and get another move.

This is where my psychology background keeps tugging at my sleeve. People don't handle hard tasks by planning them perfectly up front; we handle them through feedback, through trial and correction. The belief that you can write an instruction good enough that nothing goes wrong is a kind of perfectionism. A loop is just a feedback loop — the same mechanism by which anything alive has ever learned anything.

None of which makes the loop the better choice by default. It has a price: more tokens, more latency, non-determinism, harder debugging, and a real risk of spiralling in its own circles. A prompt is cheap, predictable, a single call. A bounded, well-defined task almost always wants a prompt. An open-ended, multi-step task with tools and uncertainty wants a loop. And the loop is only as good as the feedback you feed it; a loop with no real observation is just expensive repetition.

The distinction gets sharpest with the small local models I like to experiment with. A weak model in a good loop often beats a strong model in a brittle prompt — because its mistakes are cheap and recoverable rather than fatal. Up to a point, of course. A loop doesn't turn a tool into something it isn't; it just gives it a chance to correct course.

The question stopped being how to write the perfect prompt a while ago. The real question is how to build a loop where an imperfect model can fix itself — which, if you think about it, is the only way anything has ever gotten good at anything.