# lushbinary-loop-engineering-ai-coding-agents-guide-2026-06-09

## Veille

In-depth technical guide (Lushbinary agency blog) on **Loop Engineering**: designing the systems that drive coding agents in a loop, rather than prompting them manually. Covers the lineage prompt → context → loop engineering, the Ralph technique (Geoffrey Huntley), the **five building blocks + memory** of a loop, their implementation in Claude Code and OpenAI Codex, writing verifiable stop conditions, an adoption maturity scale, and the risks that worsen as loops grow more sophisticated. Domain: agentic software engineering, coding agents, harness/orchestration.

## Titre Article

Loop Engineering: The Guide for AI Agents

## Date

2026-06-09

## URL

https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/

## Keywords

Loop engineering, coding agents, harness engineering, Ralph technique, stop conditions, /goal, /loop, git worktrees, skills, sub-agents, maker-checker, MCP, enterprise memory, Claude Code, OpenAI Codex, maturity scale, understanding debt, adversarial verification, FinOps tokens

## Authors

Lushbinary Team

## Ton

**Profile**: third-person B2B pedagogical guide, instructive and structured register (headings, comparison tables, shell/markdown/TOML code examples), high technical level aimed at engineers and tech leads. Dual-purpose article: substantive pedagogy + closing commercial hook ("Why Lushbinary" section + free consultation).

**Style**: explanatory and didactic, with slogan-like formulas condensing each idea ("Agents forget. Repositories remember.", "The leverage shifted, complexity didn't decrease.", "Write stop conditions like contracts, not wishes.", "You remain the ceiling.", "Build loops staying engineers."). Metaphors: the loop as the system's "heartbeat"; stop conditions as "contracts" / "acceptance tests"; Ralph Wiggum (Simpsons character) for deterministic simplicity. Authority claimed through operational experience (production AI integrations, healthcare/fintech/SaaS/e-commerce "since the GPT-4 era") and grounding in named sources (Addy Osmani, Peter Steinberger, Boris Cherny, Geoffrey Huntley). Closing transparency note: content rephrased for license compliance, capabilities sourced from official Anthropic/OpenAI documentation.

## Pense-betes

- **One-sentence definition**: loop engineering builds systems that prompt agents **on a schedule and toward a goal**, instead of typing individual prompts. The leverage shifts from the *quality of a prompt* to the *design of the system*.
- **Two loop levels**: the *inner loop* (perceive-reason-act-observe on every turn, already native to agents) vs. the *outer loop* one designs (planning, helpers, self-feeding work, persistence across many turns).
- **Three-layer lineage** (each encompasses the previous one): Prompt Engineering (1 instruction) → Context Engineering (window content) → Loop Engineering (system deciding what to prompt, when, and whether the result is acceptable). The prompt and the context remain essential — a bad prompt just produces bad work faster.
- **Origin of the term**: popularized by **Addy Osmani** (Google) in June 2026, building on observations by **Peter Steinberger** (*"you should be designing loops that prompt your agents"*) and **Boris Cherny** (Claude Code lead at Anthropic: his focus shifted to *writing loops* rather than prompting directly).
- **Ralph technique** (Geoffrey Huntley, early 2026, named after Ralph Wiggum): running the agent in a simple `while` loop, the same prompt on every iteration, against a written spec, with **fresh context on every turn**. The non-obvious innovation is the **context reset** (avoids degradation from long sessions). The intelligence comes from clear specs + verifiable results + **external memory** (`PLAN.md`, `STATUS.md`), not heroic runs.
- **Loop engineering productizes Ralph**: the `while` becomes a scheduled automation, the resets become worktrees/sub-agents, the "ALL TASKS DONE" check becomes a `/goal` condition verified by a separate model.
- **5 building blocks + memory**: (1) **Automations** (scheduled discovery/triage triggers); (2) **Worktrees** (parallel agents without collisions); (3) **Skills** (documented project knowledge); (4) **Plugins/connectors** (MCP, access to real tools); (5) **Sub-agents** (separating generation from verification); (6) **Memory** (markdown, Linear/GitHub boards — outside the context window). *"Agents forget. Repositories remember."*
- **Claude Code and Codex embed the 5 building blocks + memory** under different names but identical structures → design loops that survive a tool change.
- **Automations**: Codex (Automations tab, runs into a Triage inbox, empty runs self-archive); Claude Code (`/loop` + hooks + GitHub Actions integration). Key in-session primitive = **`/goal`**: sustains work until the specified condition is verifiably true, **a separate, smaller model grades completion on every turn** (the agent does not self-assess).
- **State as of mid-2026**: `/goal` shipped in Claude Code **v2.1.139 (May 11, 2026)**, the 2.1.x branch with **Opus 4.8** as default plus dynamic workflows orchestrating large sub-agent fleets; Codex added `/goal` in **CLI 0.128.0**. Practitioners report agents working unsupervised for dozens of hours → **stop conditions become the most critical element**.
- **Write stop conditions as contracts**: end state + proof + constraints + turn/budget cap. E.g. "`src/billing` coverage ≥ 90%; `npm test` exits 0; no public API changed; stop after 25 turns or $5."
- **Three practices for reliable loops** (Claude Code teams): preserving errors (so the loop learns instead of repeating), building in verification *from the start*, treating red tests / red CI as **honesty signals**. A loop with no proof of failure always believes it succeeded.
- **Worktrees** = real git isolation (separate directories on distinct branches, shared history). But **"You remain the ceiling"**: human review capacity, not the number of worktrees, determines how many agents one actually runs in parallel.
- **Maker-checker sub-agents** = the most powerful structural change: an **adversarial** verifier agent (strong model, high reasoning, instructed to reject anything unproven) gating work before human review. Models that grade their own work are too generous.
- **Maturity scale (Levels 0→4)**: 0 Manual → 1 Triage (findings in markdown, no code) → 2 Draft (fixes on isolated branches) → 3 Verified PR (verifier sub-agent as gate) → 4 Auto-merge (low-risk categories on green CI). Move up a level only if the current one produces work one would have done oneself.
- **3 risks that worsen (not lessen)**: **verification remains your responsibility** ("done" is a claim, not proof); **understanding debt accelerates** (code ships faster than it is understood); **cognitive surrender** (accepting outputs without judgment) — two people building the same loop get opposite outcomes depending on whether they use it to advance work they understand or to avoid understanding it.
- **Watch the tokens**: scheduled loops + post-turn verifier models burn tokens fast. Start with slow cadences and tight conditions, monitor costs for several days, scale only after proof of useful merged work.
- **Security**: autonomous loops with connectors touch production → guardrails, permissions, audit logging required.

