Ralph loop vs a bounded evidence-producing workflow

If you already run a Ralph loop, you do not need another explanation of what it is — the definitive Ralph loop guide on this site owns the origin, the vocabulary, the variant family, and the limits, with every claim linked to its source. What that page deliberately does not do is weigh the technique against an alternative, because head-to-head judgment is a different job. This page owns that job, and only that job: take one concrete evening of agent work, run it both ways, and compare what actually comes out the other end — the artifacts each system leaves, the losses each one absorbs, and the signals that tell you the trade has flipped for your repository. It is a comparison of two techniques, not of vendors; direct product matchups live under the comparison hub.

The bounded side of the comparison is the workflow this site teaches elsewhere: one agent, one explicitly bounded task, a numeric iteration cap, your review between cycles, and a set of artifacts recorded by machinery rather than by the model's own memory. The starter walkthrough covers how to run it step by step; what follows uses it as the comparison target, not as a tutorial. Every claim below about YYLO's behavior is anchored in the committed README and script sources, verified 2026-08-28; the run anatomy itself is this site's original analysis.

One evening of work, two ways

Comparisons get mushy when they stay abstract, so fix the work first. The task is real and typical: a failing checkout test in an existing repository, plus two smaller fixes behind it. Now walk the same evening through both systems and watch where they diverge.

Before launch. The raw loop's preparation is three files: PROMPT.md describing the mission, a prioritized plan file the agent maintains, and a specs folder for anything that must not drift. Preparation is fast because nothing has to be verifiable by anyone else — the loop is the whole contract. The bounded workflow's preparation is one task whose outcome a command can decide, recorded on a board the runner reads:

./.juno_task/scripts/kanban.sh create --body-file task.md --status todo
./.juno_task/scripts/kanban.sh ready --sort asc

Writing the bounded version takes longer, and that difference is the first honest cost of the comparison: the raw loop starts producing in minutes, while the bounded workflow spends minutes on a statement a gate can referee.

While it runs. The raw side is the famous one-liner:

while :; do cat PROMPT.md | claude-code ; done

Each pass re-reads the same standing prompt, picks what looks most important from the plan file, edits, commits, and restarts as a fresh process — indefinitely, with the loop's only quality gate being whatever backpressure lives inside a pass. The bounded side launches with the cap stated up front:

yy start -b shell -s claude -i 1 -v

One agent session, one iteration, one task. When the process exits, execution is over until a human or a runner decides otherwise. At queue scale the same posture repeats through Run Until Completion, which repeats bounded iterations for as long as the board reports open work, then stops:

./.juno_task/scripts/run_until_completion.sh -s claude -i 1 -v

When it stops. Here the two systems are opposites. The raw loop has no stop semantics of its own; the README's own comparison table describes its stopping as "Ctrl+C (guesswork)" — the operator interrupts when the stream looks baked, and the originator's scale admits a third outcome: baked with unspecified latent behaviors. The bounded workflow stops at the cap by construction, and the queue-level variant adds a semantic stop plus a staleness tripwire: three consecutive iterations with no task change (the default, adjustable) trigger the ON_STALE hook and an exit, so a loop that is merely spinning cannot convert budget into the appearance of work. Interruption is a designed stop rather than a loss where the runner documents it: in yylo loop runs, an operator signal stops the active child and nothing launches after it.

The morning after. The raw loop greets you with an unbounded diff: some number of unreviewed commits, a plan file the same non-deterministic process edited, and a terminal whose scrollback is the only narrative of what happened. Your decision — keep, rescue, or git reset --hard — is a judgment call made on that evidence, every time. The bounded workflow greets you with a review queue: each cycle recorded its response on the task, its commit on the branch, a replayable log on disk, and a session id you can continue exactly. The committed CLI config starts every agent run at one iteration unless a higher cap is passed, so nothing ran past a bound you did not choose.

What each run produces

Set the two artifact inventories side by side and the structural difference is visible in one glance:

• The raw loop produces history. Commits accumulate pass by pass — the technique's git discipline is real — and the plan file and prompt file evolve with them. What it does not produce is review: every commit lands ahead of any human read, and the record of why a pass did what it did lives in scrollback, which the next pass overwrites.
• The bounded workflow produces reviewable units. Per cycle: the response in the agent's own words, the commit in the diff, the run log replayable without terminal history, the session id as the handle for continuing that exact conversation. Per queue: board state a script reads, and completion that carries commit evidence on the task itself.
• At workflow scale, the record hardens further. Multi-step runs write one run directory holding per-step streams, a manifest of statuses and session ids, and hash-bound checkpoint contracts, so an interrupted run can be recovered at the exact step the evidence marks invalid — the auditable-workflows guide owns that contract end to end.

