🤖 The Agentic Loop 🔄 Loop Engineering : A Practical Field Guide 📘

How to make AI coding agents do real work — repeatedly, verifiably, and without you babysitting every step.

Synthesized from current practice (2025–2026): Addy Osmani's "Loop Engineering," Peter Steinberger's "Just Talk To It" and "Shipping at Inference‑Speed," Boris Cherny's talks on Claude Code, Geoffrey Huntley's Ralph technique, Matt Van Horn's "WTF Is a Loop?", the Forward Future Loop Library, the Lushbinary loop‑engineering guide, and the working loops shared by practitioners like Matthew Berman, Eric Lott, Hiten Shah, and others.

📋 Table of Contents

• ⚡ TL;DR
• 1. 🔄 What an agentic loop actually is
• 2. 🔧 From prompting to loop engineering
• 3. 🐣 Where the loop began: the Ralph technique
• 4. 🚀 Why this matters right now
• 5. 🏗️ The anatomy of a good loop
• 6. 📝 The universal loop template
• 7. 🧱 The five building blocks of a self-running loop
• 8. 📜 Write the stop condition like a contract
• 9. 📚 A starter library of proven loops
• 10. 🪜 The maturity ladder: adopt loops safely
• 11. 🛠️ Running loops in your tool
• 12. 🛡️ Keep loops safe (non-negotiable guardrails)
• 13. 💸 The loop is now the expensive part
• 14. 💬 The "just talk to it" counterweight
• 15. ⚠️ The risks loops don't solve
• 16. 🐛 Common failure modes
• 17. ✅ Quick-start checklist
• 📖 Sources & further reading

⚡ TL;DR

An agentic loop is the simplest unit of useful agent work: do something → check the result → decide whether to continue or stop. The whole craft is in making the check real and defining when to stop. Everything else — model choice, harness, MCPs, subagents — is secondary.

If you remember one sentence: A loop is a task with a check. A task without a check is just hope.

Zoom out and the same idea has a name: loop engineering — designing the system that prompts your agent on a schedule and against a goal, instead of typing every prompt yourself. As Anthropic's Boris Cherny put it, "My job is to write loops." This guide takes you from one good loop to a self‑running one — and tells you where the brakes are.

1. 🔄 What an agentic loop actually is

Most people picture "an agent" as a chatbot that writes code in one shot. That's a one-time task. A loop is different. The agent:

1. Observes the current state (reads files, runs a test, takes a screenshot).
2. Takes one bounded action (changes one thing).
3. Checks what happened against a fixed standard.
4. Decides — continue, stop because it succeeded, or stop because it's blocked or out of budget.

        ┌───────────────────────────────────────────┐
        │                                           │
        ▼                                           │
  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌────┴─────┐
  │ OBSERVE  │──▶│   ACT    │──▶│  CHECK   │──▶│  DECIDE  │
  │ (inputs) │   │ (1 step) │   │ (fixed)  │   │ continue │
  └──────────┘   └──────────┘   └──────────┘   │ /stop?   │
                                               └────┬─────┘
                                                    │ stop
                                                    ▼
                                          ┌───────────────────┐
                                          │ HANDOFF / REPORT  │
                                          └───────────────────┘

Use a loop when the result of one step should change the next step. If it won't, use a one-time task instead. (Forward Future, How agent loops work.)

This is why "improve the code" fails and "make every page load under 50ms under the same test conditions" works. The first has no finish line; the second has a check the agent can run after every change, and a number that says done.

🔁 Inner loop vs. outer loop

The cycle above is the inner loop — what a coding agent already runs on every turn: it perceives the state, reasons about what to do, acts (calls a tool, edits a file, runs a test), observes the result, and reasons again. You don't build that; the harness does.

What you build is the outer loop: the system that runs that inner loop on a schedule, feeds it work, checks the result, and decides the next thing — without you typing each prompt. Everything past this section is about designing that outer loop well.

2. 🔧 From prompting to loop engineering

