Loop Engineering: When You Stop Prompting and Start Managing

In a June 2026 interview, Boris Cherny — creator and Head of Claude Code at Anthropic — said something that reframed the whole skill: "I don't prompt Claude anymore… My job is to write loops." If the person who built the tool has moved past prompting, that's a signal worth reading.

Here's the shift. Prompting is tactical: one instruction, one answer, and you're stuck in the chair — typing, waiting, fixing, typing again. A loop takes the chair. You give it a single goal; it discovers the work, does it, verifies its own output, records what's finished, and repeats until the goal is met. Addy Osmani (Google), who popularized the term "loop engineering," puts it well: a loop is a recursive goal where you define a purpose and the AI iterates until it's complete.

The pieces that make a loop

Osmani names the concrete parts, and each maps to a real Claude Code feature:

• Automations — the loop runs on a schedule, not when you type. Run Claude headlessly with claude -p "your loop prompt" from a scheduler, or use the in-session /loop.
• Worktrees — a Git worktree hands each agent an isolated checkout of the repo, so two can run at once without stepping on each other.
• Skills — a SKILL.md in .claude/skills/ holds the knowledge you keep re-explaining, so every run starts already knowing your project.
• Connectors — MCP integrations (claude mcp add) let the loop touch your real tools: the task board, the inbox, the database.
• Subagents — a builder in .claude/agents/ does the work; a separate reviewer checks it. The agent that does the work shouldn't be the one grading it.
• State — a markdown file (or a Linear board) where the loop writes what it finished, so ten runs become one continuous worker instead of ten fresh starts.

The copy-paste charter

No code required to begin — a loop is just a clear charter you paste into Claude Code. Use it when the work has more than one item (a backlog, a folder, a queue). Fill the brackets:

You are running as a loop, not answering one prompt. Charter:

GOAL
[The finished state in one or two sentences. Make DONE measurable — e.g. "Every
file in /pages passes the link checker and uses the new pricing."]

FIND THE WORK
[Where the work lives: "scan /pages for old pricing", "read TODO.md unchecked
items", "pull my task board items tagged 'ai'."]

DO THE WORK
- One item at a time; finish it fully before the next.
- Match the patterns already in the repo; don't invent new ones.
- If an item needs my call (spend money, delete, contact a person), STOP it, add
  it to a "needs me" list, move on.

VERIFY (evidence, not confidence)
[Pick per item: "run the tests", "re-open the file and check it meets the goal",
"screenshot and confirm."] If it fails, fix and re-verify — max 3 tries, then log
it blocked and continue.

REMEMBER
Keep LOOP-STATE.md. After each item write: name, status (done/blocked/needs-me),
what changed, what the next run needs. Read it FIRST every run so nothing is redone.

STOP WHEN
Every item is done or logged blocked, or you've done [N] this run. Then report:
done, blocked, needs my decision.

Start by reading LOOP-STATE.md if it exists, then find the work.

Where most people go wrong

The goal you hand it must be something it can score itself on — a number, a percentage, a checklist — not "make it good." Verification is the whole game. As Osmani warns, a loop running unattended is also a loop making mistakes unattended. No self-check means you've just built a machine that's wrong faster.

Do this today

Pick one annoying multi-item task you do by hand — a backlog to clear, a folder to clean. Paste the charter, fill the brackets, add a LOOP-STATE.md for memory, and run it once while you watch. That single move is how you stop being the one who prompts and start being the one who designs the system that does.

Sources

• Addy Osmani — Loop Engineering
• The Neuron — How Claude Code's creators use agent loops