## RésuméDe400mots

This guide from the Lushbinary agency theorizes **loop engineering**: the shift from *manually prompting* a coding agent to *designing the systems that prompt it automatically*. For two years, extracting value from an agent followed a simple pattern (prompt, context, review, next instruction) where the developer retained control at every turn. Starting June 2026, the leverage shifts: the developer stops being the primary prompter and becomes the designer of an **outer loop** that discovers work, distributes it, validates results, documents, and decides what comes next. The term, popularized by **Addy Osmani** (Google), draws on Peter Steinberger (*"design loops that prompt your agents"*) and Boris Cherny (Claude Code/Anthropic: writing loops rather than prompting).

Loop engineering is the **third layer** of a stack (prompt → context → loop), each encompassing the previous one; complexity does not decrease, the leverage shifts toward design. Geoffrey Huntley's **Ralph technique** (early 2026) is its pre-terminology validation: a `while` loop, the same prompt, **fresh context on every iteration**, durable state on disk (`PLAN.md`, `STATUS.md`). Loop engineering productizes it.

A functioning loop requires **five building blocks + memory**: (1) scheduled **automations** (Codex Automations; Claude Code `/loop`, hooks, `/goal`); (2) git **worktrees** for parallel agents without collisions; (3) **skills** capturing project knowledge (`SKILL.md`); (4) **plugins/connectors** via MCP (portable across tools); (5) **sub-agents** separating the "maker" from the "checker"; (6) **memory** outside the context window (markdown, boards). Claude Code and OpenAI Codex now embed these building blocks under different names but identical structures.

The `/goal` primitive (Claude Code v2.1.139, May 11, 2026, Opus 4.8 by default; Codex CLI 0.128.0) sustains work until a condition **verified by a separate model** is met. Hence the imperative: write stop conditions **as contracts** (end state, proof, constraints, turn/budget cap). The **maker-checker** split (adversarial verifier) is the most powerful change. A 5-level **maturity scale** (Manual → Triage → Draft → Verified PR → Auto-merge) guides cautious adoption, with the human staying in the loop as long as the evidence doesn't support stepping back.

Three risks **worsen** with sophistication: verification remains human ("done" is a claim, not proof), **understanding debt** accelerates, and **cognitive surrender** looms. Conclusion: design loops "like someone who intends to remain an engineer."

## GrapheDeConnaissance

- Addy Osmani —publie→ Loop Engineering (METHODOLOGIE, 0.95)
- Loop Engineering —s_inspire_de→ "you should be designing loops that prompt your agents" (CITATION, 0.92)
- Boris Cherny —affirme_que→ "mon focus est passé à écrire des boucles plutôt qu'à prompter directement" (AFFIRMATION, 0.9)
- Loop Engineering —remplace→ prompting manuel des agents (CONCEPT, 0.93)
- Loop Engineering —est_basé_sur→ Context Engineering (METHODOLOGIE, 0.88)
- Geoffrey Huntley —a_créé→ technique Ralph (METHODOLOGIE, 0.95)
- Technique Ralph —utilise→ réinitialisation du contexte à chaque itération (CONCEPT, 0.93)
- Loop Engineering —est_basé_sur→ technique Ralph (METHODOLOGIE, 0.9)
- Git worktrees —résout→ collisions de fichiers entre agents parallèles (CONCEPT, 0.94)
- Sub-agents maker-checker —permet→ séparation génération / vérification (CONCEPT, 0.93)
- /goal —fait_partie_de→ Claude Code (TECHNOLOGIE, 0.92)
- Claude Code —utilise→ Opus 4.8 (TECHNOLOGIE, 0.9)
- Skills —réduit→ coût de ré-explication du contexte projet (CONCEPT, 0.9)
- Mémoire externe —permet→ persistance de l'état entre runs (CONCEPT, 0.92)
- MCP —permet→ connecteurs portables (CONCEPT, 0.88)
- Loop Engineering —affirme_que→ "la dette de compréhension s'accélère avec des boucles plus rapides" (AFFIRMATION, 0.85)
- Conditions d'arrêt —recommande→ écriture comme des contrats (état, preuve, contraintes, budget) (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/en/fiches/lushbinary-loop-engineering-ai-coding-agents-guide-2026-06-09/