O Loop de Ralph Wiggum, Desde os Princípios Fundamentais

Se você usou um agente de codificação com IA por mais de algumas horas, você conhece o “muro”: o agente faz progressos visíveis, então estagna — e você acaba fazendo os ajustes e terminando o trabalho por conta própria.

Como os engenheiros de IA costumam fazer, um padrão surgiu para resolver esse problema: apenas faça o agente passar por verificações externas até que o trabalho realmente seja aprovado.

A abordagem pegou tão forte que ganhou um nome — Ralph Wiggum.

E o meme pegou porque o padrão funciona. Até o final de 2025, Anthropic havia formalizado isso em um plugin oficial do Claude Code.

Ralph representa uma mudança na forma como os desenvolvedores estão usando as ferramentas existentes. Em vez de tratar os sistemas de IA como assistentes interativos, eles estão sendo executados como processos de longa duração, guiados por testes, linters e condições de parada explícitas.

Então, este guia prático é a versão prática. Vamos ver o que realmente é o Ralph, por que funciona, como se espalhou e o que mudou quando foi transformado em produto.

O Que É “Ralph”, Realmente?

Essencialmente, é isso que o Ralph é: execute um agente em um loop, verifique o resultado contra algo que não possa mentir, como um teste, um linter, um verificador de tipo; e continue em loop até que passe.

É isso.

O exemplo original que Geoffrey Huntley compartilhou em julho de 2025 foi intencionalmente direto:

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude as variantes de código seguem a mesma forma, apenas com mais barreiras de proteção. Mas o princípio não muda: alimente um prompt fixo no agente repetidamente até que a realidade externa diga que você terminou.

O loop em si é quase irrelevante, e o que importa é o contrato:

• O Estado Vive No Repositório: Arquivos, diferenças, registros, histórico git; tudo o que é durável fica aqui.
• A Conclusão Vive Fora Do Modelo: Testes, linters, verificadores de tipo; o agente não decide quando terminou; o arnês decide.
• O Agente É Substituível: É um trabalhador invocado repetidamente até que o portão passe; se está lento ou obtuso hoje, troque por algo mais rápido amanhã.

Visto dessa forma, Ralph se torna um princípio de design: pare de pedir ao modelo para saber quando ele está concluído. Pare de esperar que ele lembre as restrições após as redefinições de contexto.

Em vez disso, construa o sistema de forma que o modelo não possa falhar nessas maneiras.

Por Que o Loop Se Sustenta?

Alguns motivos:

1. Janelas de Contexto Comportam-se Como Buffers

Huntley costuma enquadrar janelas de contexto em termos de baixo nível:

“Pense como um engenheiro de C ou C++. Janelas de contexto são arrays.”

Eles têm um tamanho fixo; eles deslizam; eles sobrescrevem; eles esquecem.

Sessões de longa duração assumem uma continuidade que não existe, então tratar o buffer como memória durável leva a desvios, restrições perdidas e comportamento inconsistente.

Ralph se debruça sobre a realidade do sistema. Em vez de fingir que a janela de contexto é estável, ele a trata como descartável.

O espaço temporário do agente é redefinido entre iterações, enquanto o estado durável persiste no disco. O repositório acumula verdade ao longo das execuções. Isso torna a reinicialização do agente rotineira em vez de desperdiçadora; cada ciclo começa do zero, mas constrói baseando-se no que realmente persistiu.

2. Verificações Externas Superam o Raciocínio Interno

Muitos frameworks de agentes respondem à falha adicionando estrutura dentro do modelo: planejadores, resumos, estado interno e loops de reflexão.

Ralph mantém a inteligência fora do agente. Ele depende de:

• Uma especificação fixada que não se desvia
• Evidência concreta da última execução
• Um portão determinístico que avalia o sucesso

O agente não decide quando o trabalho está concluído – o arnês decide.

É por isso que Ralph se destaca em trabalho mecânico: refatorações, migrações, limpeza, tarefas de conformidade… Em qualquer lugar onde o sucesso possa ser medido por um script em vez de julgamento, a iteração se torna confiável.

O modelo não pode se esquivar dos requisitos porque os requisitos existem fora do seu raciocínio.

3. A Compactação Erode Restrições

Uma crítica recorrente de Huntley foca na sumarização e compactação.

