Stop Being the Thing in the Loop

Leadership · AI · Systems Thinking

When I coached, I never won a game by calling the perfect play on every snap. No coach does. You win by building a system that runs without you standing over it.

The players read the defense. The checks are already built in. Your fingerprints are on every play, but your hands aren't.

The best coordinators figured this out a long time ago. The quarterback calling every play at the line doesn't scale. The coordinator who designed the system does.

I bring that up because the same shift just hit AI, and most people missed what it actually means.

What Changed

For two years, the skill everyone chased was the prompt. Write a good prompt, get a good answer, repeat. We called it prompt engineering and treated it like the whole game.

Then in June, a developer named Peter Steinberger posted one line that broke the internet for a week: "You should be designing loops that prompt your agents." Boris Cherny, who leads Claude Code at Anthropic, had said nearly the same thing days earlier. His job now is to write loops, not to prompt.

They gave it a name. Loop engineering.

Here's the plain version. You stop being the person who types the prompts. You build the system that does the prompting for you, runs on its own, and stops when the job is actually done.

That's the quarterback becoming the coordinator. And it isn't just a coding idea. It's an operating idea.

What a Loop Actually Is

Strip away the hype and a loop is simple. It runs the same four-beat cycle every time.

It acts. It observes what came back. It reasons about whether that moved it closer to the goal. Then it repeats, or it stops.

The part that matters most is the stop. A loop doesn't run until you decide to check on it. It runs until a condition you defined is met. "All tests pass." "Every lead is triaged." "The draft scores above the bar." You define done. The loop chases it.

That one detail is the whole difference between a system and a runaway.

Open Loops and Closed Loops

There are two ways to build one, and the choice matters more than the tool you build it in.

An open loop gets a goal and loose guardrails, then finds its own path. Good for exploring. Unpredictable on cost.

A closed loop gets a mapped route, defined steps, and a clear rubric for what good looks like. Predictable. Auditable. Boring in the best way.

For most operators, the closed loop is the right default. Known workflow. Defined outcome. A result you can stand behind. You don't hand an open loop the keys to your business and walk away. You map the route first.

Where This Goes Wrong

This is the part I'd make every leader sit through before they touch it, because a loop multiplies whatever you put into it. Good and bad.

No stop condition is the expensive one. Uber told its engineers to use AI as much as possible, even ran internal leaderboards for it, and burned through its entire annual AI budget in about four months. Then they capped each engineer at $1,500 a month per tool. A loop with no floor doesn't get tired. It just keeps spending.

The quieter risk is comprehension debt. The faster a loop ships work you didn't do yourself, the wider the gap between what exists and what you actually understand. Speed without understanding is a bill that comes due later.

A loop without taste just gets you to wrong faster. If your standard for "good" is fuzzy, the loop scales the fuzziness.

It runs your judgment a thousand times. If your judgment was sharp, that's a thousand good calls. If it wasn't, that's a thousand mistakes with your name on them.

The Part People Are Getting Backward

Everyone keeps asking whether this kills prompt engineering. It doesn't. It raises the stakes on it.

When you were typing prompts one at a time, you could catch a bad one and fix it on the next try. You were in the loop. Now you're not. The instruction you write at the start becomes the foundation for hundreds of steps you will never watch happen. The quality of your thinking doesn't matter less. It matters more, because it's no longer something you correct as you go. It's something you build in once and live with.

This is the same lesson I keep coming back to. The tool amplifies whatever is already there. A loop doesn't create good judgment. It scales the judgment you already had. The people winning with this aren't the ones with the best agent. They're the ones who already had standards worth scaling.

Where to Start

If you run a team and you want to think in loops, don't start with code. Start with one thing your team does the same way every week.

Pick a workflow that's predictable, visible, and owned. Lead triage. Follow-up drafts. Scanning requirements off an RFP.

Write down what "done" looks like before anything else. If you can't define done, you're not ready to build the loop.

Decide who checks the work. The system that does the work shouldn't be the only thing grading it.

Keep it closed. Map the route. You can loosen the guardrails later, once you trust what it does.

That's the whole shift. Stop calling every play yourself. Build the system that runs the play, and put your judgment where it actually compounds.

The coordinator never touched the ball. He still decided the game.