Start here / how to use this

Stop prompting. Start designing loops.

Two of the most senior AI engineers alive said the same thing this year. Boris Cherny, who runs Claude Code at Anthropic: "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops." Peter Steinberger, creator of OpenClaw: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Both quotes are as reported in the source threads, not verified against a primary recording. See the sourcing note in the last section for how much to trust each claim in here.

Most people read that and had no idea what it actually meant. This tutorial fixes that. By the end you will understand loops better than almost anyone on your timeline: what they are, when they are worth it, when they are a trap, and how to build one, starting with a version you can run with a single paragraph of text.

No jargon for its own sake. The whole idea is genuinely simple once someone lays it out in order. That is what these short lessons do.

How to move through it

• Use the list on the left, or the Next button at the bottom of each lesson.
• On a keyboard, press ← and → to move between lessons.
• Hit Mark as read at the end of each one. Your progress is saved on this device, so you can close the tab and come back where you left off.
• Anything in a dark terminal box has a Copy button. The pieces you can actually try are called out clearly.
• The teal go deeper blocks are optional. Skip them for the fast path, open them when you want the why underneath.

Lesson 01 / the problem

Right now, you are the loop

Look closely at how you use AI today. Write a prompt. Wait. Read the output. Fix it by hand. Write another prompt.

Every step runs through you. You decide what to ask, you judge the answer, you decide what comes next. The AI never moves unless you push it. The moment you stop, everything stops.

That is fine, and for a lot of work it is exactly right. But it has a hard ceiling: you are the engine. The AI is only the tool in your hand, and a tool does nothing on its own.

The leverage point moved

The builders moving fastest in 2026 are not writing better prompts. They are building small systems that do the prompting for them. The shift is one sentence: from typing prompts, to designing the loop that prompts.

Anthropic's own engineers now merge roughly eight times as much code per day as they did in 2024. Anthropic itself calls that "almost certainly an overstatement" of the real gain, so treat the number lightly. The mechanism underneath it is not in doubt: the leverage stopped being at the prompt and moved one floor up, to the system that decides what the agent works on, checks it, and keeps it going.

That is what the rest of this is about. Not a new app to buy. A way of working.

Lesson 02 / the core idea

What a loop actually is

A prompt is a single instruction. A loop is a goal the AI keeps working toward until it gets there.

A prompt gives you one answer and then waits for you to decide what is next. A loop runs the full cycle on its own, over and over, until the job is actually done. Not until it produces an answer. Until it reaches a verified outcome.

• Discover work out what needs doing.
• Plan decide how to do it.
• Execute do the work.
• Verify check it against the goal.
• Iterate not good enough? fix the weakest part and repeat.
• Stop the goal is met, or a hard limit is hit.

Claude Code, Cursor, Codex: underneath, they all run this same cycle. The difference between a prompt and a loop is not the model. It is whether something checks the work and keeps going until it passes.

Lesson 03 / the parts that matter

Three parts do all the real work

The cycle has five steps, but three things are where people get loops right or wrong: the gate, the memory, and the stop condition.

1. Verify: the gate

This is the heart of the loop. Without a real check on the result, you do not have a loop, you have the agent agreeing with itself on repeat. The check is what turns repetition into progress.

A gate can be a hard test ("do the tests pass"), a measurable condition ("is the number above X"), or a rubric the model scores against. What it cannot be is the same agent's own opinion. The model that did the work is far too generous a grader of its own work.

2. State: the memory

Agents forget. What they learn this run is gone next run unless you write it down. So a real loop keeps a small record on the side: what is done, what failed, what is next. A plain markdown file called STATE.md is enough.

3. The stop condition: the brakes

A loop with no exit runs until it succeeds, breaks, or drains your account. Every serious loop has two ways to stop: success, and a hard limit ("after 8 tries, stop and report"). Skip this and you have built a machine that can run all night for nothing.

Put simply: a prompt hands the AI an instruction. A loop hands the AI a job, a way to know when the job is done, and a rule for when to give up.

Lesson 04 / the decision

Do you even need one?

Most articles sell you the loop before they tell you when it is a mistake. Here is the honest test the serious people actually use.

A loop earns its setup cost only when all four of these are true. Miss even one and the loop costs more than it returns. Try it: tick the ones that are true for a task you have in mind.

