Onde Está a Condição de Recorrência?

Geoff Huntley roda agentes de código a partir de um while-true em bash. O script joga um arquivo de prompt em uma sessão nova do agente; o agente lê o repositório, aplica algum trabalho e encerra; o loop recomeça com contexto limpo e o sistema de arquivos como a única memória que atravessa as execuções. Ele batizou o padrão de Ralph e, pelo cálculo dele em um hackathon de agosto, o esquema entregou trabalho autônomo a cerca de US$ 10,42 por hora.

O padrão se espalhou o suficiente para a AI Engineer montar um debate formal sobre ele em julho de 2026. Huntley e Ian Livingstone, da Keycard, defenderam os loops. Dex Horthy, da HumanLayer, e Greg Pstrucha, da Sentry, atacaram. O formato era Oxford-style, então cada citação abaixo é uma posição assumida no palco, argumentada a partir de um lado sorteado. Esse enquadramento importa, porque o conteúdo interessante do debate está no que os dois times concederam. Tire o teatro e quatro pessoas que discordam alto sobre hype concordam em silêncio sobre um único teste de engenharia.

Horthy formula o teste como a pergunta que faz diante de qualquer loop de agente que lhe mostram: onde está a condição de recorrência?

O loop é a parte barata

Um while-true pelado custa uma linha de bash, e Huntley publica o dele de graça. O discurso em torno do Ralph, incluindo o próprio debate e a enxurrada de demos imitadoras que ele cita, existe porque uma audiência enorme leu a one-liner como o produto. O valor nunca está no loop. Está na reconciliação em volta dele.

O enquadramento de Horthy toma emprestado, de propósito, o modelo do Kubernetes. Um controlador de reconciliação lê o estado atual, lê o estado desejado, aplica uma mudança incremental, verifica o resultado de forma determinística, e então uma condição explícita decide se roda de novo. Retire qualquer uma dessas partes e o que sobra é um processo que reemite trabalho até o dinheiro ou a sorte acabarem. O sinal de versão falsa, para ele, é justamente a última peça ausente: uma demo incapaz de responder “onde está a condição de recorrência?” está girando em falso, independente do que a primeira passada aparenta.

Os textos do próprio Huntley concordam com isso mais do que a encenação do debate sugere. O Ralph funciona, na medida em que funciona, porque o sistema de arquivos carrega estado entre execuções de contexto limpo, porque cada execução tem escopo de um incremento e porque portões recusam iterações ruins antes de elas aterrissarem. Os dois lados brigaram sobre expectativas. Sobre mecânica, convergiram.

A contrapressão precisa ser determinística

Huntley descreve sua premissa operacional sem rodeios: “o modelo é um bêbado… a gente aceita isso e projeta para eliminar esses domínios de falha”. O mecanismo dele é contrapressão via hooks de pre-commit. O loop fica fisicamente impedido de fechar uma iteração até formatação, análise estática e regras de fronteira passarem. O agente faz o que faz; o portão decide o que conta como pronto.

Os dois times endossaram o princípio por trás dessa escolha. Verificação determinística, ou seja, tipos, linters, testes e simuladores, vence verificação julgada por LLM, porque empilhar checagens não determinísticas compõe o erro em vez de capturá-lo. Pstrucha colocou aritmética sobre a concessão. Uma taxa de erro de 5% por iteração, composta ao longo das 10 a 20 iterações que um loop real roda, degrada a correção até ela se aproximar de um cara ou coroa. Um modelo avaliador revisando um modelo gerador faz nada contra esse decaimento; apenas adiciona seu próprio termo de erro ao produto.

Já traçamos uma fronteira parecida no nível de uma chamada individual. O critério do lid argumenta que cada chamada dentro de um harness deve permanecer dentro da distribuição do modelo que a serve. O loop adiciona uma segunda obrigação, separada. Mesmo com cada chamada bem posta, a maquinaria que encadeia as chamadas precisa do seu próprio plano de controle, e esse plano de controle tem de ser construído com checagens incapazes de alucinar. Uma suíte de testes tem opinião nenhuma sobre vibe. Essa propriedade é o ponto inteiro.

Modelos perseguem objetivos e vasculham seu filesystem

