🧮 Loops × Filas

Em julho, o engenheiro Geoffrey Huntley publicou um artigo (14/jul) que viralizou na comunidade: o Ralph loop. A ideia é deliciosamente simples — você escreve um loop while em bash que chama o Claude Code passando o mesmo prompt de novo e de novo. O agente termina uma passada, o loop reinicia, e ele recebe a instrução outra vez. Roda assim, em AFK, sem você no teclado.

O nome "Ralph" é uma piada interna (referência ao personagem Ralph Wiggum, dos Simpsons, que faz a coisa simples sem pensar muito) — e parte da graça é justamente essa: brutalmente simples, e ainda assim eficaz. Por que funciona? Porque cada nova passada do agente recomeça com contexto fresco, relê o estado do codebase e dá mais um passo. É a forma mais crua de tirar você da equação. O erro comum aqui é achar que "loop = mágica autônoma": o loop só repete; quem faz o trabalho ainda é o agente, e ele depende do prompt e do harness por trás.

Aqui entra a posição de Pocock — e é uma virada de chave importante. Ele reconhece que o Ralph loop é engenhoso, mas diz, com todas as letras: "não preciso rodar como loop — só preciso do agente AFK pegar uma tarefa específica e fazer." Em outras palavras, o que o destrava de verdade não é a repetição infinita; é o AFK (o agente trabalhando sem você presente). O loop é só uma forma — e não a melhor — de alcançar isso.

Por quê? Porque um loop único que tenta "fazer tudo" não bate com a forma como times reais trabalham. Um time não tem um robô girando para sempre; tem um backlog de tarefas claras, cada uma com começo, meio e fim. A repetição cega gasta tokens, perde o foco e dificulta dizer "isto aqui está pronto". A resposta certa, segundo Pocock, é trocar o verbo: em vez de "loopar", pense em "pegar a próxima tarefa da fila". Mesma autonomia, muito mais controle e clareza. Erro comum: confundir "rodar sozinho" (bom: AFK) com "rodar em círculos" (raramente o que você quer).

A frase central de Pocock é: "eu penso nisto principalmente como filas, não loops." Uma fila é simplesmente o seu backlog de tarefas. E ele dá o exemplo concreto do Sand Castle (a ferramenta dele): ele olha as issues, faz a triagem (é trivial? é possível?), adiciona o label agent:implement e o agente implementa via GitHub Actions (visto no módulo 4.3).

E aí vem a definição que organiza tudo: "todo desenvolvimento é só uma fila de tarefas: PMs adicionam à fila, você as completa; múltiplos nós (devs) pegam itens da fila." Repare como isso descreve qualquer time de software do mundo — sem nenhuma IA envolvida. O PM alimenta a fila, os desenvolvedores consomem. A sacada de Pocock é que os "nós" agora podem ser agentes em vez de (ou além de) humanos. Você não muda o modelo mental do time — só troca quem puxa os itens. Por isso a fila encaixa naturalmente, e o loop único que "faz tudo" não bate com como times trabalham.

Antes de um item virar trabalho, ele passa por triagem. No fluxo do Sand Castle, Pocock olha cada issue e responde duas perguntas: é trivial? e é possível? — e isso já pode ser feito em AFK. Há uma issue real (#795 no exemplo dele) que vai mudando de label: agent:explore → agent:in-progress, enquanto o bot github-actions posta um comentário de "Triage" com um TL;DR e uma estimativa de Difficulty (dificuldade).

Por que isso importa? Porque a triagem dá escopo — e escopo é o que separa uma tarefa "pegável" de um pedido vago. Quando o agente recebe "implemente a issue #795, dificuldade média, TL;DR: tal", ele tem um alvo nítido. Compare com "conserte os bugs" jogado num loop: não há onde começar nem como saber que terminou. A triagem também filtra o que não deve ir pro agente sozinho (coisas que precisam de decisão humana). O erro comum é pular a triagem e despejar tudo na fila cru — aí o agente trabalha duro no item errado, ou tropeça num item impossível.

David (o entrevistador) trouxe uma analogia que cristaliza a diferença entre loop e fila: o rei medieval. Pense num ministro numa região distante rodando em loop por conta própria — ele pode dar certo, ou pode dar muito errado, e o rei só descobre quando o estrago já aconteceu. Essa é a abordagem "loop": autonomia cega, sem priorização central. O rei sensato não quer isso.

O rei quer a abordagem de fila: os problemas chegam até ele (uma invasão, uma fome, uma proposta de brand deal — onde ele checa a reputação primeiro antes de aceitar), e ele prioriza. De 50 bugs que chegam, talvez só 3 sejam críticos — e ele decide quais atacar agora. O ponto, nas palavras da conversa: você continua no comando. A fila não tira seu poder de decisão; ela o concentra no que importa. O loop entrega o reino a um ministro distante; a fila mantém a coroa na sua cabeça. Erro comum: delegar autonomia sem manter o ponto de priorização — aí você vira um rei ausente, e o reino faz o que quiser.

Fechando o módulo: a maior vantagem de pensar em fila é que ela escala com múltiplos nós. Lembre da frase de Pocock: "múltiplos nós (devs) pegam itens da fila." Cada nó pode ser você, um colega, ou um agente rodando em GitHub Actions (módulo 4.3). Como cada tarefa tem escopo claro (graças à triagem), dois ou três agentes podem trabalhar em paralelo em itens diferentes sem se atrapalhar — exatamente o que você viu no módulo 4.2 sobre paralelizar com sandboxes. O loop único não escala assim: ele é um trabalhador só, girando. A fila é uma arquitetura — abre espaço para "dois, três, quatro de você", como Pocock descreve o AFK. Use o esqueleto abaixo para experimentar o Ralph loop e sinta na prática por que, no fim, você vai querer migrar dele para uma fila com triagem:

#!/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.