Good first loops

• Nightly CI failure triage: scan failures, classify causes, draft fix requests for the easy ones.
• Weekly dependency bumps: scan for updates, test compatibility, open the safe ones.
• Lint and fix passes on every change.
• Flaky test hunting: loop until a theory survives the test.

Bad first loops (keep a human in the chair)

Architecture rewrites. Anything touching auth or payments. Production deploys. Vague product work. Anything where "done" is a matter of judgment.

Lesson 05 / the anatomy

The five building blocks

Under the hood, a real loop is assembled from five parts. Claude Code and Codex now ship all five. You do not need all of them on day one, but this is the full anatomy.

Sub-agents and connectors are the "grown-up" blocks. If you only ever use two, use the automation (block 1) and the verifier (block 5). Those two are what make a loop real.

Lesson 06 / build small

The smallest loop that works

If you passed the four-condition test, build the smallest loop that works before anything fancy. Four parts, no swarm.

The order that actually works

The order matters more than the tools. Everyone who ships loops that survive in production does it the same way. Skipping ahead, scheduling something you have not made reliable by hand, is exactly how loops blow up while you sleep.

1. Get ONE manual run reliable first.
2. Turn that into a skill        # save the instructions
3. Wrap the skill in a loop       # add the gate + stop condition
4. THEN put it on a schedule.

# Prove it once. Harden it. Then automate it.

Lesson 07 / your actual toolbox

Claude Code on autopilot

You already pay for this. Claude Code shipped a full automation stack over the last few months: three layers that go from your terminal to Anthropic's cloud. The arc is simple: get the manual loop right, make it survive a restart, push it to the cloud where your laptop does not matter.

Layer 1: /loop, in a session

The fastest way to make Claude repeat something on a cadence. Inside any session, give it an interval and a prompt.

/loop 30m check the test suite and summarize any new failures

# the interval can lead as a bare token (30m, 2h, 1d)
# or trail as a simple clause:
/loop pull the latest and flag anything broken, every 2 hours

/loop handles simple repeating intervals: minutes, hours, days. It does not do calendar schedules like "every weekday at 7am", that is what Routines are for (Layer 3). Under the hood it uses Claude's built-in cron tools.

Four things to know, or you will lose time later: recurring tasks auto-expire after 7 days. Max 50 per session. If Claude is busy when one is due, it fires once when free, not once per missed slot. And it is session-scoped: start a new conversation and they stop. That last limit is the whole reason Layers 2 and 3 exist.

Pair it with /goal

Where /loop repeats on a clock, /goal keeps the current session working until a condition you state is actually true, and refuses to stop at "done enough." After each turn, a small fast model (Haiku by default) checks the condition, so the agent doing the work is not the one grading it. That is the maker vs checker split applied to the stop button itself.

/goal every test in tests/auth passes and lint is clean.
  Scan src/auth for failures, fix the highest-impact one each turn,
  keep going until the checker confirms the condition holds.

Layer 2: Desktop scheduled tasks

The Claude Desktop app has its own scheduler. Same idea, but tasks survive a restart: reboot the machine, close every terminal, they still fire. The catch: your machine has to be awake. If the laptop is asleep when a task is due, that run is skipped.

Layer 3: Cloud Routines

A Routine is a saved Claude Code setup (a prompt, repositories, connectors, permissions) that runs on Anthropic's cloud on a trigger. Your laptop can be off. The run still happens. This is also where calendar schedules live. Create one with /schedule or at claude.ai/code/routines.

/schedule every weekday at 7am, pull yesterday's commits and
  post a 5-bullet morning brief to Slack

Triggers can be a schedule, an incoming web request, or a GitHub event (say, every new pull request). Available on all paid plans (Pro, Max, Team, Enterprise) with Claude Code on the web enabled. The minimum interval is one hour, not one minute like /loop. And by default a Routine can only push to branches named claude/, so a careless one cannot overwrite your main branch.

One more thing: permissions

