Vibe coding para não deixar o agente em loop de retry sem limite

Repetir uma ação sai barato quando ela não deixa rastro. Ler o arquivo de novo, consultar o estado de novo: se falhar várias vezes seguidas, o que você perdeu foi tempo. A conta muda quando cada tentativa cria alguma coisa que continua de pé depois que a tentativa acabou. Nesse caso o custo não fica parado, ele cresce a cada rodada, e quem está repetindo é um agente que não se cansa.

Thiago viu isso acontecer ao vivo, no fim de uma live da série dele. O pedido era pequeno: adicionar uma segunda conta a uma ferramenta que trabalha com várias contas. O agente tentou fazer o login, falhou, tentou de novo e falhou de novo, e cada tentativa abriu uma página de autenticação no navegador. Thiago só percebeu quando viu a tela.

"Por que você abriu tantas páginas?"

O agente respondeu com a frase que nomeia o problema:

"Não era spam, era [retry] do mesmo login."

Erro idêntico repetido não pede mais uma tentativa

O agente não estava fazendo nada aleatório. Tinha uma tarefa, a tarefa falhava, e ele reagia do único jeito que conhecia. O defeito apareceu antes da repetição: ele não comparou o erro que voltou com o erro anterior. Quando a segunda falha é igual à primeira, nada mudou entre uma e outra, nem no comando nem no estado da máquina. O que não mudou não vai entregar resultado diferente na terceira vez.

Retry foi inventado para a falha instável, aquela em que a rede oscilou ou o serviço estava ocupado por um instante. Aí a segunda chamada acontece num mundo diferente e tem chance de verdade. Um agente que não separa os 2 casos trata toda falha como instável e fica girando.

O limite que falta no vibe coding tem 2 partes

A primeira parte é o teto de tentativas, um número acima do qual o agente para e devolve o problema para você. Um teto de 3 dá conta da maioria dos casos, e esse valor é escolha de quem escreve a instrução, não regra consagrada. O número importa menos do que existir um número, porque sem ele o limite acaba sendo a paciência do hardware.

A segunda parte é a comparação. Antes de repetir, o agente confere se o erro atual é diferente do anterior, e para quando for igual. Só o teto não resolve: um teto generoso ainda deixa o estrago crescer até quase o fim, e cada unidade desse estrago já era evitável. Com a comparação, o loop morre na segunda tentativa, que é exatamente onde a informação para decidir já existia.

Essas 2 frases cabem na instrução que você dá ao agente antes de soltar a tarefa. É o tipo de freio que o vibe coding pede quando o agente ganha permissão para agir sozinho: você não está revisando cada passo, então precisa deixar combinado onde ele para. Isso aparece também em vibe coding para nao deixar o teste proteger o corte errado. Vale ver como isso terminou em vibe coding para nao deixar quem reduz sem reforco positivo. Vale ver como isso terminou em vibe coding para processar lote sem torrar o limite.

Pergunte o que sobra no mundo a cada tentativa

A classe de ação que precisa de teto é a que cria recurso. Abrir aba ou janela de navegador, subir processo, criar arquivo, disparar chamada cobrada, gravar registro no banco. Cada tentativa deixa um objeto vivo, e esse objeto consome memória ou dinheiro enquanto existir. Vale ver como isso terminou em vibe coding para separar tela de aprovar e tela de publicar. A aba de autenticação é um exemplo limpo disso: uma aba sozinha não pesa quase nada, e a conta só aparece quando elas se acumulam.

Foi o que aconteceu ali, com a memória indo embora até a máquina parar de responder.

"Travou meu PC."

"Não faz isso de novo."

Numa leitura refeita, o teto é conforto. Numa ação que instancia recurso, o teto é proteção. Antes de deixar o agente repetir qualquer coisa, pergunte o que sobra no mundo depois de cada tentativa, e ponha limite sempre que a resposta tiver um substantivo.

O retry cego erra no volume e erra no estado final

O travamento foi o dano visível. Quando o computador voltou, a sessão estava autenticada na conta errada, no e-mail que não era o pretendido. A última tentativa venceu por ser a última, e não por ser a certa. Isso aparece também em vibe coding para separar formato visual da estrutura do conteudo.

O sistema parou num estado que ninguém escolheu, definido pela ordem acidental das tentativas, e coube ao Thiago descobrir depois em qual conta tinha ficado. A máquina travando avisa na hora; a sessão logada no lugar errado fica quieta esperando você trabalhar em cima dela.

É a mesma família de problema que aparece quando Thiago exige confirmação antes de uma ação que gera custo: lá o freio é humano e vem antes do primeiro disparo, aqui o freio é numérico e vem antes do segundo, e nos 2 casos o que se protege é a ação que deixa marca fora do editor. Trabalhar com vibe coding é aceitar que o agente age, e ação que age no mundo precisa de onde parar.

O que fazer antes de soltar o agente

Olhe para a tarefa que você vai delegar e responda o que cada tentativa cria. Se criar alguma coisa, escreva na instrução o número máximo de tentativas e a ordem de parar quando o erro se repetir igual, com a mensagem de erro no relatório para você. Peça também que ele feche o que abriu antes de tentar de novo, porque a aba da tentativa anterior já não serve para nada. E quando você vir a tela se enchendo de janela que você não pediu, pare o agente antes de perguntar o motivo: a explicação continua disponível depois, a memória da máquina não. Isso funciona tanto para problemas técnicos quanto para decisões preparatórias, como em vibe coding para usar ia como rascunho de contador e advogado. E quando o agente afirmar que salvou, pergunte o lugar exato e confira lá, como em vibe coding para agente que diz que salvou mas não salvou no lugar certo. Quando disparar múltiplos agentes em paralelo, defina de antemão qual será o teto de consumo e a família de modelo autorizada, como em vibe coding para restringir modelo e conta de ia para o squad.

Dá para assistir à live: a cena está no fim, com o navegador cheio de páginas de login e o computador travado.