From vibecoding to loops to graphs

On 7 June, Peter Steinberger wrote that you should not be prompting coding agents any more. On 18 July, he asked whether we had moved on to graphs. In between, we found time to give a talk about loops.

This piece explains all three steps, and where you should be standing. The short answer is that you have missed nothing: the loop is still the unit, and if you have not built one, that is where you start.

From vibecoding to loops

Vibecoding is describing what you want to build and letting an AI like Claude Code write the code while you watch. That is still how most people use the tool, and it works well.

Among the heaviest users, the pattern has started to change.

Peter Steinberger, the person behind OpenClaw, put it this way on X on 7 June 2026:

Boris Cherny, who created Claude Code at Anthropic, was even more concrete in a conversation with Acquired that same month:

Two people who know these tools better than almost anyone are saying the same thing: the work has moved from writing prompts to designing the processes that write the prompts.

What a loop actually is

A loop is not a new app or a new tool. It is a way of assembling the ones you already have. Five steps that repeat:

The hard part is not the loop itself. It is deciding when it should stop: what counts as done, how much it may spend getting there, and what has to happen for a human to step in. Without a stopping rule it runs all night and produces rubbish.

Two examples, one technical and one not

For developers. A loop that wakes up when a pull request arrives. It goes through the changes, runs the tests, and merges the code when everything is green and safe. Only the risky changes reach a human.

For everyone else. A loop that runs a newsletter. Every morning it sweeps its sources and writes a draft. A separate editor agent reads it against the tone you have set. Then the loop schedules and sends it itself, and gets sharper at picking with every issue. You do not read every draft. You hear from it when something is actually wrong.

Nobody prompts them at every step. Nobody sits there minding them.

Why this concerns you, not just the developers

The past six months have been demanding for developers working with AI. Writing the code is no longer enough, and neither is asking an agent to write it. Now you have to ask agents to both write and review the code, and to steer several of them at once. Anyone who does not is visibly behind.

This is not a developer problem alone. Anthropic's own Economic Index shows that 49% of occupations already have at least a quarter of their tasks done with Claude. Developers were simply first.

But the conclusion is not that everyone should now build their own app. Building was never the whole point. It was just what the tools got good at first. What has actually changed for the people furthest ahead is that their work is now about designing processes others run, rather than carrying out the tasks themselves.

Where this goes next: graphs

On 18 July 2026, Steinberger asked a new question on X: are we still on loops, or have we moved to graphs? The post drew 575,000 views within hours.

A graph is several loops wired together, each keeping an eye on the others. One loop optimises, another watches that it is not optimising the wrong thing. A third moves more slowly and checks that the goals still match reality.

It is worth knowing where this is heading. It is also worth saying plainly: a graph does not replace loops, it connects them. A critical review of the term concludes that “graph engineering” is for now a new name for composing agents as stateful workflows, not a new technology or an established method.

The loop is still the unit. The graph is what you do once you have several of them.

How to get started

Do not try to learn it all at once. Start with one question: what is the first loop you could design?

Pick something small. One trigger, one job, one message to you when it needs a human. If you have not built one yet, that is where you start — not in the graphs.

Most people working this way today use Claude Code as the engine. The same tool that made vibecoding possible, set to run a fixed process instead of answering one prompt at a time. The principle is the same as with vibecoding: you do not need to understand all the machinery. You need to know what you want out, and be able to describe the process clearly enough that the agent lands it.

Want to see what this looks like in practice, at a real company with real customers? Read How AI agents changed the running of Atelie — Christian's first-person account of running a platform with over 1,000 artists on agent teams.