In June 2026 this pattern got a name. Addy Osmani called it loop engineering, crystallizing what Peter Steinberger and Anthropic's Boris Cherny (head of Claude Code) had been saying:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." — Peter Steinberger

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." — Boris Cherny

It's the third layer in a stack that's been building for years. Each layer wraps the one inside it and moves the leverage point further from the raw model call:

The lower layers don't disappear — a sloppy prompt inside a loop just produces sloppy work faster, and the loop still has to put the right files in front of the model each turn. What loop engineering adds is the autonomous control structure around all of it.

The leverage moved; the work didn't get easier. A well‑designed loop multiplies a good engineer. A badly designed one multiplies a bad decision just as fast, with less of you watching.

3. 🐣 Where the loop began: the Ralph technique

Before it had a name, there was Ralph. In July 2025 Geoffrey Huntley described running a coding agent inside a plain while loop and named it after Ralph Wiggum — "deterministically simple in an unpredictable world." It looks too dumb to work, and it works. (Huntley built an entire programming language with it for about \$297.)

# The original Ralph loop: same prompt, fresh context, until done
while ! grep -q "ALL TASKS DONE" STATUS.md; do
  # each pass is a brand-new agent with an empty context window
  claude -p "Read PLAN.md and STATUS.md. Pick the next unchecked task,
             implement it, run the tests, commit on success, and update
             STATUS.md. Then stop."
done

The non‑obvious insight is the context reset. A long session degrades as the window fills with old reasoning, dead ends, and stale file contents. Ralph sidesteps that: every iteration is a fresh agent with a clean context that reads the current repo state and task list from disk, does exactly one unit of work, commits, and exits. The intelligence doesn't live in one heroic run — it lives in clear, granular specs and verifiable outcomes, applied over and over against an external memory the model can't pollute.

Loop engineering is Ralph, productized. The while loop becomes a scheduled automation, the context reset becomes a worktree plus a sub‑agent, and the ALL TASKS DONE grep becomes a /goal condition graded by a separate model. Same shape, fewer sharp edges.

📊 The five-stage lineage

Ralph didn't appear from nowhere — and what Steinberger and Cherny mean today isn't Ralph either. The word loop hides at least five distinct things. Knowing where you are on this ladder is the fastest way to stop talking past people:

Stages 1–4 are single‑agent. Stage 5 is what's genuinely new: the loop became the unit of work (not the task), loops started supervising other loops concurrently and on a schedule, scheduling replaced the human kickoff (so it runs on infrastructure time, not your attention), and durability became explicit (git‑backed state and crash recovery, because Ralph assumed your terminal stayed open and the 2026 version assumes it does not).

"It's just cron with a hat on" — half right. The sharpest skeptic line in the whole discourse was four words: "Cronjobs have funny re‑branding right now." And yes, the scheduling layer is cron — Claude Code's /loop runs on cron under the hood. What cron never had is the body. A cron job runs a fixed script; a loop runs a model that reads the current state, decides what to do next, does it, checks whether it worked, and decides whether to continue. A loop is cron plus a decision‑maker in the body. Stack those — let one loop dispatch and supervise others with durable shared state — and you get something cron can't express. The open‑source proof is Steve Yegge's Gas Town: 20–30 Claude Code instances coordinated by a "Mayor" agent, patrol agents running continuous loops, and state in git so work survives a crash.

🗺️ What stage-5 orchestration looks like

Read it top to bottom: a scheduler tick wakes the Mayor (the outer loop), which hands each patrol agent one bounded task in its own worktree. Each patrol agent runs its own inner observe → act → check cycle, then a verifier gates the result — failures bounce back to the Mayor for rework, passes are committed to durable git state. The next tick reads that state and picks up where the last one stopped. The Mayor enforces the three hard stops (max iterations, no‑progress, budget) so the whole thing halts instead of running off a cliff.

4. 🚀 Why this matters right now

The capability bar moved. Practitioners report that agentic coding went from "this is crap" to "this is good" around mid‑2025, and from good to "this is amazing" with the newest frontier coding models. The practical consequence, in Steinberger's words: the amount of software you can create is now mostly limited by inference time and hard thinking — not by typing.

