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

Antes escribí un tutorial sobre ralph-loop, y muchos amigos que lo probaron me dieron la misma respuesta: 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 últimamente.

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, lo que reduce 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 bucles de agentes de codificación de IA", solo que no se conforma con "poder ejecutarse", sino que le importa más "que puedas ver, controlar y restaurar".

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 escribieron su posicionamiento de manera muy directa: un orquestador de bucles de agentes con TUI interactivo, y que admite TUI / headless / remote.

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

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

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

• ¿Está repitiendo la corrección del mismo error?
• ¿Está modificando la misma sección de código una y otra vez?
• ¿Ya terminó, pero no salió?
• ¿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 el disco (.ralph-tui/session.json)
• Se puede restaurar la ejecución si falla (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 el TUI local se conecta a él

En una palabra: 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

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

Primero, confirma que tienes bun en tu máquina:

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

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

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

npm i -g ralph-tui

No hagas nada grande todavía, ejecuta un bucle cerrado mínimo

Sugiero que la primera vez que lo uses, no hagas nada como "reestructurar 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 setup Esto 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 (como 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 vago la primera vez, es imprescindible ejecutar setup.

Generar el PRD del proyecto

Una vez ejecutado 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 haya terminado de preguntar, generará dos cosas directamente en el proyecto (y esto es lo importante):

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

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

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

Puesta en marcha (run)

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

ralph-tui run --prd ./prd.json Verás que se inicia la TUI y comienza el bucle: seleccionar tarea → ejecutar → determinar si está completa → 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 Una vez que termine, revisa los cambios, ejecuta las pruebas y comprueba si el PRD y las tareas cumplen con las expectativas. Una vez que hayas confirmado que esta cadena funciona, puedes liberar las iteraciones y pasar a headless/remote, ese 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 lo que más preocupa a mucha gente es: "¿Puedo evitar usar Claude Code? ¿Puedo usar modelos más baratos?"

La respuesta es: sí.

ralph-tui te permite especificar el agente y el modelo (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 "añadir pruebas, corregir lint", es demasiado caro. Mi costumbre es estratificar:

• Modelos baratos: para ejecutar una gran cantidad de trabajo repetitivo (añadir pruebas, añadir comentarios, corregir el formato, añadir límites)
• Modelos caros: solo se utilizan en puntos clave (ajustes de arquitectura, errores 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 agente también escriba el PRD

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

La forma oficial de instalarlo es con add-skill:

bunx add-skill subsy/ralph-tui --all O instalarlo en un agente específico, como 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 agente:

/ralph-tui-prd /ralph-tui-create-json /ralph-tui-create-beads Esto es como instalar un plugin en tu IDE, solo que este plugin es para el agente. 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 equívocos. 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 proyectos antiguos)
• Corregir lint / format
• Refactorización en pequeños pasos (converger código repetido)
• Añadir 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 puede aceptar, se puede avanzar de forma iterativa.

Escenarios en los que no es adecuado forzar ralph-tui

Lo que quieres hacer es esto:

• Refactorización grande única, criterios de aceptación poco claros
• Requisitos en sí mismos ambiguos, que dependen de tu conocimiento implícito
• Necesitas mucha comunicación/confirmación entre equipos
• Necesitas hacer juicios de producto

En este tipo de tareas, el bucle del agente 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 y se encarga de la detección de salida, la limitación de velocidad y el disyuntor. Si quieres "rapidez", es muy rápido.

ralph-tui se parece más a una "consola de control de ingeniería para el bucle del agente": 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 gestionar el bucle como un servicio → ralph-tui

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

Yo mismo tengo algunas reglas de oro para ejecutar el bucle del agente, las escribo aquí para que las sigas y la probabilidad de que te salga mal sea mucho menor:

• Ejecuta en una rama, no te mates en main.
• La primera vez que ejecutes, añade --iterations, primero confirma en pequeños pasos que no se va a volver loco.
• La tarea debe ser aceptable: ya sea que pueda ejecutar pruebas, ejecutar lint o comparar archivos de salida.
• Debes aprender a parar: ver que empieza a dar vueltas es más inteligente que seguir quemando dinero.
• Los modelos baratos hacen el trabajo sucio, los modelos caros hacen el trabajo clave: el coste se gestiona, no se reza para que salga bien.Dirección del proyecto: https://github.com/subsy/ralph-tui