By default Claude asks before every command. That is right when you are watching, and a problem when no one is. Two safe moves: pre-approve a short allow-list of harmless commands and deny the dangerous ones, and use Auto Mode (available on all paid plans), where a classifier auto-approves the routine work and still asks about the risky calls. Anthropic's own telemetry is the reason it exists: users approve 93% of permission prompts, so Auto Mode automates that 93% and keeps you in the loop for the 7% that actually matter. The test for what to auto-approve is one question: if this turns out wrong, what does it cost to undo? Cheap to undo, approve. Expensive to undo, never.

Lesson 08 / worked example

A loop, start to finish

Enough theory. Here is one complete loop, built the right way, on a real job many teams have: keeping a documentation site's internal links healthy.

Every time a new page is added, its [[links]] can point at pages that do not exist yet. Left alone, the docs quietly rot. Before writing a single line, run it through the four-condition test from Lesson 4:

• Repeats? Yes. New pages land most weeks, so new broken links appear most weeks.
• Automated gate? Yes. A short search lists every [[link]] whose target file does not exist. Objective, no human needed.
• Budget? Yes. A scan plus a few small files. Cheap.
• "Done" is objective? Yes. Zero unresolved broken links. Not "the docs feel tidy."

Four for four. Build it. Now follow the order from Lesson 6, one step at a time. Do not skip to the end.

Step 1: get one manual run reliable

Do the job by hand once and watch it. The gate is the thing that can fail the work, so define it first. In plain terms it returns a list, or nothing:

# Find every [[link]] pointing to a page that does not exist.
# Claude writes the real script; conceptually it prints:
broken: [[install-guide]]     in  docs/setup.md
broken: [[api-reference]]     in  docs/index.md
# ...or nothing at all, which is what "done" looks like.

Ask Claude, in a normal session, to run that check and fix the easy ones: repoint an obvious typo, or draft a short stub for a real concept that has no page. Then run the check again. Empty list means the run worked. You have proven the job by hand. This is the step almost everyone skips, and skipping it is why loops fail in production.

Step 2: save it as a skill

Write the rules down once, so the loop does not re-derive them from scratch every run:

---
name: link-health
description: Find [[wikilinks]] pointing to missing pages.
  Fix typos, stub real concepts, escalate the unclear ones.
---

# Link health

## The gate
A link is broken if its target file does not exist.
The run is DONE when the broken-link scan returns nothing.

## Fix rules
- Obvious typo (target exists under a near slug)  # repoint the link
- Real concept, no page yet                       # draft a short stub
- Ambiguous (two possible targets, or not real)   # list it, do not guess

## Never do
- Never delete a link to "fix" a broken one.
- Never write full page bodies. Stubs only, a human fills them in.
- Never touch generated or vendored files.

## State
After each run, update STATE.md: links repointed, stubs made, items escalated.

Step 3: add state, wrap it in a loop

The state file is the memory that survives between runs. The loop file ties goal, gate, and stop condition together:

Read STATE.md to see what last week already handled.

GOAL: the broken-link scan returns zero results.

EACH PASS:
1. Run the scan. Read the list of broken links.
2. For each one, apply the link-health skill rules.
3. Run the scan again to confirm the count went down.

STOP WHEN: the scan is empty, OR 5 passes reached.
ON STOP: update STATE.md and open ONE claude/ branch with the stubs.

Do not write page bodies. Stubs only. Escalate anything ambiguous.

Step 4: schedule it, with a human gate

Only now do you automate. A weekly calendar cadence like "every Friday at 6pm" is a Routine (Layer 3 from Lesson 7), created with /schedule, so it runs even with your laptop shut. Routines already default to pushing only to claude/ branches, which is exactly the human gate you want:

/schedule every Friday at 6pm, run the link-health-loop.md file

The Routine drafts stubs onto a claude/ branch and stops. You skim the branch on Friday evening and accept the good ones. Creating a file on a side branch is cheap to undo. Letting a loop write unreviewed pages into your knowledge base is not. That is the human gate, sitting exactly where the cost of a mistake stops being cheap.

Lesson 09 / the traps

How loops fail, and cost you money

Loops rarely crash. They fail quietly and keep billing you. Know these before you schedule anything.

The Ralph Wiggum loop

Named by engineer Geoffrey Huntley. The agent decides it is done too early, exits on a half-finished job, and the loop keeps running and spending while producing nothing. The fix is the gate: something objective that can fail the work, plus a hard iteration limit checked by a fresh model.

Goal drift

