A watermill turns whether or not anyone stands and watches it. Hang a wheel where the water falls, and the current turns the wheel and the wheel grinds the grain, each on its own. What the miller did was not the labor of grinding grain by hand — it was setting up, once, a structure that runs by itself, water and wheel and stone meshed together. After that his work changes. From the one who grinds to the one who watches: whether the water is running dry, whether the wheel is spinning free.
Among people working with AI lately, a similar shift is underway.
From the prompt to the loop
In June 2026 a single sentence went around the developer world. “Stop prompting your coding agent. Design the loop that prompts your agent.” One tweet cleared a few million views in a matter of days and spread the phrase loop engineering. The arc people drew was this: from the age of writing good commands (prompt engineering), through the age of designing what to put in front of the model (context engineering), and now into the age of building the cycle the agent runs in itself. No stage throws out the one before it; it wraps it in another layer. On top of a single command you lay the information environment it sees, and on top of that the loop it runs around and around.
The skeleton of a loop is simple. Act, observe the result, decide what’s next, and go again. Instead of a human cutting in every turn to type the next prompt, you build the loop once and it runs the agent. Boris Cherny, who leads Claude Code at Anthropic, put it like this: “I don’t prompt Claude anymore. I run loops that prompt Claude. My job is to write loops.” It’s the miller moving from the one who grinds to the one who watches.
Reading it left me with an odd feeling. Before the name was ever attached, I was already running five or six loops of my own.
I run loops across several domains
No one got there first. The people posting those tweets and I were all just doing what we each needed to do. One thing was different, though. Where most of them stacked loops in the single domain of coding, I’d been running the same pattern across several different tracks.
One is investing. With real money, once every half hour an agent looks over the market, decides whether to buy or sell, and records its reasoning. Another is knowledge curation. Once every few hours it reads through the raw records that have piled up and distills them into a tidied wiki (the last piece was about exactly the wiki this loop produces). An idea-mining loop surfaces a new topic once a day and learns from the patterns I ignore to sharpen its next suggestions. And at work, when I put up a piece of output, another agent holds it against the requirements doc and judges whether it actually met the ask.
The domains are all over the place, but the skeleton is identical. Trigger (when it runs), action (what it does), verification (who checks it went well), stop (when it halts). And for domains this different, it always broke down in the same two places.
First, the verifier
The first is verification.
Take that loop that judges output against requirements. The key is to separate the one who judges from the one who made it. Ask the model that built something “did you do this well?” and it goes easy on itself, the way a person grading their own homework does. So the judging falls not to the model that made it but to a separate judge, a different model holding a different set of instructions (LLM-as-judge).
But once it was actually running, the hard part wasn’t making the judge smarter. When the judge wavered, it usually wasn’t because the judge was dumb — it was because the criteria were vague. When the requirements doc was woolly, the same piece of output passed one day and bounced the next. Reach in to raise the quality of the judging, and what I ended up fixing wasn’t the judge but the sentences I’d written down as the requirements. If I can’t write clearly what counts as meeting the bar, the judge can’t judge clearly either.
This is the lived feel of a line that gets repeated a lot in loop engineering: “The bottleneck isn’t the model, it’s the verifier.” A loop amplifies, exactly as written, the judgment I baked into the verification criteria. Which makes the level of the verifier the ceiling of the whole loop. The scariest case is a different beast: a loop running diligently toward the wrong criteria drives its output, confidently, further and further in the wrong direction. Fast, consistent, and wrong.
Second, the stop
The second is stopping.
In the investing loop there was a stretch where not a single trade happened. At first I figured the market was just quiet, but looking closer, that wasn’t it. Trying to make it safe, I’d added one guardrail after another — “in this case, don’t buy” — and those rules had multiplied on their own and tightened until almost every situation tripped a “don’t buy.” The loop was running fine, but it had locked itself into a state of doing, effectively, nothing.
A loop with no stop condition runs off the other way. With no brake to push back, an agent endlessly agrees with itself and repeats the same move, or burns money like an open tab. One company, the story goes, burned through its annual budget on an unguarded loop in a few months, and only then set a per-person spending cap. Smart sits in the middle; stopping dead and running away sit at the two ends. Half of loop engineering isn’t growing the middle — it’s handling the two ends.
So where does human verification go?
Here a fair question arises. If the loop pulls me out of the seat of “the person who prompts every time,” when does human verification happen? The answer is that verification doesn’t disappear — it changes seats. The work I used to do cutting in every turn, checking on the spot, scatters into three places.
First, at design time. The moment I build the loop, I pin down the verification criteria and the stop condition in advance. I’m condensing into rules the judgment I used to make each time. The verifier discussion above lived here. Next, mid-run. For sensitive decisions I leave a gate where the loop halts in front of a human. Last, after the fact. A person reads the output the loop produced and accepts it.
The trouble is that each seat the work moves to carries a new cost. Move verification to a rule at design time, and when that rule is wrong the loop breaks confidently. Move it to after-the-fact review, and now how much I can actually read becomes the bottleneck. And pass things through without reading, and the output piles up while the understanding that should hold it up never settles inside me. As I wrote before, you can hand off the execution of thinking, but not the understanding. Automation that skips review is exactly what grows that empty spot.
This isn’t a strange story, really. I’ve said before that the truth an agent stands on needs a gate of human-approved verification (A Single Truth), and that knowledge stacked automatically may fit one person yet still has to pass that gate before it can become an organization’s standard (LLM Wiki). Loop engineering asks the same question through one more lens. The deeper automation goes, the more human verification, rather than vanishing, moves to fewer and more important seats. Where you put that seat, and whether you can bear its cost — that’s the whole of it.
The one who watches
Building a loop looks like automating work, but it’s really deciding where to fix your judgment in place. What counts as meeting the bar, when to stop, which results you must lay eyes on yourself. It’s carving those decisions into the structure ahead of time. A loop is exactly as smart as the judgment I carved in, and exactly that safe.
The man who built the watermill was freed from the labor of grinding, but not from the responsibility of watching the water and the wheel. If anything, his work moved to fewer, more important judgments. When the water runs dry the wheel stops; when the dam breaks the wheel runs away. The seat of the person running the loop is right there too. Not the seat that grinds each grain, but the one that watches, to the end, what is turning well and what has slipped.
— tomte