🧮 Bucles × Colas

En julio, el ingeniero Geoffrey Huntley publicó un artículo (14/jul) que se volvió viral en la comunidad: el Ralph loop. La idea es deliciosamente sencilla: escribes un bucle while en bash que llama a Claude Code pasando el el mismo prompt una y otra vez. El agente termina una pasada, el loop se reinicia y recibe la instrucción otra vez. Funciona así, en AFK, sin que estés frente al teclado.

El nombre "Ralph" es una broma interna (una referencia al personaje Ralph Wiggum, de Los Simpson, que hace lo simple sin pensar demasiado) — y parte de la gracia está justamente en esto: brutalmente simple y aun así eficaz. ¿Por qué funciona? Porque cada nueva pasada del agente empieza con contexto nuevo y vuelve a leer el estado del codebase y da un paso más. Es la forma más directa de sacarte de la ecuación. El error común aquí es creer que "loop = magia autónoma": el loop solo repite; quien sigue haciendo el trabajo es el agente, y depende del prompt y del harness que tiene detrás.

Aquí entra la postura de Pocock, y es un cambio de perspectiva importante. Reconoce que el Ralph loop es ingenioso, pero dice claramente: "no necesito ejecutarlo en bucle: solo necesito que el agente AFK tome una tarea específica y la haga." En otras palabras, lo que de verdad lo desbloquea no es la repetición infinita; é o AFK (el agente trabajando sin que estés presente). El loop es solo una forma — y no la mejor — de lograrlo.

¿Por qué? Porque un único loop que intenta «hacerlo todo» no coincide con la forma en que trabajan los equipos reales. Un equipo no tiene un robot girando para siempre; tiene un backlog de tareas claras, cada una con principio, desarrollo y final. La repetición a ciegas gasta tokens, pierde el foco y dificulta decir "esto ya está listo". La respuesta correcta, según Pocock, es cambiar el verbo: en vez de "hacer un bucle", piensa en "tomar la siguiente tarea de la cola". La misma autonomía, mucho más control y claridad. Un error común es confundir «ejecutarse por su cuenta» (bueno: AFK) con «dar vueltas en círculos» (rara vez es lo que quieres).

La frase central de Pocock es: "yo pienso en esto principalmente como colas, no loops." Una cola es simplemente tu backlog de tareas. Y da el ejemplo concreto del Sand Castle (su herramienta): él mira las issues, hace el triaje (¿es trivial? ¿es posible?), agrega el label agent:implement y el agente lo implementa mediante GitHub Actions (visto en el módulo 4.3).

Y entonces viene la definición que organiza todo: "todo el desarrollo es solo una" cola de tareas: los PM agregan tareas a la cola y tú las completas; múltiples nodos (devs) toman elementos de la cola." Fíjate cómo esto describe a cualquier equipo de software del mundo, sin ninguna IA involucrada. El PM alimenta la cola; los desarrolladores consumen. La idea de Pocock es que los «nodos» ahora pueden ser agentes en lugar de (o además de) humanos. No cambias el modelo mental del equipo: solo cambias quién toma los elementos. Por eso la fila encaja de forma natural, y el loop único que «lo hace todo» no se ajusta a cómo trabajan los equipos.

Antes de que un elemento se convierta en trabajo, pasa por clasificación inicial. En el flujo de Sand Castle, Pocock revisa cada issue y responde dos preguntas: ¿es trivial? e ¿es posible? — y esto ya se puede hacer en AFK. Hay una issue real (#795 en su ejemplo), que va cambiando de etiqueta: agent:explore → agent:in-progress, mientras el bot github-actions publica un comentario de "Triage" con un TL;DR y una estimación de Difficulty (dificultad).

¿Por qué esto importa? Porque la clasificación te da alcance — y el alcance es lo que separa una tarea «abordable» de un pedido vago. Cuando el agente recibe «implementa la issue #795, dificultad media, TL;DR: tal», tiene un objetivo claro. Compáralo con «corrige los errores» lanzado en un bucle: no hay por dónde empezar ni cómo saber cuándo terminó. El triage también filtra lo que no debe ir solo al agente (cosas que necesitan una decisión humana). El error común es saltarse la clasificación y volcar todo en la cola sin filtrar; así el agente trabaja duro en el elemento equivocado o tropieza con uno imposible.

David (el entrevistador) presentó una analogía que cristaliza la diferencia entre loop y cola: el rey medieval. Piensa en un ministro en una región distante ejecutándose en bucle por su cuenta: puede salir bien o muy mal, y el rey solo se entera cuando el daño ya está hecho. Este es el enfoque de «loop»: autonomía ciega, sin priorización central. El rey sensato no quiere eso.

El rey quiere la enfoque de cola: los problemas le llegan (una invasión, un hambre, una propuesta de acuerdo de marca — donde primero verifica su reputación antes de aceptar), y él prioriza. De 50 bugs que llegan, quizá solo 3 sean críticos, y él decide cuáles abordar ahora. La clave, en palabras de la conversación: tú sigues en el comando. La fila no te quita el poder de decisión; lo concentra en lo que importa. El loop le entrega el reino a un ministro distante; la fila mantiene la corona en tu cabeza. Error común: delegar autonomía sin mantener el punto de priorización: así te conviertes en un rey ausente, y el reino hace lo que quiere.

Al cerrar el módulo: la mayor ventaja de pensar en una cola es que escala con múltiples nodos. Recuerda la frase de Pocock: "varios nodos (desarrolladores) toman elementos de la cola." Cada nodo puedes ser tú, un colega o un agente que se ejecuta en GitHub Actions (módulo 4.3). Como cada tarea tiene un alcance claro (gracias a la clasificación), dos o tres agentes pueden trabajar en paralelo en elementos distintos sin estorbarse — exactamente lo que viste en el módulo 4.2 sobre paralelizar con sandboxes. El loop único no escala así: es un solo trabajador, dando vueltas. La cola es una arquitectura — abre espacio para «dos, tres, cuatro de ti», como Pocock describe el AFK. Usa el esqueleto de abajo para probar el Ralph loop y siente en la práctica por qué, al final, vas a querer migrar de él a una cola con clasificación:

#!/usr/bin/env bash
# Ralph loop (Geoffrey Huntley, 14/jul) — o esqueleto cru:
# um while que chama o Claude Code com o MESMO prompt, de novo e de novo.

PROMPT="Pegue a próxima tarefa pendente em TODO.md, implemente-a,
rode os testes e marque-a como feita. Se TODO.md estiver vazio, escreva DONE.txt."

while true; do
  # injeta o mesmo prompt no agente, em modo AFK (sem você no teclado)
  claude code -p "$PROMPT"

  # condição de parada: o agente sinaliza que a fila esvaziou
  if [ -f DONE.txt ]; then
    echo "Fila vazia — encerrando o loop."
    break
  fi

  sleep 2   # respiro entre as passadas
done

# Lição do módulo: isto FUNCIONA, mas é um loop cego (1 nó, foco difuso).
# Prefira virar isto numa FILA: triagem -> label agent:implement ->
# vários nós (agentes em GitHub Actions) puxam itens em paralelo. Você, o rei, prioriza.