On long sessions, early constraints quietly disappear. "Never touch the billing code" from message 3 is gone by message 47, because each summarization step loses a little. The fix: a standing VISION.md the agent rereads at the start of every run. State tells it where it is. The spec tells it where to go.

Self-preferential bias

The agent that wrote the code is too nice grading its own homework, and always gives itself a pass. The fix: a separate verifier with no view of the maker's reasoning. It sees only the requirements and the result.

Agentic laziness

The loop calls a task "done enough" at partial completion, especially on vague success criteria. The fix: an objective stop condition only. "Tests return exit code 0," not "tests look good."

Lesson 10 / try it (needs signal)

The no-code version

You do not need a coding agent to feel how a loop works. You can run one by hand inside any chatbot right now, with nothing but a prompt.

The trick is to hand the model all three loop parts at once: a goal, strict success criteria, and a protocol that forces it to check itself before it is allowed to stop. Paste this into Claude or ChatGPT and watch it draft, grade its own work against your bar, find the weak spot, and rewrite, over and over, until it clears the bar instead of handing you the first thing that looked close.

You will work in a loop until the task meets the bar.

TASK:
[describe exactly what you want produced]

SUCCESS CRITERIA (be strict, no soft passes):
- [criterion 1]
- [criterion 2]
- [criterion 3]

LOOP PROTOCOL, repeat every turn:
1. PLAN   - state the single next step.
2. DO     - produce or improve the work.
3. VERIFY - score the result 1-10 on each criterion.
            Be brutally honest. List what is still weak.
4. DECIDE - if every criterion is 8+, print "FINAL" and stop.
            Otherwise print "ITERATING" and go again,
            fixing the weakest point first.

RULES:
- Never call it done until every criterion is 8 or higher.
- Each pass must fix the weakest score from the last VERIFY.
- Do not ask me questions. Make a sensible assumption,
  note it, and keep going.

Begin. Run the loop until FINAL.

That is a real loop. You just built one with a paragraph. It has a goal, a gate (the self-scoring against strict criteria), and a stop condition (all 8+, or you calling it).

Lesson 11 / build yours (needs signal)

Build your first real loop

Fill in the four boxes for a task you actually have. It assembles a loop specification you can hand straight to Claude Code, or read back to sanity-check your thinking.

The pre-flight checklist

Before you schedule anything, every box should be true:

Lesson 12 / power tools

Beyond the loop

You now understand the single loop: one agent, a gate, state, a stop. These three tools are how the people running fleets go further. You do not need them for most work. Knowing they exist changes what you attempt.

Hooks: gates the system enforces

Everything so far asks the model nicely. "Never touch billing." "Stop when the tests pass." The problem is a model can talk itself past a nicely-worded rule, especially on a long unattended run. That is goal drift from Lesson 9, and it is exactly when you are not there to catch it.

A hook is different. It is a command the Claude Code harness runs at a fixed moment, and it can hard-block an action no matter what the model decided. The model does not get a vote. You configure it once in settings, and it fires every time.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",                 # only checks Bash commands
      "hooks": [{ "type": "command",
                  "command": ".claude/block-push.sh" }]
    }]
  }
}

The hook script reads the command about to run and decides. Exit code 2 blocks it, deterministically. Exit 0 lets it through. (You can also print a JSON decision for finer control.)

#!/bin/bash
# the tool input arrives as JSON on stdin
input=$(cat)
if echo "$input" | grep -q "git push"; then
  echo "Blocked: no pushing from an unattended run." >&2
  exit 2          # exit 2 = hard block, the push never runs
fi
exit 0

This is the difference between a guardrail you hope holds and one that cannot be crossed. For a loop running while you sleep, that is the whole ballgame. Hooks are the real fix for the security tax and goal drift from Lesson 9: they turn "the gate" from a polite request into a wall.

Subagents and worktrees: many agents without chaos

A single loop is one agent going around. When a job splits into independent parts, or you want a genuine maker-and-checker, you spawn subagents: separate workers, each with its own context window, each defined as a small markdown file. The classic split is Lesson 5's pattern made concrete: one explores, one implements, one verifies, and the verifier never sees the maker's reasoning.

---
name: verifier
description: Check a fix against the original requirements.
model: sonnet
tools: Read, Bash
isolation: worktree      # its own git checkout, cannot collide
---

