Ralph Loop: cuando 40 caracteres de bash son suficientes

Hay ideas que, cuando las escuchas por primera vez, parecen una broma. Y a los cinco minutos te das cuenta de que la broma eres tú por no haberlas pensado antes. Ralph Loop es una de esas ideas. Se reduce a un solo renglón de bash:

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

Eso es todo. Sin framework, sin orquestador, sin grafos de agentes, sin archivo de configuración en YAML. Un while infinito que le pasa un prompt a Claude Code, una y otra vez, hasta que tú decides parar. Geoffrey Huntley lo popularizó en un post que circuló fuerte a finales de 2025, y la implementación más visible hoy es frankbria/ralph-claude-code, que añade una capa de robustez alrededor del mismo núcleo radical.

GitHub stars · frankbria/ralph-claude-code · MIT · patrón por Geoffrey Huntley

Este post es una evaluación honesta para quienes están pensando si vale la pena instalarlo. Spoiler pragmático: la idea es valiosa, el patrón tiene límites duros, y conviene entender ambos antes de comprometerle una tarde.

Qué hace realmente

El problema que Ralph Loop ataca no es “cómo hago que la IA escriba código”. Ese problema ya lo resolvió Claude Code. El problema es otro, más sutil y más molesto: el context rot.

Cuando dejas a un agente trabajar en una sesión larga, el contexto se ensucia. Se acumulan decisiones viejas, errores parcheados encima de errores, razonamientos contradictorios, y archivos que el modelo ya “recuerda mal”. A las dos horas de conversación, el agente empieza a tomar decisiones peores que las que tomaba al arrancar. No porque el modelo sea malo, sino porque el contexto se degrada.

Ralph resuelve esto por la vía más bruta posible: mata el proceso en cada iteración. Cada vuelta del loop arranca Claude Code desde cero. Lee PROMPT.md, lee IMPLEMENTATION_PLAN.md, elige la tarea más importante según ese plan, la implementa, commitea, actualiza el plan, y muere. El siguiente ciclo vuelve a empezar con la memoria limpia y el estado persistido en el filesystem —que, resulta, es la base de datos más confiable que existe.

El insight es que el estado importante ya vive en el repo: el código, el plan, los commits, los tests. No necesitas memoria del agente; necesitas que el agente lea bien lo que hay. Y leer desde cero cada vez es más barato que arrastrar 80k tokens de conversación previa.

Cómo funciona por dentro

Empecemos por el núcleo, que ya vimos:

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

Desmenucemos:

while :; — loop infinito en bash. : es el no-op que siempre devuelve verdadero.
cat PROMPT.md — lee el prompt del disco. Si editas el archivo a media corrida, la siguiente iteración ya lo usa.
| claude-code — pipea el prompt al CLI de Claude Code. El agente arranca, trabaja, termina, el proceso muere.
done — vuelta y otra vez.

PROMPT.md suele ser corto: “lee IMPLEMENTATION_PLAN.md, escoge la siguiente tarea, hazla, actualiza el plan, commit”. IMPLEMENTATION_PLAN.md es la lista de tareas pendientes, que el propio agente actualiza al terminar cada una. Cuando el plan se vacía, el loop sigue corriendo pero no hace nada útil —y ahí entras tú a apagar el proceso.

La variante de frankbria/ralph-claude-code (8,789 estrellas, 658 forks, Shell) envuelve ese núcleo con lo mínimo que cualquiera termina queriendo después de la tercera corrida:

Rate limiting. Meter un loop infinito contra la API sin freno es una factura que se ve en Slack al día siguiente. El wrapper pausa entre iteraciones.
Circuit breaker. Si el agente falla N veces seguidas —por un error de permisos, un test roto, lo que sea— el loop se detiene en vez de seguir quemando tokens contra un muro.
Exit gates. Condiciones para terminar: “todas las tareas del plan están hechas”, “los tests pasan”, “hay N commits exitosos”. Sin esto, el loop literalmente no termina nunca.
Integración con tmux. Para que puedas mirar lo que está haciendo sin adivinar.
Logging. Historial de iteraciones, qué se intentó, qué se commiteó, qué falló.

