TL;DR — Prompting turn-by-turn is now the bottleneck, not the skill. A loop replaces it with three things: a recursive goal, a verifiable stop condition, and unsupervised iteration. Is it a rebranded cronjob? Mostly yes — except for the one organ cron doesn't have. Before you build one, run the six-item harness checklist at the bottom.
This is a summary of Part 1 of the 9-part Loop Engineering series on ShipWithAI. Read the full article →
Four eras, and each one moved the skill upward
Every shift in AI-assisted coding moved the unit of leverage one layer up the stack:
| Era | Unit of leverage | Your job |
|---|---|---|
| Prompt | Words in one message | Phrase the request well |
| Context | What the agent reads | Curate CLAUDE.md, docs, memory |
| Harness | The agent's runtime | Build guardrails, hooks, verification |
| Loops | The system running the agent | Define the goal + the stop condition |
The important part: loops do not replace harnesses. They wrap them. The harness was the floor — a loop is that floor running on a timer, feeding itself.
Which also means the failure mode is obvious in hindsight. The same loop that multiplies a careful engineer's output multiplies a careless engineer's slop.
What actually counts as a loop
The canonical definition has three parts, and dropping any one of them gets you something else:
- A recursive goal — a stated purpose with observable progress
- A verifiable stop condition — checkable by a machine or by a different model, never by the worker's own say-so
- Unsupervised iteration — it runs without you prompting each cycle
Matt Van Horn's plain version is the one worth memorizing: cron plus a decision-maker in the body.
"It's just a cronjob with a rebrand"
The honest answer is mostly yes — the original essay concedes this up front rather than swatting it away, because the minimal viable loop genuinely does look like one. Geoffrey Huntley's Ralph, from July 2025:
while :; do cat PROMPT.md | claude-code; done
That's the whole thing. So where's the difference?
| Cron | Loop | |
|---|---|---|
| Execution | Fixed script on a schedule | Adaptive iteration |
| Termination | Exits when the script finishes | Exits when a condition is verified |
| Judging "done" | None — implicit in script exit | A decision-maker evaluates it |
The decision-maker is the whole ballgame — the skeptics are right about everything except that one organ. It reads current state, picks the next action, and judges completion. Cron cannot recognize success. A loop is built on recognizing it.
The anti-pattern: "run it day and night until the feature is done"
This sounds ambitious. It is actually the single most reliable way to get fake-done work.
Anthropic's November 2025 guidance on long-running agents flagged exactly this: agents without a verifiable stop declare victory prematurely and hand you features that are confidently broken.
Compare:
- ❌ "Run until done" — subjective, unbounded, unfalsifiable
- ✅ "Iterate until the failing test passes, capped at N runs" — machine-checkable and bounded
The fix is a stop condition someone other than the worker can check — a test, a lint gate, a schema, or a separate model grading the result.
One nuance people get backwards: the caps are not the stop condition. Iterations, cost, and wall-clock time are safety rails. The condition is the goal. If your only stop is max_iterations, you don't have a loop — you have a budget.
Where the engineer's job goes
What disappears: typing "fix the tests again" for the fourth time.
What doesn't disappear — and gets more important:
- Verification stays yours to design. No loop should grade its own homework — that's the failure mode every source in the essay converges on.
- Loop design assumes a working harness underneath it. Skip that and you've automated your weaknesses.
The original piece owns up to this with a first-person example: a maker agent in ShipWithAI's own content pipeline fabricated a plausible CEO quote, passed its own self-check, and was only caught by an independent fact-checker pass before publish. Small blast radius, same organ failure.
Boris Cherny — who created Claude Code, deleted his IDE in November 2025, and shipped 259 PRs in 30 days with 100% written by Claude Code — runs a recurring /loop 5m /babysit command alongside explicit self-verification. His rule: give Claude a way to verify its work, credited with a 2–3x quality difference.
The six-item harness readiness checklist
Run this against your repo before you write a single loop:
- Conventions written down — do they live in CLAUDE.md/skills, or only in your head?
- Non-negotiables are mechanical — do hooks enforce the rules, or do you catch violations in review?
- "Done" is machine-checkable — is there a failing test, lint gate, or schema check?
- State survives dead sessions — does progress persist in files the next run reads?
- Two agents can share the repo — can they work without colliding (worktrees)?
- Known caps — can you name your iteration, cost, and wall-clock limits?
Scoring:
- Items 1–3 fail → build the harness first. A loop will only automate what's already weak.
- Items 1–3 pass, 4–6 fail → you're exactly where the series picks up. Parts 4–6 cover state, parallel agents, and caps.
Worth being strict here: the source's bar for actually running a loop is all three gates plus all six checks — the task repeats, "done" is machine-checkable, and the harness clears the list.
Where this came from
The idea isn't new, it just converged:
- ReAct (2022) — formalized reason-plus-action academically
- AutoGPT (2023) — shipped the loop without verification; the failures were instructive
- Ralph (July 2025) — minimal viable loop, fresh context each iteration
-
/goal(Spring 2026) — productized verifiable stop conditions - Orchestration loops (June 2026) — loops supervising other loops
Simon Willison named the skill in September 2025, months ahead of the wave; Addy Osmani's Loop Engineering essay is the synthesis the original leans on for the term. Peter Steinberger's June 7 post — stop prompting agents, start designing loops — reached roughly 2.2 million viewers and split the room between people who agreed without a definition and people calling it cronjobs with a rebrand.
What to do this week
- Run the six-item checklist against one repo
- Find one task where "done" is already machine-checkable
- Don't build yet — Part 2 covers the anatomy before the assembly
This is a condensed summary. The full article covers the era-by-era breakdown, the complete steelman of the cron objection, and the self-verification discipline in depth:
👉 Loop Engineering: Why You Should Stop Prompting — Part 1 of 9, ShipWithAI
The rest of the series: Part 2 loop anatomy, Part 3 stop conditions (the hardest part to get right), Parts 4–6 state, parallel agents and caps, Part 7 documented real-world failures.
Top comments (0)