What Changes When You Delegate Work to a Loop

Nobody Was Watching

An engineer at Rakuten started a job and walked away. Seven hours later it was finished: a working implementation inside vLLM, an open source library of roughly 12.5 million lines, accurate to 99.9% against the reference version. One run. No steering. Nobody in the room.

Read that twice, because it lands two ways at once. Seven hours of senior engineering time, recovered out of nowhere. And seven hours of decisions made inside a codebase by something that never once stopped to ask a question.

Alibaba shipped Qwen3.8-Max this month and says it has sustained runs of ten days and longer, empty repository to production. Prime Agent runs its sessions as daemons now, so the work outlives your terminal. Discount whichever vendor number you like. The direction does not move.

The obvious reading is that the tools got faster. That reading will cost you. What happened at Rakuten is not a better tool for the work you were already doing. It is a different unit of delegation, and it carries a cost structure with almost nothing in common with two weeks of a person iterating.

The shift lands on whoever runs the team, not on whoever writes the code. It changes how you scope work, what you hire for, and where your review time goes. Those three are what I want to get to.

What a Loop Actually Is

The mechanic underneath is simpler than the results make it sound.

An agent runs inside a plain loop. Each pass starts a brand new process, reads the same goal, does one unit of work, and exits. Nothing carries forward inside the model. Whatever it needs to know about what already happened, it reads back off disk at the start of the next pass.

Simple to the point of feeling like a trick, and it is what explains the seven hours.

If you have used a chat assistant for anything sustained, you have watched quality drift over a long thread. I wrote about why that happens: every turn re-sends the entire conversation, so a thread carries its own accumulated weight and the weight only grows.

A loop refuses to accumulate. State lives in the repository instead of the conversation, which makes the repository the memory. The goal is the only thing that persists between passes, and every pass gets a clean start. Files on disk do not decay the way a transcript does.

The origin is faintly ridiculous. Geoffrey Huntley put a coding agent inside a while true loop in 2025 and named the technique after Ralph Wiggum, on the theory that something deterministically simple beats something clever in an unpredictable world. It picked up a serious name in June, after Peter Steinberger compressed the idea into a sentence and Addy Osmani published an essay giving it an anatomy. People call it loop engineering now.

The Unit of Delegation Changed

Here is the part that matters if you run a team.

Delegating to a person is forgiving. You can hand over something half-specified and it usually survives, because the person absorbs the gap. They ask a question. They infer what you actually meant. They notice the requirement you forgot and push back before burning a week on it. Most task descriptions in most organizations are worse than we like to believe, and they work anyway because somebody is quietly repairing them on the way through.

Delegating to a loop is not forgiving. There is nobody absorbing the gap. Hand a loop an ambiguous goal and it will not stop to ask you about it. It will run for six hours on your ambiguity and hand you six hours of confidently wrong work, which costs considerably more than six hours of nothing.

So the scarce skill moves, though not to where most of the coverage points. Prompting is what you do from inside the loop, steering as you go. Unattended work has no inside. What it needs instead is specification: the goal, the constraints, and the finish line stated precisely enough that something can work against them with nobody in the room.

That skill has always been valuable. It has also always been optional, because there was a person on the other end covering for you. It stops being optional.

The Migration Nobody Wants to Staff

Here is the shape of work I keep running into. What follows is a composite rather than a particular engagement, assembled from a pattern rather than lifted from any one client.

A legacy enterprise application sits on a framework going end of life. Several hundred files are in scope. The changes are mechanical but not trivial, the kind where a regex gets you sixty percent of the way and then quietly corrupts the rest. There is a test suite. It is not comprehensive but it mostly works. Everyone agrees the migration is necessary. Nobody wants to be the person who staffs four months against it, because four months of migration work is four months not spent on anything a customer will ever notice.

This shape suits a loop, and the reasons generalize, so they are worth naming.

It is bounded. You can enumerate the work before you start. You know roughly how many files are in scope, and you can tell when you have touched all of them.

It is repetitive with variation. Too mechanical to hold a person's attention, too varied to hand to a script. That gap is where loops live.

It is verifiable by a machine. It compiles or it does not. The tests pass or they do not. The loop can check its own work and correct itself without waiting on anyone. Of the four properties, this is the one that actually decides whether a loop is viable. The rest are negotiable.

