Por dois anos, extrair mais de um agente de IA significava escrever um prompt melhor.
Essa era está silenciosamente terminando. Os melhores engenheiros do mundo pararam de escrever prompts há um tempo e começaram a escrever loops - sistemas que dão instruções ao agente, verificam o resultado e continuam rodando até o trabalho ser concluído.
O script noturno do Karpathy encontrou 20 otimizações que ele havia perdido em duas décadas de ajuste manual. Boris Cherny, que construiu o Claude Code, não escreveu uma linha de código este ano. Engenheiros da Anthropic agora mesclam quase 8 vezes mais código por dia do que em 2024.
Nenhum deles digitou nada mais inteligente. Eles pararam de digitar completamente.
Aqui está o que realmente é um loop, quando você precisa de um, quando não precisa, e como construir o seu primeiro.
700 experimentos enquanto o humano dormia
Março de 2026. Andrej Karpathy envia três arquivos para o GitHub. Cerca de 630 linhas de código.
Um arquivo continha o modelo. Um o pontuava. Um dizia ao agente o que explorar e o que deixar de lado. O agente só podia tocar no arquivo de treinamento. Nada mais.
O ciclo era propositalmente entediante. Ler o código, propor uma mudança, treinar por cinco minutos, verificar se a pontuação melhorou, manter a mudança se melhorou, reverter se não melhorou, e então repetir.
Ele apontou o script para um modelo que já havia ajustado manualmente por duas décadas. Deixou rodar por dois dias.
Ele executou 700 experimentos. Encontrou 20 melhorias. Uma delas era um multiplicador escalar faltando no mecanismo de atenção, sutil, não o tipo de bug que qualquer linter pegaria, mas exatamente o tipo de coisa que um engenheiro cuidadoso poderia ter encontrado e nunca encontrou.
O CEO do Shopify executou o mesmo truque durante a noite em um modelo interno. Acordou com um ganho de qualidade de 19% em um modelo com metade do tamanho do anterior.
A percepção não é "a IA é mais inteligente". Humanos ficam cansados após o décimo segundo experimento. Loops não se cansam de jeito nenhum.
Um loop não é um prompt em um cronograma
A maioria das pessoas ouve "loop" e pensa em cron. Isso perde o ponto principal.
Um prompt é uma instrução. Um loop é um objetivo pelo qual a IA continua trabalhando até alcançá-lo, sem ninguém na cadeira. Ele planeja, executa, verifica seu próprio resultado, realimenta o resultado e repete.
Cinco estágios: descobrir, planejar, executar, verificar, iterar. Três deles fazem o trabalho real.
O verificador é o coração do loop. Sem uma barreira real na saída, você não tem um loop, você tem o agente corrigindo seu próprio trabalho para sempre. Uma barreira é um teste que passa ou falha, uma compilação que compila ou trava, um linter que retorna zero ou não-zero. Não um segundo agente com uma opinião.
O estado é o que faz o loop aprender. Um arquivo à parte, um quadro no Linear, um log do projeto, algum lugar fora da conversa que registra o que foi tentado e o que falhou. A execução de amanhã retoma em vez de começar do zero.
Uma condição de parada é o que o mantém são. Todo loop real tem duas saídas: o objetivo é alcançado, ou um limite máximo é acionado. Pule isso e você construiu uma máquina que funciona a noite toda por nada.
Perca qualquer um dos três e você não construiu um loop. Você construiu um script caro.
As quatro condições antes de construir um
Loops só valem seu custo quando quatro coisas são verdadeiras ao mesmo tempo. Perca uma e a configuração custa mais do que retorna.
- A tarefa se repete pelo menos semanalmente. Menos que isso e o custo de configuração nunca se amortiza.
- Algo pode automaticamente reprovar o trabalho. Um teste, uma verificação de tipo, um linter, uma compilação.
- Seu orçamento de tokens pode absorver o desperdício. Loops releem contexto, repetem, exploram.
- O agente tem ferramentas de engenheiro sênior. Logs, um ambiente de reprodução, a capacidade de executar o código que escreve e ver o que quebra.
A versão honesta, a parte que ninguém vendendo loops vai te contar: a maioria das pessoas ainda não precisa da versão pesada. Se você está em um plano de consumo tentando executar loops de verificação noturna em trabalho sério, a conta de tokens chega antes do ganho de produtividade.
Bons primeiros loops são os chatos. Triagem de CI. Atualizações de dependências. Passagens de lint-e-correção. Reprodução de testes instáveis. Rascunhos de issue-para-PR em uma base de código que já tem testes fortes.
Maus primeiros loops são os interessantes. Reescrevendo arquitetura. Código de autenticação. Pagamentos. Qualquer coisa onde "pronto" é uma opinião e um humano ainda precisa opinar.
Os cinco blocos que tornam um loop real
Todo loop real é montado a partir das mesmas cinco peças. Claude Code e Codex já vêm com todas elas.
A primeira é automação. O batimento cardíaco. Algo que dispara o loop em um cronograma ou evento. /loop executa em uma cadência. /goal continua até que uma condição que você definiu realmente se mantenha. Sem um batimento cardíaco, o loop é um script que você executou uma vez e esqueceu.
A segunda é uma habilidade. Conhecimento do projeto salvo como um arquivo claude-md que o agente lê em toda execução. Sem ele, o loop redescobre seu contexto do zero a cada ciclo. Com ele, a intenção se acumula. O loop conhece suas convenções, seus passos de build, a coisa que você nunca faz por causa daquele incidente três meses atrás.
A terceira são subagentes. O criador e o verificador não podem ser o mesmo modelo. Aquele que escreveu o código é muito generoso ao avaliar seu próprio trabalho. Aquele que escreveu o artigo perde suas próprias seções fracas. Escritor rápido e barato. Revisor lento e rigoroso. Essa separação é a maior parte da qualidade.
A quarta são conectores. O loop abre o pull request, fecha o ticket, envia mensagem no canal quando o CI fica verde. Esta é a diferença entre um agente que diz "aqui está uma correção sugerida" e um relatório esperando por você de manhã dizendo que o PR já foi mesclado.
A quinta é o verificador. O teste, verificação de tipo ou compilação que reprova trabalho ruim automaticamente. Todo o resto é encanamento. Este é o bloco que decide se o loop te ajuda ou apenas gasta seu dinheiro.
Empilhe esses juntos e você obtém o que equipes sérias agora executam em escala. Dezenas de loops, cada um cuidando de um trabalho restrito, rodando lado a lado enquanto todos dormem. Um engenheiro usou um loop de frota como este para reescrever uma base de código inteira de um idioma para outro em cerca de seis dias, trabalho que teria levado perto de um ano manualmente.
Onde os loops falham silenciosamente
Loops não travam. Eles te cobram em silêncio. Dois modos de falha que valem a pena nomear, ambos piorando à medida que o loop melhora, não mais fácil.
O primeiro é o loop do Ralph Wiggum. O engenheiro Geoffrey Huntley o documentou. O agente decide que terminou cedo demais, emite o sinal de conclusão em um trabalho meio feito, e o loop sai satisfeito. Sem uma barreira objetiva e rigorosa, o loop continua rodando na noite seguinte, continua gastando, continua produzindo trabalho que ninguém aceitará.
A correção não é um agente mais inteligente. É uma barreira mais burra. Um teste que passa ou falha. Uma compilação que compila ou não. Algo sem opinião.
O segundo é mais sutil. Dívida de compreensão. Quanto mais rápido o loop entrega código que você não escreveu, maior a lacuna entre o que seu repositório contém e o que você realmente entende. Um loop funcionando suavemente cobra juros compostos nessa lacuna. O dia em que você precisa depurar um sistema que ninguém na equipe leu custa mais do que os tokens jamais custaram.
A rendição cognitiva vem junto. Quando o loop funciona sozinho, é tentador parar de formar uma opinião e aceitar o que quer que retorne. Projetar o loop é a cura quando você faz com julgamento. É o acelerador quando você faz para evitar pensar. Mesma ação, resultado oposto.
Duas pessoas podem construir exatamente o mesmo loop e acabar em lugares opostos. Uma usa para se mover mais rápido em trabalho que entende profundamente. A outra usa para evitar entender o trabalho completamente. O loop não sabe a diferença. Você sabe.
Comece com um loop, não com dez
O erro que todos cometem é tentar construir o sistema completo no primeiro dia. Dez loops, um painel, uma frota. Desmorona no fim de semana porque você não consegue dizer qual loop fez o quê.
Comece com um. Escolha a tarefa repetitiva mais irritante que você tem, a coisa que você verifica toda manhã por hábito, e transforme esse único trabalho em um loop. Deixe rodar por alguns dias. Observe onde ele exagera. Observe onde ele erra. Aperte. Então adicione o segundo.
A ordem importa mais que as ferramentas. Primeiro, torne uma execução manual confiável, não rápido, confiável. Transforme essa execução em uma habilidade claude-md. Envolva a habilidade em um loop com uma barreira objetiva e uma condição de parada rígida. E então, só então, coloque-o em um cronograma. Pular etapas, agendar algo que você não tornou confiável manualmente, é exatamente como os loops explodem enquanto você dorme.
A métrica que decide se o loop está funcionando não é tokens gastos, tarefas tentadas ou PRs abertos. É custo por mudança aceita. Se sua taxa de mudança aceita está abaixo de 50%, você está fazendo o trabalho de revisão que o loop deveria eliminar, e o loop está perdendo.
Karpathy parou de escrever código de treinamento. Cherny parou de dar prompts. Nenhum deles parou de pensar. Se você levar uma coisa disso, leve esta. O loop é um sistema que faz os chatos 95% enquanto você mantém toda sua atenção nos 5% que realmente carregam risco.
Você está pagando por uma frota de agentes e usando uma janela de chat.
Siga-me e inscreva-se no meu canal do Telegram: https://t.me/+75nMf005jRpjMDU1