Quando um sistema pede ao modelo para decidir o que é importante o suficiente para manter, informações são perdidas — restrições diminuem, casos extremos desaparecem e pinos caem.

Ralph contorna isso mantendo as entradas literais:

• As especificações permanecem verbatim em vez de serem resumidas, 
• O resultado da falha permanece cru e não filtrado; e 
• A curadoria de memória nunca avança para o modelo.

O arnês preserva a fidelidade; o agente opera dentro dele, limitado pelo que realmente existe, em vez do que o modelo acredita que deveria estar lá.

Então, Como a Ideia se Espalhou?

O cronograma está bastante comprimido.

• 19 de Junho, 2025: Em um encontro em São Francisco com cerca de 15 engenheiros discutindo codificação agente, Huntley demonstra Ralph, Cursed (a linguagem de programação sendo construída por Ralph), e transmite ao vivo a codificação autônoma durante a noite enquanto dorme na Austrália. A sala tem uma conversa perturbadora sobre como é fácil copiar 80%-90% de um SaaS e como muitos tipos de trabalho estão prestes a desaparecer completamente.
• Julho de 2025: Huntley publica o post original no blog com a estrutura básica do loop bash. O artigo inclui um exemplo leve de prompt e um pedido: “você provavelmente poderia encontrar o repositório lang amaldiçoado no github se você procurasse, mas por favor, não compartilhe ainda.”
• Agosto de 2025: Acontece o hackathon dos agentes YC — equipes executam Claude Code em loops contínuos. O resultado é 6 repositórios entregues durante a noite. Dexter Horthy executa um loop experimental de Ralph em uma refatoração de código React. Em mais de 6 horas, ele desenvolve um plano completo de refatoração e o executa aqui.
• Setembro de 2025: Huntley lança oficialmente o Cursed Lang, a linguagem de programação que Ralph construiu. Ela existe em três implementações (C, Rust, Zig), possui uma biblioteca padrão, e um compilador de fase 2 escrito no próprio Cursed.
• Outubro de 2025: Dexter apresenta Ralph no Claude Code Anonymous em São Francisco. A pergunta da audiência: “Então, você recomenda isso?” Sua resposta: “Coisas simples podem funcionar surpreendentemente bem. O que poderíamos esperar de uma versão inteligente?”
• Dezembro de 2025: Anthropic lança um plugin oficial do Ralph Wiggum. O plugin pega o loop bash de Huntley e o formaliza com Ganchos de Parada e dados de falha estruturados.
• Janeiro de 2026: Huntley e Horthy fazem uma discussão aprofundada no YouTube comparando a implementação original do loop bash de Ralph com a implementação de gancho de parada da Anthropic.

Bash-Loop Ralph vs. Plugin Ralph

O Ralph original é um loop bash de 5 linhas. Você cat um arquivo de prompt, encaminha para o Claude, verifica se a saída passa no seu teste e repete até que passe. Tudo fica armazenado no disco, tudo é visível. Se algo quebrar, você pode ver exatamente por quê.

O plugin Anthropic inverte esse modelo, então, em vez de executar o loop por fora, ele instala um Gancho de Parada dentro da sua sessão Claude. Quando Claude tenta sair, o gancho intercepta, verifica suas condições de conclusão e reinsere o mesmo prompt se ainda houver trabalho restante. Os arquivos que Claude modificou ainda estão lá.

O histórico do git ainda está lá, mas os mecanismos do harness agora são opacos — escondidos em um arquivo de estado markdown, sensíveis a permissões, fáceis de quebrar se você não sabe o que está fazendo.

Este é o clássico tradeoff de abstração.

O plugin reduz o custo de adoção. Você não precisa escrever bash e não precisa pensar em loops. Mas à medida que o mecanismo fica oculto, a visão original fica mais fácil de perder.

A versão do bash-loop obriga-te a projetar o arnês. A versão do plugin permite-te pular essa etapa, o que é bom até que um caso limite surja e não consigas ver o que realmente está acontecendo.

Dexter Horthy testou e descobriu que ele falha de maneiras enigmáticas a menos que você use “–dangerously-skip-permissions”. O plugin instala ganchos em lugares estranhos, usa arquivos de estado opacos e, se você deletar o arquivo markdown antes de pará-lo, você quebra o Claude naquele repositório até desativar completamente o plugin.

