A team at the Y Combinator Agents hackathon recently ran an experiment. They spun up a few GCP instances, started Claude Code in infinite loops, and went to bed after 2 AM. When they woke up, they had 1,100+ commits across six repositories, including a near-complete port of Browser Use from Python to TypeScript. Total cost: a little under $800. About $10.50 per hour per agent.
The Technique
A Ralph Loop —named after the Simpsons character, because sometimes you just have to let it rip — is a technique created by developer Geoffrey Huntley. In its purest form:
while :; do cat PROMPT.md | claude-code; done
Run an AI coding agent, let it finish, start it again with fresh context. Repeat until the work is done. As Huntley puts it: "Ralph can replace the majority of outsourcing at most companies for greenfield projects. It has defects, but these are identifiable and resolvable through various styles of prompts." Or, more provocatively: "That's the beauty of Ralph—the technique is deterministically bad in an undeterministic world."
One engineer Huntley taught the technique to delivered a $50,000 contract as a tested MVP for $297 in compute. But that number almost certainly excludes prompt iteration, debugging cycles, human review, and architectural decisions made before the loop ran. The compute got cheaper. The skill ceiling moved—it didn't vanish.
Why Fresh Context Matters
When you interact with an AI coding tool, every exchange appends to a growing token sequence. The model processes your entire history, not just the latest message. As context grows, attention dilutes across more information. Eventually you hit limits, and the standard solution—summarizing the conversation to compress it—is lossy. Critical instructions get abstracted away. The model's frame of reference degrades incrementally—what Huntley calls losing "the pin."
As Theo from t3.gg explains: imagine a brilliant engineer whose brain gets wiped whenever they do too much work at once. They can build anything, but once they've written too many lines of code, their memory resets. The techniques you'd develop to catch them back up quickly—that's essentially what Ralph loop engineering is about.
Ralph sidesteps compaction by treating each iteration as a fresh start. Memory persists not in the model's context, but in the filesystem: git commits, progress files, task lists. Each iteration reads the current state, decides what to do, does one thing well, and updates the state for the next iteration.
This isn't novel. It's a rediscovery: stateless workers plus durable state beats clever in-memory abstractions. Unix knew this. Distributed systems have known it for decades. LLM tooling is catching up.
The Architecture Most People Get Wrong
When Ryan Carson put together a step-by-step guide for Ralph loops, Huntley responded: "This isn't it." The Claude Code plugin many developers use? Also not a proper Ralph loop. The critical distinction is control hierarchy. In a proper Ralph loop, the bash script is the outer layer controlling the AI agent. It can terminate and restart with fresh context whenever needed. The source of truth is the filesystem—the PRD, the progress file, the git history—not the agent's internal state.
The plugin inverts this: the agent controls the loop. It stays in one session, hits context limits, compacts, loses information, and continues degraded. You've prevented the agent from stopping, but you haven't solved context rot—you've hidden it. Think of it as nested boxes. Ralph should be on the outside, controlling when the agent lives and dies. When the agent controls Ralph, you lose the core benefit.
This is the same mistake developers have made with long-running JVMs versus short-lived processes, stateful CI jobs versus idempotent pipelines. If your agent owns its own lifecycle, you've lost observability and determinism.
What Happens When You Let It Run
The YC hackathon team's field report provides the clearest picture of Ralph in practice. They started with simple prompts. For porting Browser Use to TypeScript:
Your job is to port browser-use monorepo (Python) to better-use (Typescript)
and maintain the repository.
Make a commit and push your changes after every single file edit.
Keep track of your current status in browser-use-ts/agent/TODO.md
That's 42 words. When they tried "improving" it with Claude's help, it ballooned to 1,500 words. The agent immediately got slower and dumber. Back to 103 words, back on track.Several behaviors surprised the team:
Early stopping: Agents wrote tests, kept to original instructions, and mostly declared ports "done" on their own. One agent used pkill to terminate itself after detecting it was stuck in an infinite loop.
Overachieving: After finishing the initial port, the AI SDK Python agent started adding features—Flask and FastAPI integrations with no JavaScript counterpart, plus support for multiple schema validators.
Graceful degradation: The agents delivered roughly 90% completion, requiring interactive sessions to finish. But 90% overnight while sleeping is transformational—for the right class of problems.
The Real Lesson Isn't About Parallelism
Huntley frames Ralph's failures as tuning signals: "Every time Ralph has taken a wrong direction, I haven't blamed the tools; instead, I've looked inside. Each time Ralph does something bad, Ralph gets tuned—like a guitar."
What's actually happening is more precise: the agent greedily optimizes under partial observability, biased toward local optima given incomplete state. That framing matters because it predicts failure modes—architectural dead ends, semantic shifts requiring global context, refactors that touch everything.
Ralph is often cited for rejecting parallelism—running tasks linearly rather than distributing them across multiple agents. Traditional software engineering breaks projects into parallel tasks, but this introduces complexity: conflicts, dependencies, coordination overhead. And if your agents lose memory constantly, an agent assigned to tasks six, seven, and eight will keep rediscovering that task seven depends on task two—every single time.
But linear execution isn't the magic. Idempotence is.
What helps is that each iteration is restartable, each task independently verifiable, with no assumption of shared in-agent memory. You could parallelize Ralph-style agents safely—if you treated them like cron jobs with conflict detection, not collaborators with shared mental state.
The danger is concluding "parallelism is bad" when the real lesson is: parallelism without strong state contracts is bad.That's a distributed systems insight, not an LLM-specific one.
Where Ralph Breaks Down
The technique works—but intellectual honesty requires acknowledging its limits.
Implicit correctness domains: Ralph works best where tests exist or are cheap to add. In finance, infrastructure, or compilers—where correctness is implicit—the technique becomes expensive. Security regressions, license contamination, subtle semantic bugs, and cross-module invariants aren't caught by "does it typecheck and pass tests."
Creation versus maintenance: There's a meaningful difference between porting Browser Use and maintaining it for two years. Fresh-context loops excel at making progress. They're weaker at preserving architectural intent, respecting undocumented constraints, and avoiding long-term entropy.
Hidden labor: You're trading interactive coding for specification labor, prompt design, task decomposition, failure analysis, repo hygiene, and verification infrastructure. The $50k-for-$297 anecdote reflects compute costs, not total effort. Ralph externalizes cost—it doesn't eliminate it.
This doesn't invalidate the technique. It bounds the domain.
The Counterpoint: Do You Even Need This?
Peter Steinberger, one of the most prolific agentic coders in the community—his GitHub shows individual days with 500+ commits—takes a different approach using OpenAI's newer Codex-backed models. His observation: Codex will silently read files for 10-15 minutes before writing code. That patience increases the chance it fixes the right thing. Claude's Opus is more eager—great for small edits, but prone to missing context. These differences likely reflect tooling defaults, token budget allocation, and training bias as much as "model personality." Workflow shapes model behavior. Before treating this as model selection advice, ask: is this architectural, or just ergonomics?
Steinberger's workflow involves no elaborate looping. He queues tasks, lets the model work, and trusts verification rather than reviewing every line. His advice: "If your reason for using Ralph is just to complete longer tasks, you probably don't need it.". The goal of Ralph isn't solving the problem that agents stop too early. It's forcing explicit state management.
Practical Implementation
Ryan Carson's repo provides a starting point. The YC team also built RepoMirror for repo porting:
npx repomirror init \
--source-dir ./browser-use \
--target-dir ./browser-use-zig \
--instructions "convert browser use to Zig"
Key files in any Ralph setup:
- ralph.sh: Bash loop spawning fresh agent instances
- prompt.md: Instructions per instance (100 words beats 1,500)
- prd.json or TODO.md: Task tracking with completion status
- progress.txt or agent/ directory: Accumulated learnings
Critical success factors:
Small, independently verifiable tasks: Each should complete in one context window and be testable in isolation. "Add a database column" is right-sized. "Build the entire dashboard" is not.
Commit after every edit: Granular checkpoints create persistent memory and make iterations restartable. This is what enables idempotence.
Strong feedback loops: Tests, type checks, CI. Without verification, broken code compounds across iterations.
Scratchpad directories: Let the agent store long-term plans externally. This becomes durable state that survives context wipes.
The Real Takeaway
Ralph nails the most important shift in LLM-assisted development:
Productivity isn't about smarter models—it's about better boundaries.
The technique is valuable not because it's a bash loop, but because it forces developers to treat models as disposable workers, move memory into inspectable artifacts, and design workflows that survive amnesia. That's not magic. That's engineering discipline applied to a new substrate. LLMs are forcing us to re-learn old lessons about state, control, and boundaries—faster than we're comfortable with. If Ralph pushes developers to rethink context as a resource to manage rather than a convenience to accumulate, it's doing real work. The technique matters less than the mental model it instills. Just don't mistake the loop for the leverage.
For more on agentic AI architectures, see our coverage of the agentic loop explained, sandboxing autonomous agents, and when AI agents go rogue.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.
