Ralph: The While Loop That Codes While You Sleep

A developer at a Y Combinator hackathon shipped six repositories overnight using nothing but a bash loop. The code wasn't perfect, but it was done. While he slept. This is Ralph, and people are either excited or terrified.​

Ralph isn't software. It's barely even a technique. It's a while loop that feeds Claude Code the same prompt over and over until something happens​.

Geoffrey Huntley built it in July 2025, and the command looks like this: while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done ​.

That's it. No fancy orchestration. No complex state management. Just keep trying.

What Actually Happens

You give Claude a task with clear completion criteria. Ralph watches the output. If it doesn't see your completion signal (like "DONE" or "SUCCESS"), it feeds Claude the same prompt again. But here's the trick: Claude sees its previous attempt. It can review what it tried, understand where it failed, and improve.​

One developer converted 100,000 lines of Python to TypeScript in two weeks using variations of this approach. Another ran it for four hours and got 119 commits, 14,000 lines of code, zero build errors. The system just kept iterating until tests passed.​

But then there's this: someone on Reddit ran Ralph for the first time and it "took over another session". They were running Claude Code in two different terminals. Ralph didn't care. It crossed boundaries they didn't expect.​

The Part No One Mentions

Ralph has "deterministic badness". Its flaws are consistent. Predictable. Which sounds terrible until you realize that makes them fixable.​

Think of it like tuning a guitar. When Ralph messes up, you don't blame the loop. You adjust the instructions. Geoffrey explains it like this: you tell Ralph to build a playground, and it comes home bruised from falling off the slide. So you add a sign: "SLIDE DOWN, DON'T JUMP, LOOK AROUND." Ralph reads signs. It just needs more signs.​

This creates problems people don't expect.

The community built safeguards. Rate limiting (100 calls per hour). Circuit breakers to prevent infinite loops. Maximum iteration counts. One implementation tracks state with a to-do list format, letting Ralph check off completed tasks. When the count hits zero, it stops.​

Where It Actually Works

Ralph excels at things you can test automatically. Code conversions. API generation. Database schema migrations. Tasks with clear pass/fail criteria.​

It fails at anything requiring taste. Design decisions. Choosing between two valid approaches. Writing marketing copy. The moment "good enough" becomes subjective, Ralph spirals.​

Here's what surprised me: Ralph built a new programming language. Geoffrey is using it right now. The language wasn't in Claude's training data. Ralph created the syntax, wrote the compiler, and learned to program in its own creation. That's not supposed to work.​

The Cost Problem

One developer said they got best results using Ralph for MVP stage only, then switching to pair programming with Claude. They spent "many hours" setting it up. The conclusion: "we haven't reached full potential yet".​

Another admitted the technique requires "continuous tuning". Each project needs its own adjustments. Your signs won't work for my playground.​

And there's the bill. Running Claude in a loop racks up API costs fast. The maximum iterations flag exists partly to prevent you from waking up to a surprise invoice.​

Naming Things

The technique is named after Ralph Wiggum from The Simpsons. You know, the kid who eats paste and says "i'm in danger" while smiling. It's a joke about the loop's relentless, slightly oblivious persistence.​

Developers started calling their implementations things like "Ralph for Claude Code" and posting GitHub repos with the MIT license. The name stuck because it's accurate. Ralph doesn't give up. Ralph doesn't get tired. Ralph doesn't know when to stop unless you tell him exactly when.​

There's something honest about naming your coding assistant after a cartoon character who's not quite right. It sets expectations.

When You Shouldn't Use This

Most greenfield projects don't need Ralph. If you're building something small, the setup time costs more than the savings. If your task needs human judgment at each step, the loop just burns tokens.​

Ralph works when the gap between "not done" and "done" is measurable. When you can write a test that definitively passes or fails. When iteration actually improves output instead of just changing it.

One honest take from a developer who built a full implementation: best results came from limiting autonomous flow to MVP stage. After that, pair programming with Claude beat the loop. The automation only takes you so far.​

The Weird Part

You can chain Ralph loops for multi-phase projects. Phase 1: build data models, output "PHASE1_DONE." Phase 2: build API endpoints, output "PHASE2_DONE." Each phase runs until completion, then triggers the next.​

This works until it doesn't. Claude sometimes adds self-congratulatory notes to markdown files mid-loop. It gets stuck. It loops infinitely on edge cases. It crosses terminal sessions apparently.​

But when it works, it ships code while you sleep. Geoffrey's hackathon proved that. Six repos overnight. Deterministically broken, but broken in ways you can fix the next morning.​

i still think the weirdest part is the programming language. Ralph built something that didn't exist, then learned it. No training data. Just iteration and persistence. That feels different from autocomplete.