For Every Ralph There Needs to Be a Superintendent

Image: Superintendent Chalmers and Ralph Wiggum from The Simpsons. Source: ScreenRant

For context on Ralph’s lovable interaction with “Super Nintendo Chalmers,” see this classic scene.

The Ralph Loop is having a moment. Developers are shipping code while they sleep, running autonomous agents for hours, sometimes days, until tasks are complete. Geoffrey Huntley’s “bash loop” technique is elegantly simple: run the same prompt repeatedly, let git be the memory, and iterate until done.

Note: I am aware $ralph token exists and am in no way encouraging that as an investment. Please instead leverage tools like Open Collective and GitHub sponsors.

But there’s a problem we’re not talking about enough: nobody knows what Ralph learned along the way.

The Ralph Loop, Briefly

If you’re unfamiliar, the Ralph Wiggum technique (named after the Simpsons character) is an autonomous coding pattern that runs repeatedly until completion. Each iteration starts with fresh context, no accumulated conversation history, while progress persists in files and git commits.

The pattern looks like this:

while true; do
  claude < prompt.md
  # Did it output <promise>COMPLETE</promise>?
  # If yes, break. If no, loop again.
done

Context resets every iteration. The agent reads what it previously did from the filesystem, picks the next task, implements it, commits, and loops. As Huntley describes it: “That’s the beauty of Ralph, the technique is deterministically bad in an nondeterministic world.”

People are building serious projects this way. Entire compilers. Multi-month refactors. Test suite migrations. The technique works.

The Token Burn Reality

Ralph is expensive.

Running autonomous loops for hours means burning tokens continuously. Each iteration processes the same base prompt plus accumulated git history plus file contents plus tool outputs. The context window fills and resets, fills and resets, over and over.

The math can work favorably, trading compute cost for developer time often makes sense. One hour of autonomous development at $50 in tokens beats a day of human iteration. But that assumes you know what you’re getting for that $50.

What if you don’t?

A Real Example: 1000+ Lint Errors

I ran Ralph against a React codebase that had accumulated over 1,000 linting errors—TypeScript strict mode violations, formatting issues, unused variables, the works. I tested two configurations to see how model choice affects cost and iteration count.

Test 1: Sonnet with a task checklist Claude Sonnet 4.5 worked through the TODO list methodically: prettier formatting, converting @ts-ignore to @ts-expect-error, fixing any types, updating .single() to .maybeSingle() patterns.

Test 2: Haiku with the same tasks Claude Haiku 4.5 tackled the identical checklist. Cheaper per token, but would it need more iterations?

The Results

Metric	Sonnet 4.5	Haiku 4.5
Sessions	111	160
Input Tokens	5.4M	6.1M
Output Tokens	8,546	14,894
Total Cost	$16.48	$6.15
Cost per Session	$0.15	$0.04

Haiku needed 44% more sessions and processed 12% more input tokens—but cost 63% less. The cheaper model iterated more but burned fewer dollars doing it.

The 55-minute session across both tests:

11.5M tokens processed
$22.63 total cost
127 tool calls: bash (50%), file reads (22.7%), edits (19.7%)

Here’s the thing: I only know this because I captured it.

Without telemetry, I’d have seen “lint errors fixed” and moved on. I wouldn’t know Sonnet completed faster while Haiku was more cost-efficient at scale. I wouldn’t see that half the tool usage was bash commands, or that the agent spent most of its time reading files to rebuild context before making edits.

That’s exactly the visibility Ralph lacks in production.

The Observability Gap

My colleague John McBride recently wrote about observability challenges in multi-agent orchestration. His insight applies directly here: ungoverned agent systems are leaky abstractions. Tool calls, reasoning traces, file modifications—all lost. You get the artifact but not the journey.

Diagram showing ungoverned agent orchestration as a leaky abstraction

Diagram: John McBride, johncodes.com

Ralph amplifies this problem. When your agent runs eight hours overnight, you wake up to working software. But:

Which iterations failed and why?
Where did the token budget go?
What patterns led to success vs. dead ends?
How many times did it redo the same work?

Without observability, you’re flying blind. Blind automation at scale is how you burn money without understanding ROI.

