Loops Ralph Wiggum: persistência útil precisa de uma regra de parada

Revisado em 4 de setembro de 2026.

Um agente de programação que continua tentando pode ser útil. Também pode repetir o mesmo erro, transformar uma tarefa pequena em uma reescrita ou passar a noite satisfazendo um teste fraco. Persistência só ajuda quando existe um objetivo claro e feedback confiável.

A técnica Ralph Wiggum, descrita por Geoffrey Huntley, repete o trabalho de um agente a partir de uma especificação e de um estado de tarefas registrado. Seu apelo prático é a continuidade entre tentativas, em vez de uma única conversa sobrecarregada. Leia o relato original de Huntley.

É uma técnica de organização do trabalho, não uma prova de que o resultado sem supervisão está pronto para produção.

Dê ao ciclo uma tarefa delimitada

Uma tarefa útil tem uma linha de chegada visível. Por exemplo: “Adicionar paginação por cursor a este endpoint de consulta, preservar os campos atuais da resposta e demonstrar que páginas consecutivas não repetem registros”.

É um exemplo, não uma receita universal. Ele identifica o comportamento, uma restrição de compatibilidade e uma verificação de aceitação. “Melhore o backend até ficar excelente” não oferece uma forma confiável de parar.

Forneça os comandos reais de build e testes, os arquivos relevantes, as restrições conhecidas e as ações permitidas. Declare o que não pode mudar sem decisão do responsável.

Separe o ciclo da liberação

Um ciclo conceitual seria:

Ler a tarefa, as evidências e o estado atual do repositório.
Escolher um critério de aceitação ainda pendente.
Fazer uma alteração dentro do escopo.
Executar as verificações e registrar seus resultados reais.
Se a aceitação foi demonstrada: entregar para revisão.
Se houver bloqueio, limite atingido ou falta de progresso: parar e explicar.
Caso contrário: continuar com a próxima etapa delimitada.

Isso é pseudocódigo, não um supervisor pronto para executar. Uma implementação real deve aplicar limites de tempo, gasto, permissões e cancelamento fora das instruções do modelo.

Mantenha a autoridade de publicação separada. Concluir uma implementação não autoriza automaticamente merge, deploy, alteração de dados de produção ou contato com usuários.

O feedback precisa testar o comportamento desejado

Um compilador encontra os erros que seu sistema de tipos consegue expressar. Não prova que uma regra de desconto está correta, que um usuário tem a permissão adequada ou que um registro migrado preserva seu significado. Isso também vale para Rust: segurança de tipos não elimina defeitos de lógica de negócio.

Derive os testes de aceitação do requisito, não da implementação que o agente acabou produzindo. Revise de forma independente as alterações nos testes. Um ciclo que enfraquece as verificações até passar está otimizando o objetivo errado.

No exemplo de paginação, receber HTTP 200 não basta. Verifique ordem dos registros, limites, continuação e o comportamento definido quando os dados mudam.

Reconheça quando o ciclo deixou de aprender

Observe alterações repetidas na mesma área sem evidência melhor, testes que conferem apenas formatação, crescimento de escopo e mudanças de dependências sem explicação.

Use limites externos de tentativas e duração total. Defina um critério de falta de progresso apropriado: por exemplo, falha repetida no mesmo caso de aceitação sem uma nova hipótese verificada. Não existe um número único de iterações adequado para todo repositório.

Ao atingir o limite, mantenha o trabalho recuperável. A entrega deve identificar o último estado verificado, arquivos alterados, comandos executados, falha pendente e a decisão ou informação necessária para continuar. Não deixe o agente declarar sucesso só para encerrar.

Escolha um ambiente adequado

Use uma branch ou worktree isolada, credenciais delimitadas e dados de teste representativos. Restrinja acesso externo e comandos destrutivos conforme a tarefa. Dependências e scripts continuam exigindo revisão.

Trabalhe apenas com código, especificações e recursos que você tem autorização para usar. Implementação automatizada não dá permissão para copiar um produto proprietário de terceiros ou contornar seus controles de acesso.

Um ciclo delimitado é mais útil quando o feedback custa pouco e a aceitação é concreta. Decisões de produto ambíguas, credenciais indisponíveis ou uma regra de negócio não documentada costumam exigir uma pessoa, não outra tentativa.

Julgue a entrega, não o tempo de execução

Meça mudanças revisadas que cumprem a tarefa, defeitos que escaparam e custo total com supervisão. “Rodou durante a noite” descreve um horário. Não diz nada sobre prontidão.

Em uma aplicação existente, combine o ciclo com uma investigação focada e um plano de migração. Para um exemplo próprio de build em etapas com revisão e resultados jogáveis, veja nosso experimento de criação de jogos.