Si has usado un agente de programación con IA durante más de unas pocas horas, conoces el “muro”: el agente avanza de forma visible, luego se estanca… y terminas parcheando y finalizando el trabajo tú mismo.
Como suele pasar entre ingenieros de IA, surgió un patrón para resolver ese problema: simplemente poner al agente en un loop contra comprobaciones externas hasta que el trabajo realmente pase.
El enfoque se popularizó lo suficiente como para tener nombre propio: Ralph Wiggum.
via dev.to
Y el meme se quedó porque el patrón funciona. Para finales de 2025, Anthropic lo había formalizado como un plugin oficial de Claude Code.
Ralph representa un cambio en la forma en que los desarrolladores usan las herramientas existentes. En lugar de tratar a los sistemas de IA como asistentes interactivos, se ejecutan como procesos de larga duración, guiados por tests, linters y condiciones de parada explícitas.
Así que esta guía corta es la versión práctica. Veremos qué es realmente Ralph, por qué funciona, cómo se difundió y qué cambió cuando se convirtió en un producto.
¿Qué Es “Ralph”, en Realidad?
En esencia, esto es lo que es Ralph: ejecutar un agente en un loop, comprobar el resultado contra algo que no puede mentir —como un test, un linter o un verificador de tipos— y seguir iterando hasta que pase.
Eso es todo.
El ejemplo original que compartió Geoffrey Huntley en julio de 2025 era intencionalmente directo:
The original example Geoffrey Huntley shared in July 2025 was intentionally blunt:
while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; doneLas variantes de Claude Code siguen la misma forma, solo que con más barandillas de seguridad. Pero el principio no cambia: alimentar repetidamente al agente con un prompt fijado hasta que la realidad externa diga que ya terminaste.
El loop en sí es casi irrelevante; lo que importa es el contrato:
- El estado vive en el repositorio: archivos, diffs, logs, historial de git; todo lo que sea duradero va aquí.
- La finalización vive fuera del modelo: tests, linters, verificadores de tipos; el agente no decide cuándo ha terminado, lo decide el harness.
- El agente es reemplazable: es un trabajador que se invoca repetidamente hasta que pasa el control; si hoy es lento o torpe, mañana se cambia por uno más rápido.
Visto así, Ralph se convierte en un principio de diseño: deja de pedirle al modelo que sepa cuándo ha terminado. Deja de esperar que recuerde restricciones a través de reinicios de contexto.
En su lugar, construye el sistema de forma que el modelo no pueda fallar de esas maneras.
¿Por Qué el Loop Se Sostiene?
Por varias razones:
1. Las Ventanas de Contexto se Comportan Como Buffers
Huntley suele explicar las ventanas de contexto en términos de bajo nivel:
“Piensa como un ingeniero de C o C++. Las ventanas de contexto son arrays.”
Tienen un tamaño fijo; se deslizan; sobrescriben; olvidan.
Las sesiones de larga duración asumen una continuidad que no existe, así que tratar el buffer como memoria duradera conduce a deriva, restricciones incumplidas y comportamientos inconsistentes.
Ralph acepta la realidad del sistema. En lugar de fingir que la ventana de contexto es estable, la trata como algo desechable.
El espacio de trabajo temporal del agente se reinicia entre iteraciones, mientras que el estado duradero persiste en disco. El repositorio va acumulando la verdad a lo largo de las ejecuciones. Esto hace que reiniciar el agente sea algo rutinario en lugar de un desperdicio: cada loop empieza desde cero, pero se apoya en lo que realmente persistió.
2. Las Comprobaciones Externas Superan al Razonamiento Interno
Muchos frameworks de agentes responden al fallo añadiendo estructura dentro del modelo: planificadores, resúmenes, estado interno y loop de reflexión.
Ralph mantiene la inteligencia fuera del agente. Se apoya en:
- Una especificación fijada que no deriva
- Evidencia concreta de la última ejecución
- Una compuerta determinista que evalúa el éxito
El agente no decide cuándo el trabajo está terminado: lo hace el harness.
Por eso Ralph sobresale en trabajo mecánico: refactors, migraciones, limpieza, tareas de conformidad… En cualquier lugar donde el éxito pueda medirse con un script en lugar de con juicio humano, la iteración se vuelve fiable.
El modelo no puede escabullirse de los requisitos porque los requisitos viven fuera de su razonamiento.
3. La Compactación Erosiona las Restricciones
Una crítica recurrente de Huntley apunta a la resumización y la compactación.
Cuando un sistema le pide al modelo que decida qué es lo suficientemente importante como para conservarlo, se pierde información: las restricciones se suavizan, los casos límite desaparecen y los “pins” se caen.
Ralph evita esto manteniendo las entradas de forma literal:
- Las especificaciones se mantienen verbatim en lugar de resumirse
- La salida de fallo permanece cruda y sin filtrar
- La curaduría de memoria nunca se traslada al modelo
El harness preserva la fidelidad; el agente opera dentro de él, limitado por lo que realmente está ahí, y no por lo que el modelo cree que debería estar ahí.
Entonces, ¿Cómo se Difundió la Idea?
La línea de tiempo es bastante comprimida.
- 19 de junio de 2025: En un meetup en San Francisco con unas 15 personas hablando sobre agentic coding, Huntley hace una demo de Ralph, de Cursed (el lenguaje de programación que Ralph está construyendo) y transmite en vivo programación autónoma durante la noche mientras él duerme en Australia. En la sala surge una conversación inquietante sobre lo fácil que es copiar entre el 80 % y el 90 % de un SaaS y sobre cuántos tipos de trabajo están a punto de desaparecer por completo.
- Julio de 2025: Huntley publica el post original del blog con la estructura básica del loop en bash. El artículo incluye un prompt de ejemplo ligero y una petición: «probablemente podrías encontrar el repo de cursed lang en GitHub si lo buscaras, pero por favor no lo compartas todavía».
- Agosto de 2025: Tiene lugar el YC agents hackathon: los equipos ejecutan Claude Code en loop continuos. El resultado son 6 repositorios entregados de la noche a la mañana. Dexter Horthy ejecuta un Ralph loop experimental para un refactor de una base de código en React. En 6 horas, desarrolla un plan de refactor completo y lo ejecuta.
- Septiembre de 2025: Huntley lanza oficialmente Cursed Lang, el lenguaje de programación que construyó Ralph. Existe en tres implementaciones (C, Rust y Zig), tiene una librería estándar y un compilador de segunda etapa escrito en el propio Cursed.
Octubre de 2025: Dexter presenta Ralph en Claude Code Anonymous en San Francisco. La pregunta del público es: «Entonces, ¿recomiendas esto?». Su respuesta: «Las cosas tontas pueden funcionar sorprendentemente bien. ¿Qué podríamos esperar de una versión inteligente?». - Diciembre de 2025: Anthropic lanza un plugin oficial de Ralph Wiggum. El plugin toma el loop en bash de Huntley y lo formaliza con Stop Hooks y datos de fallo estructurados.
- Enero de 2026: Huntley y Horthy hacen un deep dive en YouTube comparando la implementación original de Ralph con loop bash y la implementación de Anthropic basada en stop hooks.
Ralph con Bash Loop vs. Ralph Como Plugin
El Ralph original es un loop bash de 5 líneas. Haces cat de un archivo de prompt, lo canalizas a Claude, compruebas si la salida pasa tu test y repites el loop hasta que lo hace. Todo vive en disco, todo es visible. Si algo se rompe, puedes ver exactamente por qué.
El plugin de Anthropic invierte ese modelo: en lugar de ejecutar el loop desde fuera, instala un Stop Hook dentro de tu sesión de Claude. Cuando Claude intenta salir, el hook lo intercepta, comprueba tus condiciones de finalización y vuelve a introducir el mismo prompt si todavía queda trabajo. Los archivos que Claude modificó siguen ahí.
El historial de git sigue ahí, pero la mecánica del harness ahora es opaca: queda oculta en un archivo de estado en markdown, es sensible a permisos y es fácil de romper si no sabes exactamente lo que estás haciendo.
Este es el clásico trade-off de la abstracción.
El plugin reduce el coste de adopción. No necesitas escribir bash ni pensar en loops. Pero a medida que el mecanismo se oculta, el insight original se vuelve más fácil de perder.
La versión con loop bash te obliga a diseñar el harness. La versión con plugin te permite saltarte ese paso, lo cual está bien… hasta que te topas con un caso límite y no puedes ver qué está pasando realmente.
Dexter Horthy lo probó y descubrió que falla de formas crípticas a menos que uses –dangerously-skip-permissions. El plugin instala hooks en lugares extraños, usa archivos de estado opacos y, si borras el archivo markdown antes de detenerlo, rompes Claude en ese repositorio hasta que desactivas el plugin por completo.
Entonces, ¿cuál es la lección? Ambos funcionan, pero funcionan por razones distintas. El loop bash funciona porque es tonto y transparente. El plugin funciona cuando la abstracción no oculta algo crítico.
¿Qué Aprendes al Ejecutarlo?
Ralph asume distancia entre el humano y el agente. No te sientas dentro de la sesión a guiarlo. En su lugar, lo pones a correr, te vas, inspeccionas los artefactos cuando termina y ajustas las restricciones para la siguiente iteración.
La interacción ocurre a nivel del harness —el prompt, los tests, las condiciones de parada—, no dentro de la conversación.
Con el tiempo, aparece un patrón: la mayoría de los fallos no son fallos del modelo, sino fallos del harness.
La especificación era vaga, el test demasiado amplio o la condición de finalización no describía realmente qué significa “terminado”.
Cuando ves esto unas cuantas veces, tu instinto cambia. Dejas de preguntarte “¿cómo hago a Claude más inteligente?” y empiezas a preguntarte “¿cómo hago las restricciones más estrictas?”.
Aquí es donde las especificaciones se vuelven críticas.
Especificaciones Como Superficies de Control
Huntley replantea las especificaciones no como documentación, sino como entradas de control fijas. Las produces mediante conversación con Claude, las editas deliberadamente hasta que son precisas y luego las fijas. Una vez fijadas, no cambian durante todo el loop.
Esto importa porque las especificaciones hacen tres cosas al mismo tiempo:
- Limitan lo que el agente puede inventar: sin una especificación estricta, Claude añadirá capas defensivas, abstracciones o funcionalidades que nunca pediste, expandiendo el alcance en cada iteración.
- Anclan la búsqueda y la recuperación: para que el agente no alucine nuevos requisitos.
- Estabilizan el comportamiento entre ejecuciones: cada iteración resuelve el mismo problema, no una interpretación ligeramente distinta.
Si tu especificación es vaga sobre qué significa “terminado”, el agente la interpretará de forma diferente en cada loop. El resultado es deriva, scope creep e iteraciones que se contradicen entre sí.
¿Cómo Ejecutar el Loop de Forma Responsable?
Una configuración mínima de Ralph suele verse así:
MAX_ITERS=30for i in $(seq 1 $MAX_ITERS); do cat PROMPT.md | claude if ./ci.sh; then exit 0; fidoneexit 1La mecánica del loop importa mucho menos que las reglas que lo rodean:
- Mantén la especificación inmutable; no la ajustes a mitad del loop según lo que esté haciendo Claude.
- Codifica la finalización como comprobaciones ejecutables.
- Impón límites de iteración y de tiempo para que el loop no se ejecute indefinidamente y consuma todo tu presupuesto de tokens.
- Conserva logs y diffs para poder inspeccionar qué salió mal si ocurre.
Además, la práctica operativa ha revelado algunas heurísticas importantes:
- Prefiere diffs pequeños y regulares en lugar de grandes refactors, porque los cambios grandes acumulan errores y son más difíciles de depurar.
- Vuelve a ejecutar sobre la rama main actual en lugar de hacer rebase, porque los conflictos de merge desperdician iteraciones.
- Evita usar Ralph para trabajo exploratorio, porque si no tienes tests de aceptación claros, solo obtendrás un loop caótico que inventa cosas que no pediste.
La restricción es la funcionalidad.
El Loop es la Lección
A medida que Ralph ganó tracción, surgieron variaciones. Algunos equipos construyeron loops externos estructurados alrededor de agentes con tool-calling. Otros añadieron componentes verificadores separados: un modelo distinto que revisa la salida del “trabajador” antes de que el loop decida salir. Estas extensiones funcionan, sí, pero solo si respetan el insight original.
La regla es simple: la verificación debe seguir siendo determinista, y los resúmenes nunca deben reemplazar a las entradas primarias.
- Si añades un verificador, debería comprobar cosas concretas: que los tests pasen, que el linter termine sin errores, que el git diff coincida con lo esperado.
- Si añades loops externos estructurados, estos deberían seguir viendo la salida y los logs en crudo, no un resumen “limpio” de lo que salió mal.
El argumento central de Huntley es que el desarrollo de software como profesión está, en la práctica, muerto; pero la ingeniería de software —la práctica de construir sistemas bien— está más viva que nunca.
