feedback-loops

Snapshot of community thinking about the “Ralph Wiggum” loop (created by Geoffrey Huntley), covering both the original bash technique and the official Claude Code plugin (“Ralph Loop”). This note summarizes public docs, origin posts, and community reports, related approaches as of January 2026. Executive summary Ralph turns a one-shot prompt into an iteration loop that keeps working until a completion signal or iteration cap is reached. The main split is “OG bash loop” (fresh context each run) vs the official plugin (stop hook in a single session). The loop succeeds when “done” is machine-verifiable (tests pass, lint clean, checklist complete). Best fit: deterministic, mechanical tasks (migrations, lint fixes, test-first loops, repo hygiene). Weak fit: architecture or ambiguous goals without hard exit criteria. Guardrails are essential: max iterations, explicit tests, budget awareness, and carefully scoped permissions. Common failure modes: context pollution, hallucinated “done”, permission dead-ends, and cost blow-ups. The ecosystem now includes loop runners, verification plugins, and guardrails that reduce risk in long runs. Verified facts (as of Feb 1, 2026) Official Status: The plugin is published as “Ralph Loop” and is Anthropic Verified. Canonical Syntax: /ralph-loop "..." --max-iterations N --completion-promise "..." Cancel Command: Explicit support for /cancel-ralph. State Preservation: The plugin description claims it preserves file modifications and git history between iterations (“claimed by plugin page”). What Ralph is Mechanism (official plugin) The official plugin registers a stop hook. When Claude tries to exit, the hook checks for a completion promise (a specific string) and an iteration cap. If the promise is not present and the cap is not reached, the plugin re-injects the original prompt and continues within the same session. The codebase on disk is the durable “memory” that carries progress forward. ...

Incrementalism is the practice of reducing batch size so you can: learn sooner (faster feedback) reduce risk (smaller blast radius) keep options open (cheaper course-correction) In AI-assisted work, the same idea becomes more important, not less: the tooling can generate more output faster, but that doesn’t make it more trustworthy. Core Idea Build in thin slices and run a tight loop: Decide the smallest slice that will teach you something real. Specify only what you need to move forward (avoid “whole spec first”). Implement the slice, verify it (tests + review), and integrate it. Ship or stage it (flags if needed), observe, and repeat. The goal is not “more output per cycle”; it’s shorter cycle time and higher learning rate. ...

This note summarizes the “Three Developer Loops” framework from the book Vibe Coding by Gene Kim and Steve Yegge. The core idea: AI-assisted development happens across three different feedback-loop timescales. Practices (and patterns) must match the loop you’re currently in to maintain speed without sacrificing quality. The three loops (timescales) Inner Loop (seconds to minutes): Rapid, conversational collaboration with an AI assistant for constant, fast iterations. Middle Loop (hours to days): Continuity across multiple sessions, coordination between agents, and context management. Outer Loop (weeks to months): Long-term architecture, system-level sustainability, and organizational governance. Across all three loops, apply the same control logic: ...