From prompt engineering to loop engineering
The people who built Claude Code have stopped writing prompts and started writing loops. Here is what loop engineering actually is, why it behaves like closed-loop control, and where the engineering effort really goes.
I keep a short list of sentences that changed how I work. A recent one came from one of the people who built Claude Code, who said — more or less — that he doesn't write prompts anymore. His job is to write loops.
When the person who shipped the tool tells you he has stopped using it the way the rest of us do, it is worth sitting with. This is not a productivity tip. It is a statement about where the work went.
The prompt was never the system
A prompt is a single request. You phrase it well, you send it, you get one response, and the quality of that response is mostly settled the moment you hit enter. Prompt engineering was the craft of making that one shot count: the right framing, the right examples, the right constraints.
Loop engineering is the craft of building the thing around the model that decides what to send, checks what comes back, and sends again. You stop optimizing the message and start designing the system that produces the messages. The model becomes a component inside a program you wrote, not the program itself.
What a loop actually is
Strip away the vocabulary and a loop is plain. You define a goal and a way to know when it is met. The model proposes a change. Something deterministic — a test suite, a compiler, a linter, a type checker — judges that change. If it fails, the failure goes back into the model's context as the next instruction. If it passes, you stop. Then it runs again, and again, without you in the seat between iterations.
The important part is the judge. The model does not have to be right on the first try; it has to be able to get closer when handed a concrete error. A failing test is a far better instruction than anything I would have typed by hand.
Why this is a control problem
I trained as a physicist, so the shape of this is familiar. A single prompt is open-loop control: you set the input, you hope for the output, and you have no mechanism to correct for everything you could not predict. Closed-loop control measures the result and feeds the error back. We do not fly aircraft or hold a temperature open-loop, because the disturbances you cannot model are the ones that dominate. Language models are full of disturbances you cannot model. The remedy is the one engineering reached for a century ago: close the loop and let feedback do the work the open-loop guess cannot.
That reframes "is the model smart enough" into a more useful question: can I measure whether it succeeded, cheaply and reliably, and feed that measurement back?
The engineering moved; it did not disappear
People hear "I don't write prompts" and assume the work got easier. It moved. The surface you tune now is the loop's parts:
- The verifier — what counts as done, and how you check it without a human in the loop. This is the hard one, and the one most teams underinvest in.
- The context — what the model sees each turn, and what you prune so it does not drown in its own history.
- The tools and environment — what the agent can actually do, and how safely it can do it.
- The stopping condition — when to declare success, and when to quit so the loop does not burn money chasing a goal it cannot reach.
In production, the bottleneck is almost never the model's raw ability. It is the verifier. A loop is only as good as its ground truth; point it at a weak signal and it will optimize, confidently, toward the wrong thing.
What I tell my teams
Spend your effort on evaluation, not on wording. If you cannot separate good output from bad automatically, you cannot build a loop — you can only supervise one by hand, which is the work you were trying to stop doing. Decide the stopping condition before you start the loop. Put a budget on it. Keep a person at the checkpoints that carry real risk, and let the machine handle the iterations in between.
Prompting is not dead. It is one line inside the loop. The leverage is the loop, and the people who built these tools have already moved there. The work is no longer finding the perfect words — it is designing the system that no longer needs them.