Sigue siendo el mismo patrón. Solo que con frenos.

Pros

Simplicidad extrema. No hay abstracciones que entender. Si sabes leer bash, entiendes el sistema completo en un minuto.
Cero lock-in. No depende de ningún framework. Si mañana sale un agente mejor, cambias claude-code por otro CLI y ya.
Contexto fresco garantizado. No hay forma de que el agente arrastre basura cognitiva entre iteraciones. El filesystem es la única memoria.
Commits atómicos naturales. Como cada iteración hace una tarea y muere, los commits salen pequeños por construcción, no por disciplina.
Debuggeable con las manos. ¿Algo raro? Editas PROMPT.md o IMPLEMENTATION_PLAN.md con vim y la siguiente vuelta ya lo agarra. No hay que reiniciar un daemon ni redeployar.
Filosóficamente honesto. Reconoce que el agente no tiene memoria confiable, y en vez de simularla con hacks, usa el único medio persistente que sí lo es: el repo.

Contras

Solo greenfield. Esta es la limitación grande, y Huntley la dice sin rodeos: no metería Ralph en un codebase existente. El patrón asume que el agente puede leer todo lo relevante en cada arranque. En un repo de 200 mil líneas con convenciones locales, eso no escala.
Sin memoria real. Si algo aprendiste en la iteración 12 que importa en la 47, más vale que lo hayas escrito en un archivo. El agente no lo va a recordar.
Sin planning genuino. El “plan” es un markdown que el agente va tachando. Funciona para TODOs lineales; se rompe para dependencias no triviales o tareas que requieren backtracking.
Sin recovery inteligente. Si una tarea falla, la siguiente iteración la reintenta o la ignora, pero no hace debugging profundo. El circuit breaker de frankbria es un paracaídas, no un diagnóstico.
Costo en tokens. Leer el plan completo, el prompt, y los archivos relevantes en cada iteración se suma. En un proyecto grande, cada vuelta arranca con 10-30k tokens solo de contexto inicial.
Requiere supervisión. “Dejar el loop corriendo mientras duermes” suena lindo hasta que en la iteración 200 el agente decide refactorizar tu carpeta de secrets. Nadie en su sano juicio lo deja sin supervisar.

Cuándo sí, cuándo no

Sí si estás haciendo un prototipo de fin de semana, un side project, o un experimento donde la velocidad importa más que la arquitectura. Sí si quieres ver qué tan lejos llega un agente con una lista de tareas bien escrita. Sí para aprender cómo se comporta Claude Code bajo presión iterativa —es un laboratorio excelente.

No para proyecto de cliente. No para un monorepo con convenciones, tests legacy, y tres equipos pisándose los PRs. No para algo que tenga que correr en producción sin que alguien revise cada commit. No como base de un stack serio de AI coding, porque te vas a pasar más tiempo escribiendo PROMPT.md que código, y al final vas a reinventar un framework peor que los que ya existen.

Veredicto

Ralph Loop es un recordatorio de que a veces la herramienta correcta son 40 caracteres de bash. Su valor no está en ser el próximo stack de AI coding —no lo es, ni pretende serlo—. Su valor está en haber articulado con claridad brutal una idea que ahora podemos extraer y aplicar parcialmente en sistemas más sofisticados: el contexto fresco por iteración es una técnica, no un accidente.

La variante de frankbria le pone los cinturones de seguridad que el one-liner no tiene, y por eso tiene casi 9 mil estrellas. Pero cinturones o no, el auto sigue siendo de un solo asiento. Lo usaríamos para un prototipo; no lo pondríamos en la base de nuestro stack. Y eso, creemos, es exactamente como Huntley lo pensó.

TL;DR — Ralph Loop demuestra que un while infinito puede resolver el context rot mejor que un framework, pero solo en greenfield: para codebases reales, la elegancia del one-liner se queda corta.