Ralph Wiggum (and why Claude Code's implementation isn't it)
The official Anthropic Ralph plugin differs fundamentally from the original technique: outer orchestrators with full context resets produce deterministic outcomes, while inner-loop plugins with auto-compaction lose critical context.
The Core Difference
Geoffrey Huntley and Dex Horthy break down why Anthropic's official Ralph plugin misses the point of the original technique. The distinction comes down to architecture: outer orchestrator vs inner plugin.
Original Ralph: A bash script wraps Claude Code, feeding fresh context on every iteration. The context window fully resets between loops, keeping objectives deterministic.
Anthropic's Plugin: Runs inside Claude Code, relies on auto-compaction. When context fills up, the model summarizes what it thinks matters. This summary is lossy—it can drop specs, goals, or completed tasks.
Context Windows Are Arrays
Huntley frames context engineering through a C programmer's lens: context windows are arrays. Every message you send allocates to the array. Every tool execution auto-allocates more. The LLM slides a window over this array, and the less sliding required, the better the outcomes.
The key insight: deliberately allocate the first entries in the array. If you always inject specs and objectives at position zero, they stay in the "smart zone" near the top of the window.
One Context = One Goal
"One context window, one activity, one goal."
When you extend context indefinitely and let compaction run, you lose deterministic allocation. The sliding window might contain two or three goals, some already completed. The model gets confused about what's actually done.
With outer-loop Ralph, each iteration resets to a single objective. Finish, reset, reallocate, repeat.
Human On the Loop, Not In
The distinction between "in the loop" (human approves every action) and "on the loop" (human watches, intervenes only when needed). Huntley treats Claude Code streams like a fireplace—watch patterns, notice stupid behaviors, then engineer them out through prompt refinement.
"Discoveries are found by treating Claude Code as a fireplace that you just watch."
Security Architecture
Running dangerously-allow-all on your local laptop exposes everything: Bitcoin wallets, Slack cookies, GitHub tokens. The threat model isn't "if" the agent gets compromised—it's "when."
Their setup: ephemeral GCP VMs with restricted network access and minimal credentials. The only keys present are API tokens for Claude and deploy keys for specific repos. When (not if) it gets popped, the blast radius stays contained.
The Test Runner Problem
Most test runners output too many tokens. If tests pass, Claude sees massive JSON output. If tests fail, the actual error might be at line 50 while Claude only sees tail -100.
Solution: custom test scripts that only output failing tests. Passing tests produce zero tokens.
Connections
- ralph-wiggum-as-a-software-engineer - Huntley's original technique this video critiques implementations of
- context-engineering-guide - The array-allocation mental model fits context engineering principles
- 12-factor-agents - Offers an alternative to loop-based patterns through deterministic workflows