That shifts where your effort goes. The bottleneck is no longer writing code; it's specifying the goal and the check precisely enough that an agent can run unattended and you can trust the result. The agentic loop is the format that encodes exactly those two things.

A second reason it matters: closing the loop. The recurring theme across every credible source is that agents get dramatically more reliable when they can verify their own work — run the CLI, run the test, diff the screenshot, hit the endpoint. Whatever you build, build it so the agent can check itself. "By default, whatever I wanna build, it starts as a CLI. Agents can call it directly and verify output — closing the loop." (Steinberger.)

5. 🏗️ The anatomy of a good loop

Every reliable loop names five things explicitly. Miss one and the loop drifts, runs forever, or "succeeds" while tests fail.

📐 The four design rules (from How agent loops work)

1. Start with a measurable goal. Describe the result so you can review or measure it.
2. Keep each action small. One bounded, reversible change at a time — easier to verify, easier to undo.
3. Use a fixed check. Run the same test/benchmark/rubric/approval after every change. The check — not the agent's opinion — determines whether the work improved.
4. Define how it stops. Success, no‑op, ask‑for‑approval, and blocked/out‑of‑budget must all be spelled out.

6. 📝 The universal loop template

This single prompt shape works across Cursor, Codex, Claude Code, Factory, Devin — anything. Fill the brackets:

When [trigger], inspect [fresh inputs]. Choose one in-scope action using
[criteria], then make the change.

Run [acceptance check] under the same conditions. Record what changed, the
evidence, and the next step in [state file].

Repeat only while progress is measurable and [budget] remains. Stop when
[success gate] passes. Stop without changes when [no-op condition] is true.

Ask for approval or report a blocker when [escalation condition] occurs.
Never [forbidden action]. Finish with [pull request, report, artifact, or handoff].

Run it once by hand before you schedule it. The first manual run almost always reveals a missing check, a fuzzy boundary, or a stop condition that needs to be sharper. (Forward Future.)

🍦 Two flavors

