Boris Cherny, who built Claude Code, described the shift plainly, in a piece Gergely Orosz collected the reaction to: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” Addy Osmani’s gloss on the same shift is the sharper version: loop engineering means replacing yourself as the person who prompts the agent, and designing the system that does it instead.
The easy half of loop engineering
The part everyone got excited about is also the easy part. Andrew Ng broke his own loop-writing down into three layers any team can build in an afternoon: an agentic coding loop that runs every few minutes, where the agent writes code, tests it, and iterates until a spec is met; a developer feedback loop that runs over hours, where a person steers direction; and an external feedback loop that runs over days or weeks, where real users and real production data settle what the first two loops got wrong.
None of that is the hard part. A loop that calls itself until a test passes is a tutorial, not a skill. Every team currently posting about their loop architecture on social media has already solved the trivial half of this problem.
Wil Chung made a sharper counterpoint in the replies: none of this is new, it’s control theory and cybernetics with a fresh name, the same feedback-loop mathematics engineers have used for decades to keep a thermostat or an autopilot on target. I don’t mean this as a takedown of loop engineering. It’s the whole point. A control system has always needed an explicit target and an explicit tolerance before its feedback loop means anything at all. Software teams discovering this requirement for the first time, at the level of shipping product decisions, are relearning something control engineers have always understood and practiced.
What the stop rule actually requires
Two replies to Ng’s own thread named the hard part better than the post did. Xi Zeng asked the question the excitement skipped: what’s the stop rule? An agent can iterate for a long time and still be polishing the wrong thing, because a loop only knows to keep going until something tells it to stop, and that something has to be defined by a person before the loop starts. It cannot be discovered by the loop while it runs.
That definition is a verifier: an explicit statement of what counts as good enough, specific enough that a machine can check itself against it without a human re-reading every pass. I’ve written before about why extracting this is the actual bottleneck in any AI-assisted process, agentic loop or otherwise. The standard has to come out of the judgment of whoever currently makes that call by instinct, and that extraction is slow, uncomfortable work no amount of loop-writing skill shortcuts. A loop with a vague verifier doesn’t fail loudly. It converges confidently on the wrong answer, at speed.
The loop nobody names
Marcus Spillane named the other missing piece: the approval loop. An agent finishes a task in forty minutes. Then it waits three weeks for a security review, a legal sign-off, a change advisory board meeting. Build fast, deploy slow, as the reply put it, and that gap is the real constraint in most organisations running these loops today.
I’ve watched this exact gap play out: a working prototype ready before lunch, and a review and sign-off that took longer to arrive than the build did. Orders of magnitude longer. Weeks of delay spent in endless discussions while the value-creating work sat on a virtual shelf, benefitting nobody. The build loop was never the bottleneck. The outdated process behind it was.
This isn’t a problem loop-writing skill touches. It’s the one I described in AI Won’t Save the Kingdoms We Built: AI compresses the work inside a loop to minutes. It does not compress an organisation’s willingness to let something ship that fast, and no framework for writing better loops changes that willingness at all. The approval loop was never a technical loop. It’s a decision-rights problem wearing a technical costume, and it was there long before anyone called any of this a loop.
Both gaps point at the same underlying fact. Writing the loop is a solved problem, cheap enough that anyone can pick it up in a weekend. Deciding what the loop is allowed to call finished, and who has to agree before it ships, was never solved by writing it faster.
“My job is to write loops” is a true sentence, but it undersells its own claim. The job did not move from prompting to writing loops. It moved from doing the work to deciding, in advance, what counts as the work being done, and by whose authority. That decision was always someone’s job. Loop engineering just made it obvious how often nobody currently owns it, or how inefficient most business processes remain, in ways that risk making AI-enabled work deliver worse outcomes than before.
Writing the loop was never the hard part. Deciding what it’s allowed to decide is.
Leave a Reply