Por dois anos, extrair mais de um agente de IA significava escrever um prompt melhor.
Essa era está acabando silenciosamente. Os melhores engenheiros do mundo pararam de escrever prompts há algum tempo e começaram a escrever loops – sistemas que dão instruções ao agente, verificam o resultado e continuam executando até o trabalho ser concluído.
O script noturno do Karpathy encontrou 20 otimizações que ele havia perdido em duas décadas de ajustes manuais. Boris Cherny, que construiu o Claude Code, não escreveu uma linha de código este ano. Engenheiros da Anthropic agora mesclam quase 8x mais código por dia do que em 2024.
Nenhum deles digitou algo mais inteligente. Eles simplesmente pararam de digitar.
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 avaliava. 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 alteração, treinar por cinco minutos, verificar se a pontuação melhorou, manter a alteração se sim, reverter se não, e então repetir.
Ele apontou o ciclo para um modelo que já havia ajustado manualmente por duas décadas. Deixou-o rodar por dois dias.
Foram 700 experimentos. Ele encontrou 20 melhorias. Uma delas era um multiplicador escalar ausente 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 da Shopify executou o mesmo truque durante a noite em um modelo interno. Ele 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 se cansam após o experimento doze. Loops não se cansam nunca.
Um loop não é um prompt em uma programação
A maioria das pessoas ouve "loop" e pensa em cron. Isso perde o essencial.
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 avaliando sua própria lição de casa para sempre. Uma barreira é um teste que passa ou falha, uma compilação que compila ou falha, um linter que retorna zero ou diferente de zero. Não um segundo agente com uma opinião.
O estado é o que faz o loop aprender. Um arquivo auxiliar, um quadro Linear, um registro 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.
Faltando qualquer um dos três, 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. Faltando uma, 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 reprovar o trabalho automaticamente. 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, tentam novamente, 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 noturnos em trabalho sério, a conta de tokens chega antes do ganho de produtividade.
Bons primeiros loops são os entediantes. 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á possui testes fortes.
Maus primeiros loops são os interessantes. Reescrevendo arquiteturas. Código de autenticação. Pagamentos. Qualquer coisa onde "pronto" é uma questão de julgamento e um humano ainda tem que 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 agora.
A primeira é a automação. O batimento cardíaco. Algo que aciona o loop em um cronograma ou evento. /loop é executado em uma cadência. /goal continua até que uma condição que você definiu realmente seja válida. 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 cada execução. Sem ele, o loop deriva seu contexto do zero a cada ciclo. Com ele, a intenção se acumula. O loop conhece suas convenções, suas etapas de compilação, aquela coisa que você nunca faz por causa daquele incidente de 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 os conectores. O loop abre o pull request, fecha o ticket, notifica o 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 o trabalho ruim automaticamente. Todo o resto é encanamento. Este é o bloco que decide se o loop te ajuda ou apenas gasta seu dinheiro.
Empilhe esses componentes e você terá o que equipes sérias agora executam em escala. Dezenas de loops, cada um responsável por 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 quase 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 facilitando.
O primeiro é o loop 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 perfeitamente cobra juros compostos sobre essa lacuna. O dia em que você tiver que 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 roda sozinho, é tentador parar de formar uma opinião e aceitar o que quer que volte. Projetar o loop é a cura quando você o faz com discernimento. É o acelerador quando você o faz para evitar pensar. Mesma ação, resultado oposto.
Duas pessoas podem construir exatamente o mesmo loop e acabar em lugares opostos. Uma o usa para se mover mais rápido em um trabalho que entende profundamente. A outra o 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 inteiro 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 recorrente mais irritante que você tem, aquela que você verifica toda manhã por hábito, e transforme essa única tarefa em um loop. Deixe-o rodar por alguns dias. Observe onde ele excede. Observe onde ele falha. Aperte. Então adicione o segundo.
A ordem importa mais do que as ferramentas. Primeiro, torne uma execução manual confiável, não rápida, 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 alteração aceita. Se sua taxa de alterações aceitas estiver abaixo de 50%, você está fazendo o trabalho de revisão que o loop deveria remover, 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ê tirar uma coisa disso, tire isso. O loop é um sistema que faz os chatos 95% enquanto você mantém sua atenção total 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