The pattern underneath the inventory: the raw loop's outputs are optimized for the next pass (the loop reads them, the loop benefits), while the bounded workflow's outputs are optimized for the next human (you read them, you decide). Neither is free — the raw loop's artifacts cost nothing extra to produce and everything to audit; the bounded workflow's artifacts cost ceremony to produce and almost nothing to audit.

What each side loses

A comparison that only prices one side is marketing. Both systems fail, and the losses differ in kind.

The raw loop's losses are the documented ones, and they compound quietly. Stopping is guesswork, so you overcook (features nobody asked for) or undercook (half-fixed bugs). State lives in markdown the same model edits, so the process that fails is also the record keeper — the README's Ralph assessment names this class "Fragile state". Changes blend together with no task-level traceability, so reconstructing which pass broke something means bisecting commits against a plan file that has since moved. And some mornings you wake to a tree that does not compile and a rescue decision with no evidence to lean on. The limits section of the definitive guide quotes the originator and longest-running practitioners on each of these; the comparison-level summary is that every raw-loop loss is a review-or-recovery cost paid later, at night, unattended.

The bounded workflow's losses are smaller per incident but certain and up front. A one-iteration cap throttles single-prompt bulk builds: a greenfield job that needs two hundred passes on one prompt either gets its cap raised deliberately or must be decomposed into verifiable tasks first. The queue runner can still spend a night on many bounded iterations, but only after that decomposition is paid. And where review sits between cycles, the system's throughput is your reading speed; a review backlog behaves exactly like the raw loop's commit backlog with extra steps. Task-writing overhead is real: a bounded task that names no verifiable outcome produces a loop that stops politely at the wrong finish line. And bounds cannot rescue a bad task statement, a wrong model choice, or a gate that passes for the wrong reason — they only make those failures cheap to see. Every one of these costs is paid in daylight, on purpose, before anything runs unattended; that is the whole trade.

Migration triggers

Neither system dominates; the trade flips with the work. These are the observed signals that the bounded side has started paying for itself — each one is a trigger, not a verdict, and the list assumes you are already running the raw loop honestly:

• Review debt compounds. Unreviewed commits accumulate faster than you read them, and your stop heuristic has quietly drifted from looks-baked to hope-it-is-baked.
• Attribution breaks. You can no longer tie a breakage to the pass that caused it without bisecting commits against scrollback that no longer exists.
• A fragile-state event landed. The plan or task file came back corrupted, duplicated, or drifted from reality, and the loop kept editing around it.
• A morning ended in a reset. The most recent unattended run concluded with git reset --hard rather than a rescue, and the work it represented is gone.
• The target changed underneath you. Work moved from greenfield scaffolding to an existing codebase with a merge surface, where the technique's own originator draws his boundary.
• Signs stopped working. The same guardrail line has been added to the prompt repeatedly and the same failure keeps returning.
• Someone asked for the record. An audit, a teammate, or a compliance need requires connecting each change to the intent that produced it and the evidence that validated it.

One trigger means tune the loop. Two or more firing together means the bounded workflow's fixed costs are now cheaper than the raw loop's compounding ones — that is the moment to stop re-signing the prompt and start bounding one task as a pilot. The step-by-step path from a prompt file to a full auditable pipeline is a separate guide of its own; the decision that starts it is the one this page owes you.

When the raw loop still wins

Saying so keeps this comparison honest: for greenfield bulk generation — a spec stack, a scratch repository, a senior operator watching the stream — the raw loop is not the loser of this comparison. Its whole value is throughput — passes per day — and interleaving human review between every cycle would throttle exactly the property you launched it for. The originator's own framing cuts both ways — "the technique is deterministically bad in an undeterministic world" — the technique is dependable while its passes are not, which is a trade worth making precisely when generation throughput dominates and a human is present to be the stop condition. The bounded workflow wins the mirror-image regime: existing code, shared state, unattended time, and any stakeholder who will later ask what changed and why. Choose by the properties of the work in front of you, not by which technique is fashionable.

Run this comparison on your own repository

The anatomy above generalizes, and you can re-derive it anywhere in an afternoon. Pick your next real task and write down, before launching either system, the four things this page compared: what the run may change, what stops it, what it must leave behind, and who reads that residue. Then run the raw loop for an evening and a bounded task for another, and hold the two mornings side by side. The artifact inventory is usually decisive on its own: whichever morning lets you answer the three audit questions — what changed, why, and what proved it — from files rather than from memory is the system your repository can afford to leave running. The failure-design guide turns that discipline into a pre-launch review; the ledger's task-truth guide is the durable-state half; and the dated evidence for YYLO's side of this comparison sits under the hub this page's action points to.