Stop Prompting. Start Looping.

For a year I used AI the way you use a calculator. I typed, it answered, I typed again. Every useful thing the model did depended on me being there to ask the next question. The model wasn't working for me. I was operating it, one pull of the lever at a time.

That's the default way most people use these tools, and it has a ceiling: your throughput. One prompt, one judgment, one revision per turn. You become a very fast reference desk, and you're the one standing between the model and anything it might do on its own.

Then I started building loops, and the ceiling moved.

The idea, in one sentence

Write down what "good" means as something a program can check. Then let the model keep trying, score each attempt, keep the winners, throw out the rest, and try again. No you in the middle. You walk away. It runs.

That's the whole pattern. People have started calling it "the Karpathy Loop" after Andrej Karpathy, who's been the loudest public voice pushing the broader practice he calls agentic engineering. The name matters less than the shape, and the shape is old: it's a search algorithm with a learned proposer and a hand-written judge.

If you squint, it's also a thermostat. A thermostat doesn't ask you whether to turn the heat on. It has a target, a measurement, and an action, and it just closes the gap, forever, without your help. An agent loop is a thermostat where the target is a metric you chose and the "furnace" is the model generating the next attempt.

Why that changes everything

Here's the small reframe that took me too long to internalize. When you prompt a model, you are doing two jobs at once:

1. Proposing — coming up with the next thing to try.
2. Evaluating — deciding whether what came back is any good.

Both have a bottleneck, and the bottleneck is you. You can propose maybe a dozen ideas in an hour and evaluate maybe twice that before you get tired and start rubber-stamping.

A loop replaces both halves with code. The model proposes (it's fast, and it never gets tired). A function you wrote evaluates (it's consistent, and it never gets bored). Your job moves upstream: you design the target and the scorer, exactly once, and then the search runs as wide as your compute allows.

best, best_score = None, -1
for _ in range(N):
    candidate = propose(best)     # the model suggests a change
    score = evaluate(candidate)   # your code decides if it's better
    if score > best_score:
        best, best_score = candidate, score

That's it. Five lines. Everything interesting lives in what evaluate actually measures, because that's where you put your taste.

A real, boring example

I run a small publishing pipeline. At one point I had a pile of landing-page headline variations and no honest way to pick among fifty of them. So I wrote a scorer: does it fit the length limit, does it avoid the words I'd banned, and does a separate model call rate it for clarity on a 1-to-10 scale. Then I let the loop generate, score, keep, repeat, for a few hundred rounds.

I came back an hour later and the winning headline was better than anything I'd have written by hand. Not because the model was brilliant. Because it had run the experiment five hundred times and I would have run it three. I could never have evaluated five hundred headlines by eye. The loop could, because evaluation was a function, not a feeling.

That's the part people miss. The magic isn't intelligence. It's permission to iterate.

Where it breaks (read this before you build one)

I don't want to sell this as a dial you just turn up. It has one catastrophic failure mode, and you should name it out loud before you write a single line.

The loop optimizes the metric you wrote, not the goal you meant. This is Goodhart's law with the gas pedal floored. If your scorer is sloppy, the loop will find the best possible answer to the wrong question, and it will find it fast, and confidently, and seven hundred times. A clear headline that's also a lie will score great. A test suite that "passes" because someone deleted the failing tests will score perfect. The faster your loop, the faster you arrive at a confidently wrong optimum and mistake it for done.

So the real engineering isn't prompting. It's writing a scorer that actually tracks the thing you care about, and resisting the urge to optimize a number just because it happens to be easy to measure.

It only works where feedback is cheap and unambiguous. Code that compiles, tests that pass, click-through rates, latency, win/loss. Yes, loop all day. "Is this essay actually good?", "is this design tasteful?", "will people trust this?" No. Those are exactly the questions where you can't write a cheap scorer, which means you can't close the loop, which means the model is back to being a calculator and you're back to being the engine. That isn't a failure of the technique. It's the boundary of where the technique applies, and it's worth knowing exactly where that line sits in your own work.

Compute isn't free. A loop that runs overnight on a real problem is real money. Most of us don't have the budget to loop everything, and that's a perfectly good reason to be selective. Loop the boring, verifiable stuff. Keep the taste-driven stuff for yourself.

How to start

You don't need a GPU farm. The smallest version fits in an afternoon:

1. Pick one task you repeat and dread.
2. Ask the only question that matters: can I write a function that scores an attempt at this? If you can't, stop. You don't have a loop yet, and that's fine.
3. If you can, have the model generate five candidates, score them with your function, keep the best, feed it back as the starting point, and repeat a few times. Start with N = 5. Watch it. Then turn N up.

The point isn't to disappear overnight. The point is to move, one task at a time, from you are the engine to you wrote the engine.

The real question

For twenty years we sat at a search box and asked, what do I type next? That question assumed we were the bottleneck, and for a long time we were.

The loop reframes it completely. The question stops being what do I prompt? and becomes what do I set running, and can I trust the thing it's measuring?

Get the second part right and you can go to sleep while it works. Get it wrong and you'll wake up to the best possible answer to a question you never meant to ask.