You receive only the requirements and the result, never the
maker's reasoning. Run the tests. If they pass, approve.
If not, reject with the failing output. No opinions otherwise.

The moment two agents edit files at once, they collide. That is what isolation: worktree solves: each subagent gets its own git checkout, so their edits cannot touch each other, and it is cleaned up automatically when the work is done.

There is also an experimental "agent teams" mode where independent sessions talk to each other peer to peer. It is off by default and still rough. For almost everything, subagents are what you want.

Dynamic Workflows: the rung above a loop

A loop is one agent iterating on a schedule. A workflow is a script that orchestrates many agents at once, and the key difference is that the script holds the loop, not the model. It fans out to tens or hundreds of subagents, pipelines their work through stages, and runs adversarial verify or judge panels, keeping every intermediate result in script variables instead of clogging one context window.

This is the "heavy version" the source articles were selling with their forty-agents and rewrite-a-codebase-in-six-days stories. It is real and generally available. You reach for one by saying "use a workflow" in plain language, by running the built-in /deep-research for a cited report, or by putting the keyword ultracode in a prompt to have Claude plan and run one.

Lesson 13 / other stacks

The same loop on Codex

Everything so far used Claude Code, but the loop is not a Claude idea. It is a shape. OpenAI's Codex CLI, powered by gpt-5.3-codex, runs the exact same cycle, and the model is tuned for it: plan, implement, validate, repair. What changes is not the concept. It is the levers you pull to activate it.

The concept is fully portable

The no-code loop from Lesson 10 runs word for word inside a Codex or ChatGPT session. Goal, strict success criteria, a self-check protocol, a stop condition: paste it in and it iterates the same way. If you understood the loop on Claude, you already understand it on Codex. Only the tooling below is different.

The same three layers, different levers

Codex has no /loop and no /goal. It reaches the same three layers from Lesson 7 by different means. This is the whole translation:

The one primitive to learn: codex exec

If you take one thing from this lesson, take codex exec. It is the headless run, and it is where your gate lives: it returns a real exit code, so a script or a scheduler can tell success from failure with nobody reading the output. That exit code is the objective gate from Lesson 3, for free.

# headless run. streams to stderr, final message to stdout,
# and exits 0 on success or non-zero on failure = your gate.
codex exec "run the link-health check, fix the easy ones" \
  && echo "clean" \
  || echo "still broken, escalate"

# state between runs: resume the last transcript + plan
codex exec resume --last "continue where you stopped"

Save your rules once in AGENTS.md (the Codex version of a skill), point cron or a GitHub Actions schedule: at that one line, and you have a full loop: automation, skill, state, and gate. The exact four parts from Lesson 6, on a different stack.

The model is not the tool

Worth being precise, because it changes what "using loops with Codex" even means. gpt-5.3-codex is the model. Codex CLI is one tool that drives it. If you call gpt-5.3-codex through an API instead, say in your own cloud tenant, there is no CLI and no Automations panel: the loop lives in code you write, the same script-holds-the-loop pattern as the workflows in Lesson 12, just against OpenAI's endpoint. Same shape, one floor lower.

Reference / glossary & sources

Glossary and sources

The words that come up, in one place, plus where all of this came from.

Glossary

Where this came from

Synthesized from AI engineering writing published in mid-2026. Two products in that reading (Slate and Mira) were promoted tools; this tutorial teaches the durable pattern and leaves the sales pitch out.

• How To Build Your First AI Loop in 2026 @sairahul1, Jul 2026
• Loop engineering: the 14-step roadmap from prompter to loop designer @0xCodez, Jun 2026
• How to run Claude on autopilot in 14 steps: /loop, Routines, the full stack @0xCodez, Jun 2026
• Loops explained: Claude, GPT, Mira and what actually works @AnatoliKopadze, Jun 2026
• Stop Being the Loop. Make Claude Work While You Sleep Jun 2026
• Addy Osmani, long-form on loop engineering; Anthropic engineering docs on evaluator-optimizer patterns; Geoffrey Huntley on the Ralph Wiggum loop.

How reliable is this?

Not every claim in here is equally solid. Here is the honest breakdown, because you should know which parts to lean on and which to double-check.