The Ralph Loop has recently gained a ton of traction for fixing an unpopular aspect of coding agents: human intervention.
The Ralph loop was introduced by Geoffrey Huntley, who found this behavior similar to that of Ralph Wiggum from The Simpsons, who’s known for being persistent yet not particularly skilled. He describes it as a while true bash loop for your agent.
It’s deceptively simple: a Ralph loop re-prompts your agent a set number of times with the same prompt. It refuses to let your agent say it is done with a task, and forces it to keep iterating until it hits a stop condition.
Coding agents aren’t at the point where they can one-shot tasks and still get solid results. Devs report stronger outputs when they get an agent to iterate on a feature several times, and the Ralph loop does exactly that.
How to do this with Claude Code
Conveniently, Anthropic maintains their own Claude plugin for Ralph loops.
In order to use it, install the plugin within a CC session:
/plugin install ralph-wiggum@claude-plugins-official
You want your prompt to include a list of standards that the code must meet before the loop stops executing (1. all tests must pass 2. endpoints must be working). You will also set a maximum number of iterations using the --max-iterations flag.
Use this syntax and keep your requirements specific:
/ralph-loop "Refactor authentication to use dependency injection. Requirements: Extract auth logic into AuthService, controllers inject AuthService via constructor, all tests passing, add unit tests for AuthService. Output REFACTOR_COMPLETE when done." --max-iterations 10
It’s a decent alternative way to prompt, and can get you more “complete” or “refined” results with less involvement. But after all, it’s named after Ralph Wiggum for a reason: it isn’t going to give you smarter code…
Ralph looping in ephemeral environments
You’ve specified a set of stop conditions for your Ralph loop, e.g. all E2E tests passing. To verify that your agent-written code is up to spec, you can configure your Ralph loop to run tests against your new code changes as soon as they get auto-deployed to an ephemeral environment.
For example, you can get this set up with Shipyard, and your agent can easily use the Shipyard MCP and/or CLI to run tests against a branch’s environment.
<!-- prompt.md -->
Implement a dark mode toggle button and verify it works in a Shipyard ephemeral environment.
Steps:
1. Add a dark mode toggle button to the UI (header or settings area)
2. Implement dark mode styles (CSS variables or Tailwind dark: classes)
3. Add state management for dark mode preference (localStorage persistence)
4. Ensure all components respect dark mode state
5. Commit code to the current branch
6. Use Shipyard MCP to get environment URL for current repo + branch
7. Write e2e tests for dark mode
8. Run e2e tests against the Shipyard environment URL
9. Use Playwright MCP to screenshot button appearance
When complete:
- Dark mode button is visible and functional
- Clicking button toggles between light and dark themes
- Theme preference persists on page reload
- All UI components properly styled in both modes
- Shipyard environment successfully created (if not, check logs and remediate)
- New dark mode e2e tests passing in Shipyard
- All existing e2e tests passing in Shipyard
- No visual regressions or broken layouts
- Output: <promise>COMPLETE</promise>
Iterating on an app locally can only get you so far, since having your other services, integrations, and data in play can change a feature’s behavior. That’s why the Ralph loop especially makes sense here, since you can give your agent the infra it needs to test and verify autonomously, and ultimately get a more productive agent session.
Try it yourself
Once you’re running Ralph loops to build and test against your local environment, you can implement more rigorous testing/verification by incorporating remote environments into your Ralph workflows.
To get started, kick off a 30-day free Shipyard trial, type out a well-defined Ralph prompt, and walk away from your computer for an hour or so.
