Published: 2026-01-22
The Ralph Wiggum loop is a pipe dream in the most literal sense. A developer pipes a plan into Claude Code or OpenCode and dreams of a beautiful, one-shot app that will make them millions. It's fun to play with when you have spare tokens, but it's a terrible idea for production code.
while true; do
cat PLAN.md | opencode run
doneThat said, there are solid ideas we can extract from this fantasy to produce better code from the start. Even when a human stays in the loop (which you absolutely should if you're shipping anything to production).
Use sub-agents to handle the dirty work: searching, exploring, and gathering context that would otherwise bloat your main window and cause rot. Be specific when assigning research tasks. Give each sub-agent a clear goal like "read this code and report back what it does." This keeps your main orchestration context clean and focused on relevant information only.
Once you have the context, have a real conversation where you and the LLM ask each other questions until you're perfectly aligned. This reveals implicit assumptions the LLM makes that would cause bugs later. These assumptions become insidious as your repo grows.
What you're after:
Have the LLM create a comprehensive specification document. This doc takes all the gathered context and produces clear, unambiguous language. Instruct the LLM that every assumption must be made explicit. Hopefully the previous step eliminated most of them. Then have it document all edge cases. If it's a potential edge case, it goes in the spec.
Critical rule: no implementation details or code samples in this document. This is purely about what needs to be done, why it needs to be done, and potentially where it should be done. Keep it focused on requirements and behavior.
Specification requirements:
Now build a comprehensive, step-by-step plan with implementation details. Create bullet points for every single task that needs completion. Add checkboxes beside each task so the LLM can mark progress. Each task must be completable in one iteration. You'll be reusing this with a fresh context window after each section completes.
Order tasks by dependency and priority. The goal is breaking down the specification into discrete units of work the LLM can tackle individually with clean context while marking its progress.
Checklist format:
- [ ] Task descriptionThis is the most critical step. Read every single line of both documents the LLM produced. Your job as the human in the loop is verifying every word. If one detail is wrong in either document, every subsequent step inherits that error. The cascading agents pick up where previous work left off, building on potentially flawed foundations.
Skip this step and you won't understand what the plan is. You won't be able to answer questions about work that's been done or fixes that have been made. As always: the machines will not be held accountable, but you will be.
Beyond accountability, skipping this step means implementations won't match your expectations. Every time you engage the LLM, you have a mental model of the desired outcome. The challenge is translating that model into the LLM's context with perfect fidelity. Without verification, errors cascade and amplify with each loop iteration.
Approve or revise each line until these plans match your mental model.
Create a command file that gets fed to the LLM on every iteration.
# Instructions
1. Study spec.md thoroughly
2. Study implementation-plan.md thoroughly
3. Pick the highest leverage unchecked task
4. Complete the task
5. Write an unbiased unit test to verify
6. Update implementation-plan.md to check off the task
# Optional Repository Context
[Include repository structure]
[Include coding conventions]
[Include any other context needed since each loop starts fresh]Load OpenCode and run the command. Watch for any assumptions by the LLM. If you spot any, stop the process and update the plan. Be sure to commit after each checklist item is complete and you're satisfied with the output.
When the line changes grow too large, make a new branch and proceed with the next loop. Branching off an existing working branch is called stacked diffs. Doing this lets agents build on a solid foundation. If they break working code, you can restore to the previous branch or commit. The commad I use to check how many lines changes your current branch has is: git diff --shortstat.
The Ralph Wiggum loop fails because it ignores the human element. Production-ready code requires human judgment at every checkpoint. Build your process around that reality, and your AI agents become powerful force multipliers instead of token-burning fantasies.