AI coding agents are shifting from single-pass assistance to long-running, iterative execution. That shift exposes a bottleneck: when the agent runs for hours or across many files, how do you know what it was supposed to do — and how do you review the result? This post draws on the Ralph Wiggum technique and connects it to spec-driven frameworks like OpenSpec: persistent context, reviewable intent, and plans that outlive a single chat session.
1. The human-in-the-loop bottleneck
Most AI coding tools today operate in single-pass mode. You give a task, the model reasons and generates code, then it stops. Even when it could iterate on its own work, the default workflow assumes you will review every step. That creates what Geoffrey Huntley (creator of the Ralph Wiggum approach) calls the human-in-the-loop bottleneck.
For small, localised tasks this is fine. For migrations, refactors, or multi-file changes, the loop becomes exhausting: you spend time reviewing every change, re-prompting when something breaks, and waiting for the agent to resume. The limiting factor is often not model intelligence or context size — it’s the workflow that forces a stop after every action.
The alternative is autonomous loops. The agent executes, checks its own work (e.g. via tests or compilation), and iterates until a completion condition is met. You define success upfront; the agent works toward it. Failures become input for the next iteration. No human approval is required for every micro-step.
2. Iteration beats perfection
The Ralph Wiggum technique is often summarised as: “Ralph is a Bash loop.” You run the agent on the same prompt repeatedly until a stop condition is satisfied. The agent sees its previous work (e.g. via git history and modified files), learns from it, and improves.
- Single-pass: One prompt → one attempt → done (or not).
- Loop: One prompt → attempt → check result → if incomplete, iterate → repeat until done.
Implementation details vary (e.g. “stop hooks” that intercept the agent’s exit and re-inject the prompt if a completion promise isn’t found). The important idea is a shift in execution model: from one shot to continuous iteration. The agent doesn’t need to be right first time; it needs to make progress. Iteration handles the rest.
In loop mode, behaviour changes. The agent can afford to be wrong occasionally. It tries approaches faster. Errors become data for the next run. The insight is that deterministically bad (we know the agent will sometimes fail; the loop recovers) can beat unpredictably good (occasional success, but chaotic failure and manual intervention).
3. From directing to designing convergence
When you move from single-pass to loops, the human role shifts. You are no longer directing every step; you are designing conditions under which iteration converges to success.
- Define clear success criteria (what does “done” mean?).
- Provide verifiable checkpoints (tests, linters, compilation) so the agent can validate its own work.
- Structure prompts so that wrong turns are correctable (e.g. “if tests fail, read the error, fix, re-run”).
Prompting becomes less about perfect one-shot instructions and more about convergence: will repeated attempts, with feedback, tend toward a correct outcome? That’s a different skill — and it pays off when agents run for hours or overnight on migrations, refactors, or greenfield builds.
4. Where loops run into limits
Autonomous loops work well when:
- The task has clear, checkable completion criteria.
- Feedback exists in the environment (tests, build, lint).
- Context is available to the agent (e.g. git history, current files).
But as soon as work spans multiple sessions, multiple agents, or multiple people, a new problem appears: intent and context are tied to a single run or chat. When the session ends, or when someone else (or another tool) continues the work, the “why” and the “what we agreed” are not first-class artefacts. They live in chat logs or in the developer’s head.
That’s where spec-driven and plan-as-artifact tooling enters.
5. Spec-driven tools: OpenSpec and beyond
When agents run in loops over long periods, you need:
- Context that persists — not only inside one agent session.
- Review of intent — not only of the resulting code.
- Plans that outlive the conversation — so the next run, or the next developer, can see what the system is supposed to do.
OpenSpec is a lightweight, spec-driven framework that fits this model. A few ideas that align with autonomous loops:
Specs live in the repo
Specs are stored alongside code, organised by capability. When an agent needs context about how a feature should behave, it reads the spec. When a new developer joins, they browse the spec library. Context doesn’t disappear when a chat session ends. That’s exactly what long-running or multi-session agent work needs: a single source of truth for “what we’re building” that both humans and agents can use.
Review intent, not just code
Each change can produce a spec delta: how requirements are changing, not only which lines of code changed. Reviewers can judge whether the intended behaviour is right before diving into implementation. For agent-generated or agent-modified code, that’s critical: you want to review the contract and the requirements, not only the diff.
Proposal and tasks before code
OpenSpec encourages generating a proposal document, implementation tasks, and design notes — and showing how specs would change — before writing code. You review and refine the plan first. That fits the “design convergence” mindset: define what “done” looks like and how requirements change, then let the agent (or the team) execute. Misalignment is caught at the spec level, not only when tests fail.
Brownfield and multi-session
OpenSpec is aimed at existing codebases and at plans that extend over multiple sessions or tools. That matches the reality of autonomous loops: work that runs overnight, or that you hand off to another agent or human. A shared spec layer gives everyone — and every run — the same view of intent.
6. Bringing it together
Autonomous coding loops (Ralph Wiggum–style or similar) remove the need for a human to approve every step. They rely on clear success criteria, verifiable feedback, and iteration. The human role becomes designing for convergence rather than micromanaging output.
Once work spans sessions, agents, and people, that convergence design must be reflected in artefacts that persist: specs, proposals, and task breakdowns that live in the repo and can be read by both humans and agents. Tools like OpenSpec provide that layer — lightweight, brownfield-friendly, and agnostic to which coding agent you use.
Together, autonomous loops and spec-driven tooling point toward a workflow where agents can run long and loud, while intent stays explicit, reviewable, and durable. That’s a practical path to scaling AI-assisted development without losing control or clarity.
Further reading:
- The Ralph Wiggum Breakdown (DEV Community) — human-in-the-loop bottleneck, stop hooks, and convergence.
- OpenSpec — spec-driven framework, specs in repo, proposal-first workflow.