Então, qual é a lição? Ambos funcionam, mas funcionam por motivos diferentes. O loop bash funciona porque é simples e transparente. O plugin funciona quando a abstração não esconde algo crítico.

O Que Você Aprende Ao Executá-lo?

Ralph assume a distância entre o humano e o agente. Você não fica sentado na sessão e o guia. Em vez disso, você o coloca para funcionar, afasta-se, inspeciona os artefatos quando ele termina e ajusta as restrições para a próxima iteração.

A interação ocorre no nível do arnês — o prompt, os testes, as condições de parada — não dentro da conversa.

Com o tempo, um padrão surge: a maioria das falhas não são falhas do modelo; são falhas do arnês.

A especificação era vaga, o teste era muito amplo, ou a condição de conclusão não descrevia de fato o que significa “concluído”.

Uma vez que você vê isso algumas vezes, seu instinto muda. Você para de perguntar “como eu faço o Claude mais inteligente?” e começa a perguntar “como eu faço as restrições mais rígidas?”

Aqui é onde as especificações se tornam críticas.

Especificações Como Superfícies de Controle

Huntley redefine as especificações não como documentação, mas como entradas de controle fixas. Você as produz através de conversa com Claude, edita-as deliberadamente até que estejam precisas e, então, fixa-as. Uma vez fixadas, elas não mudam durante todo o ciclo.

Isso importa porque as especificações fazem três coisas ao mesmo tempo:

1. Eles Limitam O Que O Agente Pode Inventar: Sem uma especificação precisa, Claude adicionará camadas de proteção, abstrações ou funcionalidades que você nunca solicitou, expandindo o escopo a cada iteração. 
2. Eles Ancoram Pesquisa E Recuperação: Assim, o agente não alucina novos requisitos.
3. Eles Estabilizam O Comportamento Ao Longo Das Execuções: Cada iteração está resolvendo o mesmo problema, não uma interpretação ligeiramente diferente dele.

Se sua especificação é vaga sobre o que significa “concluído”, o agente vai interpretá-la de forma diferente a cada ciclo. Você acaba com desvios, aumento de escopo e iterações que se contradizem.

Como Você Executa o Loop Responsavelmente?

Uma configuração minimalista do Ralph geralmente parece com:

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

A mecânica do loop importa muito menos do que as regras em torno dele:

• Mantenha a especificação imutável; não a ajuste durante o loop baseado no que Claude está fazendo. 
• Codifique a conclusão como verificações executáveis.
• Imponha limites de iteração e limites de tempo para que o loop não possa funcionar indefinidamente e consumir seu orçamento de tokens. 
• Preserve registros e diferenças para que você possa inspecionar o que deu errado, caso ocorra. 

Além disso, a prática operacional revelou algumas heurísticas importantes:

• Prefira pequenas e regulares alterações em vez de grandes reformulações, porque mudanças grandes acumulam erros e são mais difíceis de depurar. 
• Rerun na main atual em vez de rebase, porque conflitos de mesclagem desperdiçam iterações.
• E evite usar Ralph para trabalhos exploratórios, porque se você não tem testes de aceitação claros, você acabará obtendo um loop caótico que inventa coisas que você não pediu.

A restrição é a funcionalidade.

O Loop É a Lição

À medida que Ralph ganhou tração, surgiram variações. Algumas equipes construíram loops externos estruturados em torno de agentes que chamam ferramentas. Outros adicionaram componentes verificadores separados: um modelo diferente que revisa a saída do trabalhador antes que o loop decida sair. Essas extensões funcionam, sim, mas apenas se respeitarem a percepção original.

A regra é simples: a verificação deve permanecer determinística, e os resumos nunca devem substituir as entradas primárias.

• Se você adicionar um verificador, ele deve verificar coisas concretas: os testes passam, o linter termina sem erros, o git diff corresponde às expectativas. 
• Se você adicionar loops externos estruturados, eles ainda devem ver a saída bruta e os registros brutos, não um resumo limpo do que deu errado. 

O argumento principal de Huntley é que o desenvolvimento de software como profissão está efetivamente morto, mas a engenharia de software — a prática de construir sistemas bem — está mais viva do que nunca.