The Ralph Wiggum technique — pioneered by Geoffrey Huntley — has become one of the most talked-about patterns in AI-driven development. The core idea is simple: feed the same prompt to an AI agent in a loop, letting it see its own previous work each iteration. The agent iteratively improves until the task is done.
But not all Ralph Wiggum implementations are created equal. In this post, we'll compare three approaches: the raw shell loop, the Ralph Orchestrator, and the task-driven pipeline used by clawdup. Each has trade-offs around collaboration, reliability, and scalability.
What Is the Ralph Wiggum Technique?
Before we compare methods, let's recap the core concept. The Ralph Wiggum technique runs an AI agent in a loop against the same prompt:
while :; do cat PROMPT.md | claude --continue done
Each iteration, the agent receives the same instructions but sees the current state of the codebase — including changes it made in previous iterations. This self-referential pattern allows the agent to build incrementally toward a goal, catching its own mistakes and refining its work.
Geoffrey Huntley describes it as "deterministically bad in an undeterministic world" — failures are predictable, which means you can systematically improve the process by tuning prompts.
Method 1: The Raw Shell Loop
The simplest approach is a bare while loop in your terminal:
while :; do cat PROMPT.md | claude --continue done
How it works: You write a PROMPT.md file describing what you want, and the shell loop feeds it to Claude Code repeatedly. The agent works on the task, tries to exit, and the loop starts it again with the same prompt. The agent sees its previous changes in the files and git history.
Pros
- Zero setup — just a one-liner in your terminal
- Easy to understand and modify
- Works with any AI CLI tool
- Great for quick, solo experiments
Cons
- No completion detection — the loop runs forever unless you manually kill it
- No collaboration — the prompt lives in a local file; there's no shared record of what was requested or why
- No history — once you overwrite
PROMPT.md, the previous task is gone - No guardrails — nothing prevents the agent from running in circles or making destructive changes
- Single machine — tied to whichever terminal session started it
The raw loop is perfect for experimentation. You can spin one up in seconds and see the Ralph Wiggum technique in action. But for anything beyond personal tinkering, its limitations become apparent quickly.
Method 2: The Ralph Orchestrator
The Ralph Orchestrator (by mikeyobrien) adds structure on top of the raw loop concept. It manages iterations, tracks state, and supports completion detection through "promise" phrases.
# Example usage ralph run --prompt "Refactor the cache layer" \ --max-iterations 20 \ --completion-promise "REFACTOR COMPLETE"
How it works: The orchestrator wraps the loop with iteration counting, state tracking, and a stop condition. When the agent outputs a specific phrase (the "completion promise"), the orchestrator stops the loop. You can also set a maximum iteration count as a safety net.
Pros
- Completion detection — the loop stops when the agent signals it's done
- Iteration limits — prevents runaway loops with
--max-iterations - State tracking — knows which iteration it's on and can resume
- More structured than a raw loop while remaining lightweight
Cons
- Still local — the prompt and state live on one machine
- No shared task queue — if you want multiple tasks, you manage them yourself
- No collaboration — teammates can't see what's being worked on or add tasks to the queue
- No audit trail — completed tasks aren't tracked anywhere persistent
- Manual task management — you decide what to work on next and start each loop manually
The Ralph Orchestrator is a solid step up from the raw loop. It solves the "loop runs forever" problem and gives you more control. But the task management still lives in your head or a local file — there's no shared source of truth.
Method 3: Task-Driven Pipeline (Clawdup)
Clawdup takes a fundamentally different approach. Instead of a prompt file on your machine, the source of truth is ClickUp — a project management tool your entire team already uses.
# Start clawdup — it polls ClickUp for tasks clawdup
How it works: Clawdup polls a ClickUp list for tasks with "to do" status. When it finds one, it creates a git branch, invokes Claude Code with the task description as the prompt, commits the changes, and opens a GitHub pull request. The task moves through statuses: to do → in progress → in review → complete. Everyone on the team can see what's happening.
Pros
- Source of truth — tasks live in ClickUp, visible to the entire team
- Collaboration — anyone can create tasks, add context in comments, and review results
- Full audit trail — every task has a history: who created it, when it was picked up, the resulting PR, review comments
- Automatic task lifecycle — status transitions are handled automatically as work progresses
- PR-based review — output goes to a GitHub PR, not just local files, so the standard review process applies
- Queue management — multiple tasks can be queued up; clawdup processes them in order
- Security guardrails — prompt injection detection, content sanitization, and boundary markers protect against untrusted input
- Superagent integration — ClickUp automations can create tasks automatically, enabling continuous improvement loops
Cons
- Requires a ClickUp account and initial setup
- More moving parts than a simple loop
- One instance at a time — you should only run a single clawdup instance per repository to avoid conflicting branches and race conditions
Side-by-Side Comparison
| Feature | Raw Loop | Orchestrator | Clawdup |
|---|---|---|---|
| Setup complexity | None | Low | Medium |
| Completion detection | No | Yes | Yes |
| Shared source of truth | No | No | Yes (ClickUp) |
| Team collaboration | No | No | Yes |
| Audit trail | No | Partial | Full |
| Task queue | No | No | Yes |
| PR creation | No | No | Automatic |
| Security guardrails | No | Basic | Yes |
| Concurrent instances | Manual | Manual | One per repo |
Why the Source of Truth Matters
The fundamental difference between clawdup and the other approaches is where the work is defined. With a raw loop or orchestrator, tasks live in a file on your machine. With clawdup, tasks live in ClickUp — a platform designed for project management.
This distinction matters for several reasons:
- Anyone can contribute tasks. A product manager can create a task in ClickUp. A designer can add context in a comment. A developer can refine the requirements. None of them need to know how to write a
PROMPT.mdfile or run a shell command. - Work is visible. When clawdup picks up a task, everyone sees the status change to "in progress." When the PR is created, the link appears in the task. No one has to ask "is someone working on this?" or "what happened to that request?"
- History is preserved. Every task has a complete record: the original request, comments, status transitions, the resulting PR, review feedback. This audit trail is invaluable for understanding how a change was made and why.
- Priorities are explicit. Tasks in ClickUp can be ordered, tagged, and prioritized. Clawdup processes them in order. With a raw loop, the "priority" is whichever
PROMPT.mdyou happened to write.
The One-Instance Rule
There's an important constraint with clawdup: you should only run one instance per repository. Running multiple instances would create conflicting branches, race conditions on task status updates, and duplicate PRs.
This might sound like a limitation, but it's actually a feature. A single instance means:
- Predictable git history — changes are applied sequentially, so each PR is based on the latest
main - No merge conflicts between automation branches — since only one task is implemented at a time
- Clear status tracking — there's exactly one source processing the queue, so task statuses are always accurate
- Easier debugging — if something goes wrong, there's one place to look
If you need more throughput, the answer isn't multiple instances — it's better task decomposition. Break large tasks into smaller, focused ones that each produce a clean PR.
When to Use Each Method
Use the raw loop when…
- You're experimenting with the Ralph Wiggum technique for the first time
- You have a quick, one-off task on a personal project
- You want maximum simplicity and zero setup
Use the Ralph Orchestrator when…
- You want completion detection and iteration limits
- You're working solo and don't need team visibility
- You want more control over the loop without full pipeline infrastructure
Use clawdup when…
- Multiple people need to create and track tasks
- You want a complete audit trail from task creation to merged PR
- You need an automated pipeline, not just a loop
- You want to combine AI automation with human code review
- You're building a continuous improvement workflow with superagents
Conclusion
The Ralph Wiggum technique is powerful regardless of which method you choose. The raw loop is a great way to learn. The orchestrator adds helpful guardrails. But when you need a collaborative, auditable, production-ready workflow, a task-driven pipeline like clawdup is the strongest approach.
By making ClickUp the source of truth, clawdup turns the Ralph Wiggum technique from a solo developer trick into a team-wide automation strategy. Everyone can contribute tasks, everyone can see progress, and every change goes through code review before it lands in main. That's the difference between running a loop and running a pipeline.