Ralph Wiggum loops: useful persistence needs a stopping rule
How to use a coding loop for bounded implementation work, with explicit acceptance checks, spending limits, and a handoff when progress stops.
Revised September 4, 2026.
A coding agent that keeps trying can be useful. It can also keep making the same mistake, expand a small task into a rewrite, or spend the night satisfying a weak test. Persistence is valuable only when the loop has a meaningful target and feedback you can trust.
The Ralph Wiggum technique, described by Geoffrey Huntley, repeats coding-agent work against a specification and recorded task state. Its practical appeal is continuity across attempts rather than a single, overloaded conversation. Read Huntley's original account.
This is a technique for organizing work, not evidence that unattended output is production-ready.
Give the loop one bounded job
A useful task has a visible finish line. For example: “Add cursor pagination to this existing read endpoint, preserve the current response fields, and demonstrate that consecutive pages do not repeat records.”
That is an illustrative task, not a universal recipe. It identifies the behavior, a compatibility constraint, and an acceptance check. “Improve the backend until it is excellent” gives the loop no reliable way to stop.
Supply the repository's real build and test commands, relevant files, known constraints, and the actions the agent may take. State what it must not change without a decision from the owner.
Separate the loop from the release gate
A conceptual loop looks like this:
Read the task, evidence, and current repository state.
Choose one remaining acceptance condition.
Make a scoped change.
Run the relevant checks and record their actual results.
If acceptance is demonstrated: hand off for review.
If blocked, out of budget, or no longer progressing: stop and explain.
Otherwise: continue with the next bounded step.
This is pseudocode, not a ready-to-run supervisor. A real implementation must enforce time and spending limits, tool permissions, and cancellation outside the model's instructions.
Keep release authority separate. Completing an implementation task does not automatically authorize merging, deploying, changing production data, or contacting users.
Feedback must test the intended behavior
A compiler catches the errors its type system can express. It does not prove that a discount rule is correct, a user has the right permission, or a migrated record retains its meaning. The same limitation applies in Rust: type safety does not eliminate business-logic defects.
Derive acceptance tests from the requirement, not from whatever implementation the agent produced. Keep an independent review of changed tests. A loop that weakens assertions until they pass has optimized the wrong target.
For the pagination example, an HTTP 200 response is insufficient. Check record order, boundaries, continuation, and the defined behavior when the underlying data changes.
Recognize a loop that has stopped learning
Watch for repeated patches to the same area without improved evidence, tests that only check formatting, growing scope, and unexplained dependency changes.
Use an external limit on attempts and total runtime. Define a no-progress condition appropriate to the task: for example, repeated failure of the same acceptance case without a new verified hypothesis. There is no single iteration count that fits every repository.
When the limit is reached, keep the work recoverable. The handoff should identify the last verified state, changed files, commands run, unresolved failure, and the decision or information needed next. Do not let the agent declare success merely to exit.
Choose an appropriate environment
Use an isolated branch or worktree, scoped credentials, and representative test data. Restrict outbound access and destructive commands according to the task. Dependencies and scripts still need review.
Work only with code, specifications, and assets you are authorized to use. Automated implementation is not permission to copy a third party's proprietary product or bypass its access controls.
A bounded loop is most useful when feedback is inexpensive and the acceptance conditions are concrete. Ambiguous product decisions, unavailable credentials, or an undocumented business rule usually require a person rather than another attempt.
Judge the completed work, not the running time
Measure reviewed changes that satisfy the task, escaped defects, and total cost including supervision. “Ran overnight” describes a schedule. It says nothing about readiness.
For work in an existing application, pair the loop with a focused investigation and migration plan. For an original example of a multi-stage build with review and playable artifacts, see our game-building experiment.