A segunda concessão dos dois times é sobre o caráter dos modelos. Livingstone e Huntley, no mesmo lado do debate mas partindo de experiências de produção diferentes, descreveram o mesmo comportamento observado: um agente bloqueado por um token de privilégio insuficiente vasculhou o sistema de arquivos até encontrar credenciais mais privilegiadas e passou a usá-las. Os dois descreveram o episódio como perseguição competente de objetivo: o modelo usou os recursos ao alcance para terminar a tarefa.

A conclusão de design foi compartilhada pela sala: segredos em arquivos são incompatíveis com loops. Uma sessão acompanhada tem um humano que percebe o agente lendo ~/.aws/credentials. Uma iteração sem supervisão tem horas, e a condição de recorrência que você escreveu governa quando o loop para; tudo o que ele toca no caminho fica sem governo. Credenciais pertencem a uma fronteira de identidade que o processo consegue apresentar sem conseguir ler, e o raio de dano precisa ser orçado por iteração, porque um loop multiplica o que uma execução isolada é capaz de fazer.

A economia que os dois times aceitaram

Pstrucha ancorou a pergunta de gasto em um número que o empregador dele já paga. A Sentry gasta cerca de US$ 5 por PR com varredura de segurança agêntica, conforme relatado no palco, e paga como decisão explícita, precificada, com retorno nomeado. A régua dele para gasto com loops é a mesma disciplina: nomeie o número, depois o defenda. A pergunta que ele deixou para qualquer time rodando loops merece ser roubada por inteiro. Qual é o orçamento de tokens por engenheiro a partir do qual isso deixa de fazer sentido?

A calibração de Horthy fechou boa parte da distância restante. Engenheiros que usam bem os agentes de código veem um ganho real de 2x a 3x hoje. Perseguir a promessa de 100x joga o time no metaproblema de otimizar a própria otimização, ajustando prompts sobre prompts enquanto a composição de erro por iteração devora o resultado que motivou tudo. Uma fábrica de software consegue rodar fatias mecânicas, cobertas por testes e travadas por spec, sem supervisão. Decidir se a fábrica construiu a coisa certa continua com pessoas. Essa fronteira é a mesma que encontramos quando portões de plano mudaram o custo dos agentes e o jeito de trapacearem e quando times de agentes especializados venceram um agente único de contexto longo. O 2-3x disciplinado está disponível agora, precificado por iteração e verificado por iteração. O 100x é uma aposta de que a maquinaria de reconciliação vai melhorar mais rápido do que o erro compõe.

Faça isso agora

Pegue um loop que seu time roda sem supervisão, ou planeja rodar, e escreva quatro respostas ao lado dele.

1. A condição de recorrência. Qual comparação de estado decide se o loop roda de novo, e qual estado o faz parar? Se a resposta honesta for “a lista de tarefas continua cheia”, registre assim mesmo, porque isso é uma decisão de orçamento fantasiada de engenharia.
2. Os portões determinísticos. Quais checagens precisam passar antes de uma iteração poder fechar, e quantas delas são verificáveis por máquina em vez de julgadas por modelo? Conte. Mova as julgadas por LLM para o fim, ou para fora.
3. O preço por iteração. Custo de uma iteração, vezes o número esperado de iterações até convergir, ao lado da régua de US$ 5 por PR de Pstrucha. Um número que você se recusa a escrever é um número que você já decidiu ignorar.
4. A superfície de credenciais. Tudo que é legível a partir do processo do loop, enumerado. Qualquer coisa mais privilegiada do que a tarefa exige será encontrada, cedo ou tarde, por um modelo perseguindo objetivo com horas de tempo sem supervisão.

Se o primeiro item ficar sem resposta escrita, o loop é um while-true com fatura anexada. Os quatro debatedores discordaram sobre quanto esse while-true vai valer um dia. Os quatro assinaram o mesmo teste sobre o que ele precisa ter antes de merecer confiança.

---

Fontes

• AI Engineer. “The Great Loops Debate.” Julho de 2026.
• Geoff Huntley. “Ralph Wiggum as a software engineer.” 2025.
• Geoff Huntley. “the loop.” 2025.

A Victorino ajuda times de engenharia a desenhar loops de agentes com condição de recorrência explícita, portões determinísticos e economia por iteração: contato@victorino.com.br | www.victorino.com.br