• Goal loop — starts manually, runs until the check passes or the budget runs out. (e.g., "stabilize the test suite.")
• Scheduled loop — starts on a timer or event, does its bounded work, reports, and waits for the next trigger. (e.g., Steinberger's five‑minute repository maintainer that wakes every five minutes, triages repos, assigns the highest‑value bounded task, and requires green CI before anything lands.)

7. 🧱 The five building blocks of a self-running loop

A year ago a loop meant a pile of bash you maintained forever. As of mid‑2026 the pieces ship inside the products — and the shape is the same across OpenAI Codex and Anthropic's Claude Code, so you stop arguing about which tool and just design a loop that works in either. A loop needs five blocks plus one place to remember state.

Four of these are mechanics; two are where loops live or die.

Automations are the heartbeat. They surface work on a schedule without you asking — everything else reacts to what they find. Runs that find something land in triage; runs that find nothing archive themselves. The in‑session cousin is the most important primitive of 2026: /goal keeps working across turns until a condition you wrote is verifiably true, and a separate small model checks "are we done?" after every turn.

Memory is the spine. The model forgets everything between runs, so state must live on disk, not in the context window. The agent forgets; the repo doesn't. Tomorrow's run reads the state file and picks up exactly where today stopped. Keep two things separate: skills hold durable knowledge (how we build, our conventions, "we don't do it this way because of that one incident"); memory holds changing state (what's been tried, what passed, what's still open). Never put secrets in either.

The maker–checker split is the single most useful structural move. The model that wrote the code is far too generous grading its own homework. A second agent — different instructions, sometimes a stronger model on higher reasoning effort, told to be adversarial and to trust tests over its own read of the diff — catches what the first talked itself into. This is exactly what /goal does under the hood: a fresh model decides whether the loop is done, not the one that did the work.

The reusable unit is a skill, not a prompt. Steinberger's other rule pairs with the loop one and is arguably the more durable half: if you do something more than once, turn it into a named skill; if you do something hard, turn it into a skill afterward so next time is free. A loop with no reusable skills inside it is just a while‑true around a stranger. A loop that calls a library of sharp, tested, named skills compounds — every run gets cheaper and sharper instead of re‑deriving your project from zero. The loop is plumbing; the skills are the asset.

You are still the ceiling. Worktrees remove the mechanical collision, but your bandwidth to review merged work caps how many parallel agents you can actually run. Ten agents producing changes you can't review is worse than two you can.

8. 📜 Write the stop condition like a contract

A goal is only as good as the evidence that proves it. "Make the checkout flow better" gives the loop nothing to grade against, so it stops whenever it feels like it. Practitioners running long, unattended agents converged on the same fix: specify the desired end state, the evidence required, the constraints that must hold, and a hard budget. The agent stays the executor; you write the acceptance test it must pass before it may claim done.

Three habits make a loop trustworthy: preserve mistakes so the loop learns instead of repeating them, build verification into the loop rather than bolting it on after, and treat the failing test or red CI as the signal that keeps the agent honest. A loop with no evidence to fail against will always think it succeeded.

9. 📚 A starter library of proven loops

These are real, attributed patterns from the Loop Library. Each one is a worked example of the template — notice how every one has a concrete check and an explicit stop.

⚙️ Engineering

• Fresh‑clone loop (0xUmbra) — Clone the repo into a disposable environment, follow only the README to the documented ready state. When a step fails or assumes missing knowledge, record the gap, fix the docs/setup, discard the environment, and start over carrying nothing. Stop when one uninterrupted fresh clone reaches the ready state. Check: a clean clone actually runs.
• Test‑stabilizer loop (hungtv27) — Run the suite N times, list tests whose result changes, fix the most frequent flake at its root cause (shared state, timing, ordering, external dep) — never with a blind sleep or retry. Repeat until N consecutive full‑suite runs pass. Check: N green runs in a row.
• Housekeeper loop (Eric Lott) — Hunt dead code, stale files, unused deps, duplication, broken links. Protect uncommitted/active work. Prove one low‑risk cleanup, make the smallest coherent change, rerun build + tests + diff review, keep only verified improvements. Check: build/tests still green after each removal.
• Propagation‑compliance loop (@iamTristan) — After changing a version/count/rule/name, find everywhere the old value lives and update it, while preserving intentional history/examples/migrations. Repeat until zero stale values remain. Check: search returns no unintended stale matches.

🔬 Evaluation

• Full product evaluation loop (Matthew Berman) — Create N realistic scenarios covering every major capability, define pass/fail or a scoring rubric before testing, run all scenarios under identical conditions, fix root causes, rerun affected scenarios, then rerun the full set until everything clears the bar.
• Multi‑LLM convergence loop (Donn Felker) — Have one model family review the work; verify findings, apply only necessary fixes, then hand the revised version to a different provider's model. Succeed only when both approve the same unchanged version. Stop on oscillation or the pass limit.
• Artifact‑to‑skill loop (Hiten Shah) — Turn a successful artifact into a reusable skill/playbook: extract decisions, sequence, checks, and failure‑avoidance patterns (not surface style), strip secrets, then have an independent reviewer apply it to a fresh real case. Ship only if it works without the original artifact.
• Devil's‑advocate / red‑team loop — Before committing to an architecture or rollout, have a critic argue it's wrong. Log each objection and status; the builder must fix or document acceptance of every high‑impact weakness. Stop when none remain or the same issues repeat without new evidence.

🗂️ Operations & content

• Five‑minute repository maintainer (Peter Steinberger) — Scheduled loop: wake every 5 min, triage repos, reuse one thread per repo, assign the highest‑value bounded task within granted permissions, require tests + live proof + autoreview + green CI before landing, escalate anything irreversible.
• Recent‑feedback sweep (Matthew Berman) — Gather every thread where you reported a bug, dedupe into failure patterns, audit the whole project for each pattern, fix confirmed instances, add regression coverage, repeat until the audit finds nothing.
• Promise‑to‑proof loop (Felix Haeberle) — List every customer‑facing promise (marketing, docs, demos, AI answers), label each proven/misleading/unsupported against actual behavior, fix the riskiest mismatch, repeat until no high‑risk unsupported promise remains. Ask before editing public copy.

🎨 Design / frontend

• UI/UX score loop (Hayden Cassar) — In a real browser from a fresh session, capture screens at agreed sizes, score with one checklist, improve the weakest safe area, rerun the whole flow, keep only regression‑free changes. Stop on success or two passes with no gain.
• Cold‑load trimmer loop (Christian Katzmann) — Record passing tests + screenshots + transferred bytes, then defer/compress/remove one item per pass. Keep it only if tests pass, screenshots are pixel‑identical, and bytes decrease — otherwise revert.
• Accessibility repair loop (Eric Lott) — Scan against WCAG (e.g., 2.2 AA), confirm each issue, fix the highest‑impact blocker, rerun the same checks + regression tests, never silence a check or weaken the target.

The pattern is identical every time: fresh inputs → one change → fixed check → keep only verified wins → explicit stop.

10. 🪜 The maturity ladder: adopt loops safely

Don't jump straight to an auto‑merging loop. Earn trust one rung at a time, and only climb when the current rung is already producing work you'd have done by hand anyway. Each level adds exactly one new power and keeps a human in the path until the evidence says you can step back.

Start smaller than you think. A single automation that triages CI failures into a markdown file each morning — no auto‑merge — already removes a recurring chore and lets you watch how the loop behaves before you trust it with PRs.

Watch the token bill. A scheduled loop with a verifier running after every turn burns tokens fast, and usage swings wildly with cadence and sub‑agent count. Start with a slow cadence and a tight goal, watch cost for a few days, and scale up only once the loop produces work you actually merge.

11. 🛠️ Running loops in your tool

The same prompt works everywhere; only where you store recurring instructions and how you schedule differ.

In all cases: review the diff and the actual check output — not the agent's summary — to decide whether the work is done.

🏁 A concrete starter (Claude Code)

The lowest on‑ramp is one line. Boris Cherny's own canonical example — paste it and change the nouns:

/loop babysit all my PRs. Auto-fix build issues, and when comments come in,
use a worktree agent to fix them.

Notice what you didn't write: the steps. You wrote the intent and the stopping behavior; the loop prompts the agent each tick. Cherny's five tips for running an agent autonomously for hours or days:

1. Use auto‑approve permissions so it doesn't stop to ask.
2. Let it orchestrate many sub‑agents for big tasks.
3. Use /goal or /loop to nudge it to keep going until done.
4. Run it in the cloud so you can close your laptop.
5. Give it a way to self‑verify its work end to end — the tip the hype skips and practitioners obsess over. A loop is only as trustworthy as its ability to check itself.

12. 🛡️ Keep loops safe (non-negotiable guardrails)

A loop is delegated authority. Bound it.

• Set hard limits. Max time, cost, retry count, iteration count, and affected scope. A loop must never read "keep going" as unlimited authority.
• Keep the check stable. Don't move the benchmark after every result, or progress becomes impossible to compare. When optimizing a prompt or model, evaluate against a fresh holdout set so you're not overfitting to the cases you've been tuning on.
• Gate consequential actions behind a human. Production deploys, destructive ops, financial moves, privacy‑sensitive data, and external messages require approval. Blocked, exhausted, and stagnant runs are not successful runs — never let an agent dress them up as done.
• Leave a useful handoff. Record goal, steps completed, evidence, blockers, and next action in a state file (e.g., tmp/<file>.md). Never store secrets there.
• Demand evidence, not claims. "Tests pass" means show the green run. "Production verified" means show the proof. Several of the strongest loops exist precisely because agents will otherwise mark partial work as complete.

13. 💸 The loop is now the expensive part

Here's the plot twist of 2026. Once the model writes the code for almost nothing, the cost moves to the loop running it. The expensive resource shifted from tokens‑per‑feature to loop management.

"The costliest thing in AI coding is no longer writing code, it's managing the agent loop."

The receipts are real: Uber capped its engineers at \$1,500 per person, per tool, per month for Claude Code and Cursor after burning its annual AI budget in four months. And the failure mode every production team fears is the loop that doesn't stop — "without guardrails, you get infinite loops and billing surprises orders of magnitude over budget."

Which is why every serious 2026 write‑up converges on the same three hard stops. Bake all three into every loop:

1. Max iteration count — a ceiling on turns, full stop.
2. No‑progress detection — if N passes produce no measurable change against the check, halt instead of grinding.
3. A token or dollar budget — a hard spend ceiling that ends the run.

The romantic version of loops is that you write them and a thousand agents build your company overnight. The production version is that you write the loops, and most of your job is making sure they halt. (For perspective: Gartner places agentic AI at the peak of inflated expectations, with only ~17% of organizations actually deploying agents. Mind the gap between the timeline and the receipts.)

14. 💬 The "just talk to it" counterweight

Here's a nuance worth naming: the same Peter Steinberger quoted in §2 as a loop‑engineering advocate also wrote "Just Talk To It," a manifesto for dropping the ceremony. That's not a contradiction \u2014 it's the boundary. Structure pays off for unattended, repeated work; it's overhead for interactive, exploratory work where you're watching the stream. Both are right, for different situations.

His core claims for the hands‑on mode, distilled:

• The model + the conversation is the unit of work. Start a discussion, paste links and screenshots, let it read the code, flesh out the feature together, then say "build." No elaborate plan‑mode charade for capable models.
• Short prompts + images beat long specs with strong models. A screenshot dragged into the terminal with "fix padding" often does more than a paragraph.
• Prefer CLIs over MCPs. Most MCPs are context tax (a single GitHub MCP can eat ~23k tokens); a named CLI the model already knows costs zero context and is self‑documenting via --help.
• Parallelism over orchestration. Run several agents side by side rather than building elaborate multi‑agent systems. You are usually the bottleneck, not the tooling.
• Watch the stream, manage blast radius. Keep changes small and atomic so you can hit escape, ask "what's the status," steer, or abort. Don't fear stopping a model mid‑task — file changes are atomic and agents resume well.
• Develop intuition. "The more you work with agents, the better your results will be." Many skills for managing agents are the same as managing senior engineers.

🤝 How to reconcile the two views

• Reach for the lightweight, conversational mode for exploratory, UI, and one‑off work where you are in the loop watching the stream. Here the "check" is your eyes and your taste.
• Reach for a structured loop when work is repeated, unattended, scheduled, or consequential — test stabilization, maintenance sweeps, evals, accessibility, anything that must run while you're not watching. Here the check must be mechanical, because no human is verifying each pass.

The shared truth underneath both: build for verification, keep changes small, and never trust a summary over a check.

15. ⚠️ The risks loops don't solve

A loop changes the work; it doesn't delete you from it. Three problems get sharper as the loop gets better, not easier.

1. Verification is still on you. A loop running unattended is also a loop making mistakes unattended. Splitting the verifier from the maker makes "it's done" mean something — but "done" is still a claim, not a proof. Ship code you confirmed works; human review of merged changes stays in the loop no matter how good the verifier gets.
2. Comprehension debt grows faster. The faster the loop ships code you didn't write, the wider the gap between what's in the repo and what you actually understand. A smooth loop just widens that gap — unless you read what it produced.
3. Cognitive surrender is the comfortable failure. When the loop runs itself, it's tempting to stop having an opinion and accept whatever it returns. Designing the loop is the cure when you do it with judgment, and the accelerant when you do it to avoid thinking. Two people can build the identical loop and get opposite outcomes: one moves faster on work they understand deeply, the other avoids understanding it at all. The loop doesn't know the difference. You do.

Build the loop. But build it like someone who intends to stay the engineer — not just the person who presses go.

16. 🐛 Common failure modes

17. ✅ Quick-start checklist

Building your first real loop? Walk this list:

• [ ] Goal is measurable (a number, a passing test, a rubric score — not "make it better").
• [ ] Trigger is named (manual goal, or a timer/event for scheduled).
• [ ] Inputs are re‑inspected fresh each pass.
• [ ] Action is one bounded, reversible change.
• [ ] Check is fixed, mechanical, and run every pass under identical conditions.
• [ ] Stops are all defined: success ✅, no‑op 🟰, ask‑for‑approval 🙋, blocked/out‑of‑budget 🛑.
• [ ] Budget caps time, cost, and iterations.
• [ ] Handoff records goal, evidence, blockers, next step — no secrets.
• [ ] Consequential actions are gated behind a human.
• [ ] If it runs unattended, a separate verifier (different instructions/model) grades the result — the maker doesn't grade itself.
• [ ] You're on the right maturity rung (start at triage, not auto‑merge) and watching the token cost.
• [ ] You ran it once by hand and tightened whatever the first run exposed.

Get these right and you have a loop you can trust to run while you sleep. Everything else is iteration.

📖 Sources & further reading

On loop engineering (the discipline):

• Addy Osmani — Loop Engineering (Jun 7, 2026): https://addyosmani.com/blog/loop-engineering/ — the post that named the pattern; source of the five building blocks and the Steinberger / Boris Cherny quotes.
• Lushbinary — Loop Engineering: Designing Systems That Prompt AI Agents: https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/ — the prompt→context→loop stack, stop‑condition‑as‑contract, and the maturity ladder.
• Geoffrey Huntley — Ralph Wiggum as a "software engineer" (the Ralph technique): https://ghuntley.com/ralph/
• Matt Van Horn — WTF Is a Loop? Peter Steinberger vs. Boris Cherny (Jun 8, 2026): https://x.com/mvanhorn/article/2063865685558903149 — the five‑stage lineage, the "cron plus a decision‑maker" framing, and the economics (Uber's cap, the three hard stops).
• Boris Cherny — remarks at the WorkOS Acquired Unplugged event (Jun 2, 2026) and his five tips for running agents autonomously.

Loops in practice (the patterns):

• Forward Future — Loop Library and How agent loops work: https://signals.forwardfuture.ai/loop-library/ · https://signals.forwardfuture.ai/loop-library/learn/
• Peter Steinberger — Just Talk To It: https://steipete.me/posts/just-talk-to-it
• Peter Steinberger — Shipping at Inference‑Speed: https://steipete.me/posts/2025/shipping-at-inference-speed
• Peter Steinberger — My Current AI Dev Workflow: https://steipete.me/posts/2025/optimal-ai-development-workflow
• Loop authors cited above: Matthew Berman, 0xUmbra, Eric Lott, Hiten Shah, Christian Katzmann, Hayden Cassar, Donn Felker, Felix Haeberle, hungtv27, @iamTristan, and other Loop Library contributors.

Tool commands and product capabilities (Codex /goal, Claude Code /loop, worktree flags, Automations) change frequently — verify against each vendor's current official docs before relying on a specific behavior. Loops in the library are shared under their authors' attribution.

🗺️ Companion Reads

These posts pair directly with topics covered above. Read them in the order that matches where you are right now.

Suggested reading path:

1. This guide (orientation + mental model)
2. → 🤖 SWE-agent — Deep Dive & Build-Your-Own Guide 📘 (understand the inner loop mechanics)
3. → 🏗️ Building High-Quality AI Agents 🤖 — A Comprehensive, Actionable Field Guide 📚 (harness + tool design)
4. → 🚀 Claude Code: From Zero to Pro 🤖 (tool-specific execution)
5. → 🏗️ Building Production-Grade Fullstack Products with AI Coding Agents 🤖 — A Practical Playbook 📘 (ship it end-to-end)

If you found this helpful, let me know by leaving a 👍 or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! 😃