--- title: "Practical Loop Engineering" section: "raw" type: "source" created: "2026-08-27" updated: "2026-08-27" canonical: "https://pyweb.dev/wiki/raw/articles/addy-osmani-practical-loop-engineering-2026" --- # Practical Loop Engineering By Addy Osmani (2026). Originally published on Substack. A practical guide to operating autonomous feedback loops, goal-driven agents, scheduled tasks, and maker-checker verification pipelines. ## Core Extraction Summary ### 1. Named Frameworks & Patterns (Author's Exact Words) - **"Loop engineering"**: Designing an autonomous, self-correcting feedback cycle where an AI agent repeatedly acts, tests results, and adjusts approach until a specific goal is met. - **"Goal primitive" (`/goal`)**: Bounded iteration mechanism where a generator agent acts and an independent evaluator model verifies completion criteria after each turn until criteria are satisfied or a turn budget is hit. - **"Loop primitive" (`/loop`)**: Time-based scheduler re-running prompts on a cadence (e.g., `/loop 5m check PR and fix CI`). - **"Schedule primitive" (`/schedule`)**: Cloud-based persistent routine that executes out-of-session background tasks. - **"Four kinds of loops"** (Claude Code taxonomy): 1. *Turn-based (Agentic loop)*: Human directs each turn; agent gathers context, edits, tests, and responds. 2. *Goal-based loop*: Multi-turn autonomous iteration evaluated by an independent checker model against deterministic criteria. 3. *Time-based loop*: Recurring prompt on a fixed cadence for external state polling. 4. *Proactive loop*: Event-triggered or cloud-scheduled routines running autonomously without real-time human intervention. - **"Maker and Checker separation"**: Architectural pattern where the sub-agent that drafts code is strictly separated from an independent verifier sub-agent that evaluates correctness. - **"Triage loop"**: Automated triage routine parsing issues/PRs against codified contribution rules and labeling or closing non-conforming items. ### 2. Decision Rules - **When defining a goal loop**, supply deterministic, measurable stopping conditions (e.g., test pass count, Lighthouse score threshold, zero TypeScript errors), **because** without explicit criteria the generator model will prematurely decide its work is "good enough". - **When verifying code changes**, never allow the generating agent to grade its own output; delegate verification to a separate sub-agent or tool runner, **because** maker models are systematically overconfident about their own work. - **When an agent repeats the same command 3 times with no change in result**, terminate or interrupt the loop, **because** the agent has entered a spinning-in-place failure loop. - **When automating frontend changes**, enforce a mandatory verification checklist (start dev server, interact with controls, screenshot before/after, check browser console for 0 errors, audit Core Web Vitals) before declaring done. ### 3. Anti-Patterns & Failure Mechanisms - **"Self-grading maker"**: The model that wrote the code evaluating its own correctness; leads to overlooked edge cases (e.g. evaluating desktop-only performance while breaking mobile). - **"Spinning loop"**: An unattended agent running identical failing commands repeatedly without adjusting strategy or back-off. - **"Subjective goal loops"**: Attempting to use goal loops for vague or aesthetic objectives (e.g. "make UI design good") where automated evaluation cannot compute a deterministic verdict. ### 4. Quantitative Claims & Qualifiers - Osmani runs between 5 and 10 agents concurrently every day, typically maxing out at 5 active parallel threads. - Recurring loops in Claude Code expire after 7 days (session-scoped unless moved to `/schedule`). - The 3-command loop-spinning heuristic: 3 identical command executions without progress indicates an unrecoverable stall. ### 5. What the Source Does NOT Claim - Does **NOT** claim loop engineering eliminates human code review on sensitive features (auth, security, payments, core architecture); explicitly mandates close human supervision and code review for high blast-radius domains. --- ## Full Text The way that I typically work is I have anywhere between five and ten agents working at the same time in parallel. There are going to be some tasks that I’m very happy to delegate fully to agents, as long as I have a very clear idea of the stopping conditions and the constraints around them. And then there are going to be some tasks where I am going to want to keep a closer eye and code-review what the agent is doing. Now within that, you’ve probably heard about **loop engineering**. > A loop is an autonomous, self-correcting feedback cycle where an AI agent repeatedly acts, tests its results and adjusts its approach until a specific goal is met. There are now basically two core primitives you can think about. In Claude Code you have a **goal primitive**, which can drive a single bounded task forward until you’ve got a particular goal, like a measurable finish line that’s been met. And then **loop** reruns on a timer or a fixed interval, so you can use it to schedule changes. ### How the Claude Code team frames loops The Claude Code team published their take on four kinds of loops: 1. **Turn-based loop (Agentic loop)**: Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. 2. **Goal-based loops**: When a single turn is not enough, define what done looks like with `/goal`. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or the turn limit is reached. 3. **Time-based loops**: For recurring work or external monitoring, `/loop` re-runs a prompt on an interval (e.g. `/loop 5m check my PR, address review comments, and fix failing CI`). 4. **Proactive loops**: Triggered by events or schedules in the cloud with no human in real time, routing routines to smaller models and using capable models for judgment. ### Verification Advice: verify-frontend-change Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 1. Start the dev server and open the edited page in the browser. 2. Interact with the change directly. Click controls, confirm state changes, screenshot before/after. 3. Check browser console: zero new errors or warnings. 4. Run Chrome DevTools performance trace and audit Core Web Vitals. If any step fails, fix the issue and rerun from step 1—do not hand back partially verified work. ### Maker and Checker Separation The other habit that matters here is not letting the agent that did the work decide the work is good. One sub-agent drafts the change. A separate one verifies it. Sometimes an agent can be confident about something, and a verifying agent can catch things that they weren't necessarily expecting. Like if it thinks that the baseline performance of an experience it’s generated is actually fine, and it’s only evaluating performance based on desktop, but you’re actually caring about the experience on mobile. ### What Loops Don't Buy You If you don’t have a clear idea of what end-state/done/good means for your completion, loop engineering is not the right pattern. Vague goals ("keep going until this UI design is good") fail because there is no objective evaluation function. Tasks requiring human taste, subjective design, or open-ended creative exploration are not a good fit. --- ## Agent Navigation ### Machine endpoints - Knowledge graph: https://pyweb.dev/api/graph.json - Graph analysis: https://pyweb.dev/api/graph-analysis.json - Context index: https://pyweb.dev/llms.txt