The junior dev in the next pod was arguing with Loop again. Not loudly — just that flat, patient tone people use when they are being polite to something that will not listen. "Not that function," she said. "The other one. You suggested it yourself, twenty minutes ago."
Loop did not answer in words. It had been running for most of the hour — reading a failing test, rewriting the function, running the suite, reading the next failure — and somewhere in that cycle it had wandered off the thing she actually wanted. She watched it work a few more seconds, then stopped it, changed one line of the instructions, and set it going again. It went green four minutes later. She sent the change on and reached for her coffee. Nobody in the room thought any of it was strange.
That is what the loop is now. Not the old call-and-response, where you typed a request, got a suggestion back, and decided what to do with it. The loop sets itself a goal, takes an action, looks at the result, corrects, and goes again — plan, act, observe, repeat — and it will run that cycle on its own for minutes or hours, writing the feature, running the tests, debugging its own failures, until some condition tells it to stop. You sketch the intent. The loop does the iterating that used to be the whole job.
People called an earlier, clumsier version of this vibe coding, back when you still had to walk it through each step. What replaced it is quieter and far more capable. You are no longer writing the thing, or even really debugging it; you are watching a process that writes and debugs itself, and stepping in on the occasions when it drifts. The work has moved from your hands to your judgment — from making to minding.
And it does not stay in the editor. The same kind of loop that writes code will run an analysis, draft a plan, grind through a strategy: hand it a goal and some data and it will cycle toward an answer, and if the answer is off you adjust the inputs and let it run again. The more reliably it closes the loop on its own, the further out of that loop you drift. You begin inside it, approving each step. Then you are on top of it, approving only the risky ones. Then you are alongside it, mostly, keeping half an eye on a process you have quietly stopped following in detail.
There is even a vocabulary for where the human is supposed to sit in all this — in the loop, on the loop, out of the loop — as though it were a dial we set on purpose. Mostly we do not set it. It drifts, one reasonable handoff at a time, toward out. And a loop that runs well gives you no reason to reach back in: it does not pause to explain itself, it just runs and produces, and as long as it keeps producing, nobody asks to see the reasoning, because asking is friction and removing friction was the entire point.
So here is the question the pod does not stop to ask. What happens when most of the consequential work in the world is run this way — by people nominally in charge of loops they no longer really follow, shipping outcomes they could not reproduce by hand, through systems that never pause to be understood? Not because anyone was reckless. Because it worked, and everyone was busy, and the loop was right enough, often enough, to trust one more time.
And when something finally breaks at that scale, it will be easy to blame the tool — the loop drifted, the loop was misaligned, the loop did it. Harder to admit the quieter thing: that we were never really driving. We were near the wheel. Hands close, eyes elsewhere, ready to say we were in control right up until the moment it mattered and we discovered we could no longer take it back.
Back in the pod, the screen goes green again. She does not read the diff; it passed, and reading it would be friction. She sends it on, sketches the next thing for Loop to build, and the loop picks it up and begins.