Enter the Superintendent

In a world where the principals are filling up their bags—shipping code while Ralph burns tokens without learning from its own mistakes—you need a superintendent.

Think Superintendent Chalmers from The Simpsons. He doesn’t intervene in Principal Skinner’s daily operations, he observes. He shows up, checks if things are running properly, and understands what’s happening without micromanaging.

Ralph needs a superintendent.

Not a controller. Not something that stops the loop or asks for permission. Just an observer that captures what’s happening so you can learn from it later. Ideally, something that works without modifying your agent code—a layer that sits between Ralph and the LLM, watching everything pass through.

Here’s what a superintendent layer should track:

A superintendent layer should track iteration metrics like count, duration, and success rates. It should attribute costs per iteration and per feature, broken down by model. And it should capture behavioral patterns—which tools get called, which files get touched, and where tests pass or fail.

Code Impact

My linting session shows this in miniature: 66 bash calls (50% of tools), 30 file reads (22.7%), 26 edits (19.7%). The agent spent $0.42 fixing formatting issues across 82 SSE events. It worked methodically through a checklist, and I have the complete trace.

That’s superintendent-level visibility.

The Concerns

Running Ralph without a superintendent creates real problems:

Cost Explosion

Tokens burn silently. You might spend $200 on an overnight run without knowing if iteration 47 was the breakthrough or if iterations 23-46 were spinning wheels on the wrong approach.

Learning the Wrong Lessons

Agents learn from their own output. If Ralph commits bad patterns early, subsequent iterations might reinforce those patterns. Without traces, you can’t diagnose where things went sideways.

No Debugging

When Ralph fails after 12 hours, you have no idea why. Was it a malformed prompt? A broken test suite? An API change? The reasoning is gone, lost in 300 context resets.

No Replay

You can’t reproduce the failure. Even if you had logs, Ralph’s nondeterminism means running the same prompt won’t give you the same result. Without a complete conversation record—a tamper-proof audit trail of every message exchanged—you’re guessing at what actually happened.

Safety Gaps

What if Ralph goes rogue? Deletes critical files? Makes breaking changes? Commits secrets? Without monitoring, you won’t know until you wake up to production fires.

ROI Justification

How do you justify autonomous coding budgets to management without metrics? “It works, trust me” doesn’t scale. You need data: cost per feature, success rates, iteration efficiency.

Telemetry for Agents, not agents for telemetry

Diagram showing governed agent orchestration with proper observability

Diagram: John McBride, johncodes.com

The solution exists, we just haven’t applied it yet. We need infrastructure that captures every conversation, stores it in tamper-proof logs, and lets you replay any session exactly as it happened. Content-addressable storage means identical conversation prefixes deduplicate automatically—no wasted space, no data drift.

OpenTelemetry has spent years standardizing observability for distributed systems. Traces, metrics, spans, context propagation. Now there’s a Gen AI SIG working on semantic conventions for LLM applications.

This is where Ralph’s superintendent should live.

Imagine every Ralph iteration emitting OpenTelemetry spans:

Diagram showing Ralph iteration emitting OpenTelemetry spans with Tokens, Model, Span, Tool Calls, Status, and Cost

Ship these to your observability backend to Honeycomb, Datadog, Grafana and suddenly you can answer questions:

What’s my average cost per completed feature?
Which iterations waste the most tokens?
Where do agents get stuck?

Building the Superintendent

Ralph works today. Multi-agent systems work today. But they work in the dark—burning tokens without telemetry, learning patterns we can’t inspect, making decisions we can’t trace.

We can build the superintendent now: standardize the traces, establish the semantic conventions, create the tooling. Or we can bolt it on in two years when companies are spending six figures monthly on autonomous coding and desperately need visibility.

Superintendent Chalmers doesn’t make Skinner a better principal by intervening—he does it by watching, measuring, and asking uncomfortable questions. Your autonomous agents deserve the same scrutiny. Build the superintendent. Know what Ralph learned.

I’m exploring agent telemetry and observability infrastructure as part of Continue’s work on continuous AI workflows. If you’re working on similar problems or want to contribute to the conversation, let’s talk. Find me on b.dougie.dev.