¡Por fin llegó lo que pedían! Ralph TUI, Ralph Loop visualizado

Anteriormente escribí un tutorial sobre ralph-loop, y muchos amigos que lo probaron dieron una retroalimentación consistente: Es genial, Claude Code finalmente puede ejecutarse durante mucho tiempo. Pero a veces lo observas y parece que no se mueve, y no puedes evitar preguntarte: "¿Está avanzando o dando vueltas en el mismo lugar?"

Esta es la razón por la que he estado trabajando en ralph-tui recientemente.

ralph-tui no obliga a usar Claude Code, hereda y desarrolla la esencia de ralph loop, y visualiza la ejecución de tareas y el proceso, reduciendo en gran medida la barrera para que los modelos grandes trabajen durante mucho tiempo. Puedes conectar otros agentes, otros modelos, nacionales, baratos, del tipo que puedas ejecutar a largo plazo. Con ralph-tui, para la gente común como nosotros, el significado no es menor que cambiar de una transmisión manual a una automática con control de crucero.

¿Qué es exactamente?

Puedes entender ralph-tui como un "orquestador de bucle de agentes de codificación de IA", solo que no se conforma con "poder ejecutarse", sino que se preocupa más por "que puedas ver, controlar y recuperar".

Su forma básica de trabajo es muy simple:

• Le das un montón de tareas (ya sea de un PRD o de otro sistema de tareas)
• Elige la de mayor prioridad
• Arma el prompt
• Llama al agente para que lo ejecute
• Determina si la tarea se considera completada
• Escribe el estado
• Continúa con la siguiente ronda

Lo importante es que puedes ver todo esto en la terminal, y puedes detenerlo y retomarlo en cualquier momento. Oficialmente también definen su posicionamiento de forma muy directa: un orquestador de bucle de agentes con TUI interactivo, y que soporta TUI / headless / remote.

¿Por qué digo que es más adecuado para "ejecutar a largo plazo"?

El mayor problema de ejecutar un script en bucle no es que no se pueda ejecutar, sino que no sabes dónde se está ejecutando.

Ves que los registros se actualizan rápidamente, y el ventilador también gira felizmente, pero no estás seguro:

• ¿Está corrigiendo repetidamente el mismo error?
• ¿Está modificando constantemente el mismo código y luego volviéndolo a cambiar?
• ¿Ya ha terminado, pero no ha salido?
• ¿Está atascado en una prueba en un bucle infinito?

La solución de ralph-tui es muy "de ingeniería":

• Tiene un concepto de sesión, el estado se guarda en disco (.ralph-tui/session.json)
• Si se cae, se puede recuperar la ejecución (crash recovery)
• Tiene un mecanismo de bloqueo para evitar que abras varias instancias y conviertas el directorio en un desastre
• Incluso se puede ejecutar headless en CI, e incluso remote abrir un listener en el extremo remoto y conectar el TUI local

En una frase: Se parece más a "estar a cargo de un trabajador que sabe escribir código" que a "estar vigilando un script que se comporta de forma errática".

Cómo instalar

El conjunto de ralph-tui es un ecosistema Bun/TypeScript, por lo que la instalación es bastante sencilla. La página oficial también proporciona una página de instalación.

Primero, asegúrate de tener bun en tu máquina:

bun --versionluego instala ralph-tui (aquí doy una instalación típica, consulta la página de instalación oficial para obtener más detalles):

bun add -g ralph-tuiDespués de la instalación, verifica:

ralph-tui --helpSi eres un fan de Node y no quieres tocar bun, también puedes:

npm i -g ralph-tui

No te metas en grandes proyectos todavía, ejecuta un bucle cerrado mínimo

Sugiero que la primera vez que lo uses, no empieces con algo como "refactorizar todo el repo". Solo haz una cosa: haz que ejecute una pequeña tarea aceptable.

Inicialización

Abre cualquier directorio:

mkdir ralph-tui-demo && cd ralph-tui-demo ralph-tui setupEsto entrará en un flujo de asistente interactivo, que básicamente es "instalar ralph-tui en este repositorio", hará lo siguiente:- Detecta automáticamente qué agentes tienes instalados en tu máquina (por ejemplo, Claude Code, OpenCode, etc.)

• Genera un archivo de configuración en el proyecto: .ralph-tui/config.toml
• Instala las skills relacionadas con la generación de PRD/conversión de tareas (para que no tengas que hacerlo manualmente después)

Mi consejo personal: no seas perezoso la primera vez, es imprescindible ejecutar setup.

Generar el PRD del proyecto

Una vez que se ejecuta setup, el siguiente paso es el más importante del tutorial oficial y el más adecuado para escribir una demo para un blog: create-prd.

El comando ralph-tui create-prd --chat iniciará un flujo de diálogo en el que te preguntará sobre los objetivos, las condiciones límite y los criterios de aceptación de los requisitos, como si fuera un Product Manager. Una vez que termine de preguntar, generará dos cosas directamente en el proyecto (esto es lo importante):

• Un archivo markdown de PRD: ./tasks/prd-feature.md
• Un archivo de tareas ejecutable directamente: ./prd.json

En este punto, realmente entras en el "bucle estándar" de ralph-tui:

Requisitos (PRD) → Tareas (prd.json) → Ejecución (run)

Ejecutar (run)

Con prd.json, ejecutar (run) es lo lógico:

