Why I Stopped Prompting AI and Started Building Loops Instead

... Last month, Peter Steinberger dropped a tweet that hit eight million views: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Around the same time, Boris Cherny—creator of Claude Code—said something similar on Acquired Unplugged: "I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude."

And then the internet did what the internet does: everyone argued about it, nobody saw a loop, and the discourse became a mess of abstraction.

I've been running actual loops for the past several months. Not because I'm ahead of the curve—I just got annoyed enough with manual triage work that I automated it. What I found surprised me: the loop mindset isn't some advanced technique for AI power users. It's actually a natural evolution that happens once you stop treating AI agents as sophisticated copy-pasters and start treating them as systems that can monitor, decide, and act on your behalf.

The Three Flavors of "Loop" Nobody Agrees On

Here's why this conversation gets messy: when people say "loop," they could mean one of three things, and the differences matter.

First, there's the autonomous task loop—essentially "keep going until done." Think Geoffrey Huntley's Ralph script (while :; do cat PROMPT.md | claude-code; done), or the /goal command that Codex and Claude Code now ship natively. This is the "set it and forget it" mode.

Second, there's the scheduled or event-driven loop—work that runs while you're not in the chair. Peter Steinberger's own HEARTEBEAT.md in OpenClaw is the canonical example: a checklist the agent reconsiders every 30 minutes. Descendants of this pattern include Codex automations and Claude Code's scheduled routines.

Third, there's orchestration fan-out—dynamic workflows with multiple agents running concurrently. Claude Code's map/reduce-style operations fall here. This is closer to the actor model than anything resembling a simple loop.

My take? Steinberger and Cherny are describing the second type, wired into the first. The loops I run are scheduled and event-driven on the outside, and several of them execute experiment-style inner loops once they trigger. That combination is where the real leverage lives.

The PR Babysitter: My Gateway Drug to Loop Design

I already had AI code review on every pull request. Claude reviewed first, then Codex's built-in review, then a custom GitHub Action where I controlled exactly what the model saw—pulling in full conversation context plus the patch diff.

My actual workflow was absurd: submit a PR, wait for reviews to come back, then copy-paste review comments into the agent. Sometimes I'd paste screenshots. It was manual, repetitive, and soul-crushing.

One day I asked my agent: "Can't you just use the gh client and check the review status yourself?" It could. So naturally, I asked: "Can't you just keep checking and tell me when it's done?"

That single request transformed my workflow. The agent now watches for review status changes, pulls in new context, analyzes the feedback, and does the actual work of addressing it. The loop ends when it reaches a triage decision: accept the feedback, push back on it, or escalate to me.

The pattern generalizes beautifully: watch for state changes in external systems, wake up when they occur, pull in fresh context, analyze, act, and triage. Once you see this shape, you start spotting it everywhere. The Codex team ships their own babysit-pr skill, and Claude Code's docs now name PR babysitting as a headline use case for their /loop command.

Inner Loops: Making the Agent Run Its Own Experiments

There's another loop pattern that took me longer to appreciate: the experiment loop. Andrej Karpathy's autoresearch concept got me thinking about this—running many iterations, measuring results, keeping what works. I pointed this at a slow Python path and ran 49 experiments in an hour, pushing p95 latency from 339ms down to 34ms for about $24.

The same pattern applies to harder problems: debugging agent behavior in production. When something goes wrong—a weird trace in Braintrust, user feedback in Slack, or something I hit myself—I spin up a worktree, paste in the trace, and invoke the test loop.

Here's what makes this loop different: it forces a discipline that the model's naive intuition fights against. Left alone, a model will hardcode "never do X, Y, Z" into the system prompt and overfit to the one trace you showed it. The skill's references distill the research on why that approach fails, and the loop contract requires a hypothesis and a test matrix.

I need three cases: the original failing case, an adjacent positive that should take the same path, and a counterexample that should take a different one. Three or four probes run concurrently against local dev, reconstituting the exact user context from the trace. Each run gets scored on tool calls, latency, input-token delta, and correctness. The model can't cheat by memorizing—it has to actually understand.

What Actually Changes When You Build Loops

The biggest shift isn't technical—it's conceptual. When you prompt an agent, you're still the one driving. You're the throttle, the navigator, the quality checker. Loops invert that. You become the architect of systems that drive themselves.

This doesn't mean full autonomy is the goal. I'm still at the triage gate on everything important. The loops handle the tedium, the monitoring, the repetition. I handle the judgment calls that actually matter.

The second shift is that loops force you to be explicit about success criteria. A good loop has clear exit conditions, clear decision points, clear escalation paths. You can't build a loop without defining what "done" looks like. That discipline bleeds into everything else.

Third, loops are composable. The PR babysitter works alongside the experiment loop. Scheduled checks trigger on-call responses. You start building a library of behaviors that work together rather than a pile of one-off prompts.

The Practical Starting Point

If you want to experiment with loops, start with something you've already automated badly. You probably have a GitHub Action that does something on a schedule, or a Claude Code session you manually re-run, or a review process that involves copy-pasting outputs between tools.

Pick the most annoying one. Ask yourself: what state change am I actually waiting for? What context does the agent need when that change happens? What decision does it need to make?

Then build the loop. It doesn't need to be elegant. It needs to work, and it needs to put you back in control of your own time.

The full configs, skills, and CI workflow behind the loops I run are in a public snapshot repo: camwest/agent-skills. It's not a polished product—it's a working system that evolves as I learn. That's the point. Loops aren't a destination; they're a practice.

The discourse around AI agents is drowning in abstraction. Here's the concrete version: stop prompting, start building loops, and see what happens when you let the machine handle the monitoring while you handle the meaning.