A Loop Amplifies Whatever You Hand It

In June, the creator of Claude Code stood on a stage and said, "I don't prompt Claude anymore. I write loops, the loops do the work." Within days the clip was everywhere on X. Another developer told his millions of viewers to stop prompting coding agents altogether and start designing loops that do the prompting for them. By the end of the month the practice had a name, loop engineering, and everyone from Andrew Ng to IBM had published a take on it.

Strip the developer vocabulary and loop engineering means this. Instead of asking an AI for one piece of work and checking what comes back, you set up work that repeats on its own until a condition you defined tells it to stop, and your job becomes deciding what the machine keeps doing while you're somewhere else.

I've been watching the argument with a sense of recognition, because underneath the jargon the developers are fighting about the question I work on every day with coaches and leaders. What happens when you hand work to a machine and step away?

What Loop Engineering Actually Means

Anthropic's Claude Code team published a plain guide to loops that cuts through most of the noise. A loop, in their definition, is an agent repeating cycles of work until a stop condition is met. What makes their guide useful is the ladder inside it. Each kind of loop hands over one more piece of the work.

The first rung is what you already do. You ask, the AI works, you check the result, you ask again. That's a loop with you inside it, turning the crank on every cycle.

The second rung hands over the definition of done. Instead of checking each attempt yourself, you tell the machine what finished looks like and let it keep trying until it gets there.

The third rung hands over the timing. The work runs on a schedule, every Monday at seven, whether you remembered it or not. I made the case for this rung in June, that your AI should be a workhorse, pulling on its own, and most people are still steering.

The top rung hands over the asking itself. The machine watches for work arriving, decides something needs doing, and does it. Nobody prompted anything.

Read that ladder again, because the pattern in it matters more than the technology. What moves down the ladder is never just labor. It's judgment. First the checking, then the call on what counts as done, then the timing, and finally the decision that work should happen at all.

The Fight Is Real on Both Sides

The boosters point to speed and scale. The people running loops well describe handing entire categories of maintenance work to machines that grind through it overnight.

The skeptics have three answers, and they deserve airtime. The first is that none of this is new, that a loop is a decades-old programming idea wearing a new name, and the renaming is what sells. The second is money. Loops burn through paid AI capacity at a rate that makes the evangelism look convenient, and Bloomberg reported in June that Uber had to cap each employee's spend at $1,500 a month per AI coding tool after the budget evaporated. The third answer is the sharpest. Armin Ronacher, a veteran engineer respected across that world, wrote that today's models produce overcautious, overcomplicated work, and a loop takes that tendency and amplifies it. Teams are already splitting into people who produce machine-made work at volume and exhausted colleagues who review it.

But Colin, you don't write code. Why should a coach or a business owner care which way this argument goes?

Because the argument was never really about code. Every part of it, the handing over, the checking, the amplified sloppiness, the person left reviewing a mountain they didn't make, shows up the moment any professional puts AI to work on anything. The developers just got there first and are having the fight in public.

Every Loop Is an Amplifier

Look closely at that fight and something odd appears. The strongest attack on loop engineering and the strongest case for it are the same argument.

Ronacher's critique is that a loop amplifies what the model already tends toward. The boosters' pitch is that a loop amplifies what one person can produce. They're both describing the same machine. A loop is an amplifier, and an amplifier has no opinion about what it's fed.

This is the ground I've built my whole approach on. The human is the source, and the AI is the amplifier. A loop is what amplification looks like with you removed from the cycle. Hand it clear judgment and a real standard, and it multiplies that. Hand it vague instructions and unexamined habits, and it multiplies those instead, at volume, while you sleep.

So the question that matters is the one sitting under the engineering, and it has two parts. What are you handing over? Which piece are you keeping?

I've written before about the first part. The human in the loop is the bottleneck. At any real volume you can't review everything, so the move is to rise above the loop and decide in advance what never runs without you. Your sacred territory. And the two questions that sort the rest, does it need you and does it drain you. The loop debate adds the missing third piece. Once you know a task belongs to the machine, when has it earned a loop?

A Loop Is Earned

Here's what the viral clip left out. A developer went and pulled the full transcripts of those talks, and found that every loop the Claude Code creator actually runs has a machine-checkable finish line. The tests pass, the feedback is sorted, the fix is confirmed. None of them is building a product while he sleeps. The loops that survive in the real world are the ones that can check their own work. The gap between the hype and the practice is wide too. An August study examined 36,710 public code projects and confirmed autonomous loops running in only 217 of them. That's projects run by developers, the people this should be easiest for.

I teach the same rule to every cohort, long before anyone builds anything. Brainstorm. Test. Schedule. The schedule comes last because it has to be earned. You earn a loop on the day you can write down what done looks like, precisely enough that you'd accept the result without watching it happen. If you can't write that check yet, you're not ready to loop the task, and that's useful information. Staying turn-based, asking and reviewing, is where the judgment gets built that will eventually write the check.

I run nine loops in my own working week. One drafts my newsletter every Monday morning from my own notes and conversations. One sweeps yesterday's unfinished tasks forward before I sit down. The one I trust most is the one allowed to produce nothing. It reads the week and drafts an article only when something clears the bar, and most weeks the correct output is no article at all. That stop condition took longer to define than the loop took to build.

Start Where You Repeat Yourself

You don't need to write code to act on this. Pick one piece of work you repeat every week. The client session summary, the Monday numbers pull, the newsletter you assemble by hand. Don't build anything yet. Take a sheet of paper and write the check. What would have to be true for you to accept this work without reading it line by line?

If you can write it, you've found a candidate for a loop, and the tools for running one without a developer are arriving fast. If you can't write it, you've learned something better. That task still needs your judgment inside it, and no amount of engineering changes that yet.

The developers shouting at each other on X are wrestling with the same thing you are, which is what stays yours when the machine no longer needs you present. Nobody has that settled. I don't either. Mine is written on a sheet of paper that I revisit more often than I expected to, and the revisiting, I've come to think, is the point.