ralph-tui run --prd ./prd.json Verás que se inicia la TUI y comienza el bucle: seleccionar tarea → ejecutar → determinar si se ha completado → escribir el estado → finalizar o pasar a la siguiente ronda.

La primera vez que lo ejecutes, te recomiendo encarecidamente que añadas un límite de iteraciones, para mantenerlo bajo control:

ralph-tui run --prd ./prd.json --iterations 5 Después de ejecutarlo, revisa los cambios, ejecuta pruebas y comprueba si el PRD y las tareas cumplen con las expectativas. Una vez que confirmes que esta cadena funciona, puedes liberar las iteraciones y pasar a headless/remote. Este es el ritmo adecuado.

En este punto, básicamente puedes confirmar: este bucle realmente funciona.

¿Cómo elegir el modelo/agente? Hay que ser honesto sobre el ahorro de dinero

Sé que a muchos les preocupa: "¿Puedo evitar usar Claude Code? ¿Puedo usar modelos más baratos?"

La respuesta es: sí.

ralph-tui te permite especificar el agent y el model (hay ejemplos en la documentación oficial de run).

Por ejemplo, usando Claude Opus:

ralph-tui run --prd ./prd.json --agent claude --model opus Pero, sinceramente, yo no usaría Opus para tareas como "completar pruebas, corregir lint", es demasiado caro. Mi costumbre es estratificar:

• Modelos baratos: para ejecutar una gran cantidad de trabajo repetitivo (completar pruebas, completar comentarios, corregir formatos, añadir límites)
• Modelos caros: solo aparecen en puntos clave (ajustes de arquitectura, bugs difíciles, lógica central)

Si eres un desarrollador normal, esta forma de pensar es aún más importante. Porque no tienes el presupuesto de una gran empresa, tienes que mantener los costes bajo control para poder ejecutarlo durante mucho tiempo.

¿Quieres algo aún mejor? Deja que el agent también escriba el PRD

ralph-tui tiene un diseño que me gusta mucho: admite skills (básicamente, un conjunto de comandos externos para el agent).

La forma oficial de instalarlo es con add-skill:

bunx add-skill subsy/ralph-tui --all O instalarlo en un agent específico, por ejemplo, claude-code:

bunx add-skill subsy/ralph-tui -a claude-code -g -y Una vez instalado, puedes usar slash commands en la sesión del agent:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Es como si hubieras instalado un plugin en tu IDE, solo que este plugin es para el agent. Su objetivo es reducir el tiempo de "transporte manual de requisitos", para que los requisitos → tareas → ejecución se parezcan más a una línea de montaje.

¿Cuándo deberías usarlo? ¿Cuándo no deberías usarlo?No me gusta mucho la narrativa de "todo se puede hacer con IA", es fácil que lleve a confusiones. Una herramienta es una herramienta, solo vale la pena en el escenario adecuado.

Escenarios adecuados para usar ralph-tui

Tienes un montón de tareas como estas:

• Complementar pruebas (especialmente en proyectos antiguos)
• Corregir lint / format
• Refactorización en pequeños pasos (converger código repetido)
• Agregar tipos en lote, complementar límites
• Descomponer requisitos y avanzar lentamente según la cola de tareas

Este tipo de trabajo tiene un punto en común: muchas tareas, alta repetitividad, se pueden aceptar, se pueden impulsar de forma iterativa.

Escenarios en los que no es adecuado forzar ralph-tui

Lo que quieres hacer es esto:

• Una gran refactorización única, con criterios de aceptación poco claros
• Requisitos en sí mismos vagos, que dependen de tu conocimiento implícito
• Requiere mucha comunicación/confirmación entre equipos
• Requiere que hagas juicios de valor sobre el producto

En este tipo de tareas, el agent loop solo amplificará el caos.

¿En qué se diferencia de ralph-loop (ralph-claude-code)?

ralph-claude-code se parece más a un "complemento de conducción autónoma para Claude Code": el script lo levanta, ejecuta el bucle, la detección de salida, la limitación de velocidad y el disyuntor te cubren las espaldas. Si quieres "rapidez", es muy rápido.

ralph-tui se parece más a una "consola de control de ingeniería para agent loop": no está soldado a un modelo específico, ni a un sistema de tareas específico. Lo que intenta resolver son problemas de ingeniería como "ejecución a largo plazo, observable, controlable, recuperable, remoto".

Entonces, ¿me preguntas cómo elegir?

• Eres usuario de Claude Code y quieres que se ejecute rápidamente → ralph-claude-code
• Quieres conectar diferentes modelos, quieres ahorrar dinero, quieres administrar el loop como un servicio → ralph-tui

Por último: no dejes que convierta tu repositorio en un laboratorio

Tengo algunas reglas de oro para ejecutar agent loop, las escribo aquí para que las sigas, la probabilidad de que te estrelles será mucho menor:

• Ejecuta en una rama, no te mates en main.
• La primera vez que ejecutes, siempre agrega --iterations, primero confirma en pequeños pasos que no se volverá loco.
• La tarea debe ser aceptable: ya sea que pueda ejecutar pruebas, ejecutar lint o comparar archivos de salida.
• Debes aprender a detenerte: cuando veas que comienza a dar vueltas, es más inteligente pausar que seguir quemando dinero.
• Modelos baratos para trabajo pesado, modelos caros para trabajo crítico: el costo se gestiona, no se ruega.Dirección del proyecto: https://github.com/subsy/ralph-tui