Stop Prompting Your Coding Agent. Start Writing Loops.

Short answer: writing loops means you stop being the one who prompts the agent and write the thing that does it: a program or a scheduled agent that finds the work, hands each piece to an agent, checks what comes back and decides what’s next. The smallest one worth running this week: a scheduled agent that wakes each morning, reads every issue opened since yesterday, labels it, drafts a repro and flags the two or three that need you.

Last time I wrote about encoding my process as agent skills: grill the idea, write the PRD, slice it, build it, keep the instructions lean. I thought that was the top of the ladder. Then I watched Boris Cherny, the head of Claude Code, describe the rung above it, and realized I’d only climbed halfway.

His line, on the Acquired Unplugged stage, roughly: a year ago he wrote code with autocomplete. Then he was running five or ten Claudes in parallel, and his “coding” was prompting each one. Now? “I don’t prompt Claude anymore. I have loops that are running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.”

Read that again. The unit of work moved from the keystroke, to the prompt, to the loop.

Which rung of the abstraction ladder are you on?

Boris frames coding as one long climb: punch cards, then assembly, then C, then the high-level languages, then the really high-level ones. “The level of abstraction always goes up.” Prompting an agent is just the next rung. And so is the one after it.

Where are most of us right now? Rung two. We prompt. Maybe we run a couple of agents at once and feel cutting-edge. The jump Boris is describing is rung three: you stop being the thing that prompts. You build the thing that prompts, and it decides what to work on, dispatches the agents, and checks the results without you in the keystroke path. That’s the shift from human in the loop (you approving every step) to human on the loop: you design the system and supervise it from outside, instead of sitting inside every iteration.

That sounds like sci-fi until you realize the primitives already exist. And no, this isn’t just cron jobs with a fresh coat of paint. We’ve scheduled scripts for twenty years, but a script does exactly what you wrote, while the agent inside this loop reads your whole codebase and decides for itself what to work on. That’s the whole shift. The scheduling is trivial and always was; the work is in the gate you put on what the agent hands back.

What is a loop? Orchestration, not magic

Strip the mystique, and split it in two. The harness is the equipment: the tools, skills, and MCPs you hand an agent so it can actually do the job. The loop is the orchestration around it: figure out what work exists → hand a chunk to an agent → check what came back → repeat, and decide when it launches, when it advances, when it stops. The harness is what the agent can do; the loop is when and how often it does it. You’re not writing the code. You’re not even writing the prompts. You’re writing the thing that writes the prompts.

In Claude Code today, that’s not a metaphor. It’s a handful of real primitives:

• Workflow scripts: deterministic code that fans work across many subagents (run them in parallel, pipe each item through stages, loop until a queue is dry or a token budget runs out). This is literally a loop that prompts Claude.
• Background and parallel agents: fire off a fleet, each on its own slice, all at once.
• Scheduled / cron agents: the part that makes it autonomous. An agent that wakes up on a schedule, reads your GitHub issues, your feedback, your Slack, and acts.

That last one is exactly what Boris described running at scale: “a couple hundred Claudes running… looking at Twitter feedback, GitHub issues, Slack. They’re figuring out what to build next.”

You don’t need a hundred. The smallest real loop you can run this week: a scheduled (cron) agent that wakes once each morning, pulls every issue opened since yesterday, and runs one instruction against each. Read it, check it against the codebase, label it, draft a repro, flag the two or three worth your time. That’s a single scheduled agent with one skill file and a token ceiling, not a fleet. It’s rung three, today, with one agent. You read its output before you trust it, then build up from there.

Here is that loop as a script. Cron runs it each morning from your repo; gh finds the work, headless Claude Code (claude -p) does each piece, and a label marks it done so tomorrow’s run skips it:

#!/usr/bin/env bash
# triage.sh, from cron: 0 7 * * * cd ~/code/my-app && ./triage.sh
set -euo pipefail

for n in $(gh issue list --search "-label:triaged" --json number --jq '.[].number'); do
  claude -p "Triage GitHub issue #$n. Read it with gh issue view, check it against this codebase \
and leave one comment: likely cause, a minimal repro if you can write one, and P1, P2 or P3. \
Don't change any code." \
    --allowedTools "Read" "Grep" "Glob" "Bash(gh issue view:*)" "Bash(gh issue comment:*)" \
    --max-budget-usd 0.50 < /dev/null
  gh issue edit "$n" --add-label triaged
done

Three lines carry the weight. The --allowedTools list lets the agent read code and comment, nothing else. --max-budget-usd is the stop condition per issue. And the check is you, reading the comments over coffee, until the loop has earned less of your attention.