Done is definable up front. Green build, green tests, no remaining references to the old framework. You can write that sentence before any work begins, which means the loop has something real to run against.

In practice a pass looks unglamorous. The loop reads the goal, picks up the next file still referencing the old framework, makes the change, runs the tests, and either commits or records what broke. Then it exits. The next pass starts fresh, reads the repository, and finds the next file. There is no cleverness in the individual step. The leverage is entirely in the fact that the step repeats without you.

Now the part that gets skipped in the enthusiastic version of this story. The loop does not remove the four months of risk. It relocates it. The time moves out of doing the migration and into specifying it and reviewing what comes back. That is usually a good trade and I would take it most of the time. It is not a free one, and a plan that treats it as free will be wrong about the schedule.

If you want a smaller first candidate, backfilling test coverage on a service nobody owns has the same four properties with a fraction of the blast radius. Bounded, repetitive, machine-checkable, and done is a number you pick in advance.

What a Loop Cannot Do

A loop can execute the migration. It cannot decide the migration.

Worth pulling apart, because that distinction carries most of the weight in this whole argument. Choosing which framework to target is a judgment call. Deciding which modules to deprecate rather than port is a judgment call. Working out which compromises are acceptable, and which ones quietly become someone's problem in three years, is a judgment call. Every one of those is a decision made under ambiguity, and ambiguity is precisely what a loop converts into confident output.

The general rule I would hand anyone evaluating this: loops suit work where success is checkable by a machine. When the definition of done is "we will know it when we see it," you do not have a loop-shaped problem. You have a conversation that has not finished yet.

The poor fits follow from that and are reasonably easy to spot. Design decisions. One-shot operations, where there is nothing to iterate against. Production debugging, where a confident wrong answer is expensive and the feedback signal is noisy. Anything where the person asking cannot yet say what they want.

One more item belongs in the honest column. Somebody still has to read the result. A four hundred file diff produced overnight is not self-evidently correct because the tests are green, and reviewing machine-generated change at that volume is a different skill from reviewing a colleague's pull request. Teams tend to discover this the first time they try it.

There is an anxious version of this question that comes up in every room, and it deserves a plain answer rather than a reassuring one. The work that survives is the work that was always the hard part. Deciding what to build, what to leave alone, and what correct means was the difficult half of the job before any of this existed. It is also the half that does not delegate.

Three Things This Changes

If you accept the delegation framing, three consequences follow, and they land in different parts of the organization.

Hiring moves first. Specification and verification skill rises relative to raw implementation speed. The person who can write an unambiguous definition of done, and who can tell whether a large machine-generated change is actually correct, becomes more valuable than the person who produces code quickly. Most technical interviews are still built to measure the second thing.

Scoping is the harder one to fix. Work has to be cut into pieces with machine-checkable finish lines, which is a planning discipline rather than a tooling change, and most backlogs are not written that way today. "Improve the onboarding flow" is a perfectly reasonable ticket for a person and a useless goal for a loop.

Scoping also moves money. An unattended run converts work that used to be headcount time into compute, and those are different budget lines with different approval paths and different people guarding them. The first time you scope a migration this way, the interesting conversation is usually not the technical one.

Review is the least intuitive of the three, because output is visible and setup is not. You stop reviewing only what came back and start reviewing what you sent: the goal, the constraints, and the conditions under which the thing stops. A loop with a good goal and no stop condition is a liability regardless of how good the output looks on the morning you check it.

I am less sure about the hiring claim than the other two, in fairness. It is the kind of thing that sounds obvious written down and then takes three years to show up in an actual job description.

The Part Nobody Budgets For

Which brings me to the thing I have been circling.

Somebody has to own what stops it.

An agent that can run productively for seven hours can also run unproductively for seventy. The controls that prevent that are unglamorous, individually cheap, and routinely skipped, mostly because they are boring next to the part where you watch an agent build something overnight. They are also the difference between a technique you can put in front of a client and a story you tell at a conference.

That is an engineering problem, not a leadership one, and it has real answers. Part two is about those.

The Question That Replaced the Old One

For most of the last two years the question in the room has been whether the model can actually do the work. That question is closing, and faster than most planning cycles assume.

The one replacing it is harder, and more familiar than it looks. Can you describe the work well enough to hand it over? And do you know what will stop it if you turn out to be wrong?