Why skills are the prerequisite (this is the sequel, after all)

Here’s the part people skip straight past, and it’s the whole reason I wrote the skills post first.

You cannot safely automate the invocation of a process you haven’t encoded.

A loop doesn’t make an agent smart. It makes it frequent. If the agents inside your loop don’t follow a real pipeline (grill the idea, slice it vertically, build with discipline, obey a slim AGENTS.md), then a loop just generates garbage faster. A firehose of plausible-looking wrong. And the prompts the loop fires still have to be good ones. The fundamentals of writing a sharp prompt don’t stop mattering just because a script is typing them instead of you.

Skills are what turn a loop from a slop machine into a process that runs itself. Boris said the same thing, almost in passing: companies keep “principles documents” to avoid making the same decisions over and over, and “the model can use these principles also, and it comes in the form of skills.” Rung two (skills) isn’t a detour on the way to rung three (loops). It’s the load-bearing wall.

The honest part: most of what a loop spits out is bad

I’m not going to sell you the dream without the asterisk.

Boris, about his hundreds of agents hunting for what to build: “most ideas are bad, but maybe 20% are good.” Twenty percent. From the person who built the tool.

And Anthropic’s own essay on recursive self-improvement lands on the same bottleneck from the opposite direction. Their framing of the trajectory (humans writing code, then agents writing whole files, then agents handing hours of work to other agents) sounds triumphant until you hit the catch: human review has become the bottleneck. The execution got cheap. The judgment didn’t.

So a loop without a filter is a liability, not leverage. The thing that makes loops survivable is the gate on the output: an adversarial review pass, a hard quality check, tests that actually fail. The loop generates; something has to be the bouncer. If 80% is junk, your edge is the speed and quality of your “no.”

And there’s a second meter running: money. A loop that fans out chained subagents while you sleep doesn’t just produce slop, it bills you for it. Every unsupervised iteration spends tokens whether the output is worth keeping or not, so a token ceiling and a stop condition aren’t nice-to-haves: they’re part of the harness. Give it a hard cap (five dollars or twenty iterations a night is plenty to start), and make it halt and ping you when it hits the cap rather than grinding on blind. Decide both before you ever let one run unattended.

Where this is heading (and why it’s not just hype)

Zoom out and Boris’s “I write loops” is the personal-scale snapshot of what Anthropic argues is happening to the whole field. Their essay sketches a future where AI increasingly automates AI development itself, and the human role compresses toward one thing: direction and judgment. Choosing what’s worth doing. Knowing a good result from a bad one.

I’d take the specific numbers with tongs, and to their credit, so do they. They openly hedge that lines-of-code is a lousy productivity metric, that self-reported gains are probably inflated, and that whether today’s models can develop real research taste on their own is, in their words, genuinely unclear. That hedging is exactly why the essay is worth reading: it’s bullish on the trajectory and honest about the uncertainty. The direction is real even if the dates aren’t.

What stays yours

Here’s the thing the ladder is quietly telling you.

Each rung you climb, your edge stops being the thing below it. It stopped being “I can write the code.” It’s about to stop being “I can write the prompt.” What’s left, at the top, is the stuff that doesn’t automate: deciding what’s worth building, judging what comes back, and the values you bake into the system that runs while you sleep.

Boris was asked what the last human-only skill will be. His answer: “the final thing we’re going to be teaching the model is values. The way we teach our kids how to be good people, we’re going to teach the model how to be a good model.”

So don’t romanticize the loops. Build one. Encode your process as skills first, wrap a small loop around it, and put a brutal review gate on whatever it produces. That’s the whole move: rung three doesn’t need a hundred agents. It needs one good loop and your judgment on the other end.

You’ve already got the smallest version, a few paragraphs up. Tonight, point one scheduled agent at a single issue label, give it a token ceiling, and in the morning read what it drafted before you trust a word. That’s rung three, this week, supervised. Build out from there once it’s earned your trust.

Related reading: this only works if the process underneath is solid. Start with the five agent skills that run my whole workflow, then wrap a loop around them. And which model you point the loop at matters: I dug into the one I now reach for in my Claude Fable 5 review.

Sources

• Boris Cherny (Head of Claude Code), Acquired Unplugged: the “I write loops” remark and the “most ideas are bad, ~20% good” line, via @codingvic’s clip on X.
• Anthropic, Recursive self-improvement: the company-scale framing and the hedges.

P.S. Building loops in anger? I want to hear what you’ve automated and what blew up in your face. Find me on LinkedIn.