“Pare de escrever prompts” — a frase está se espalhando pelos círculos de IA.
De Boris Cherny, criador do Claude Code, a Peter Steinberger — criador do OpenClaw, hoje construindo agentes pessoais na OpenAI — até Addy Osmani, o engenheiro do Google que batizou o movimento, todos na linha de frente dizem a mesma coisa.
Cherny diz que quase não escreve mais prompts à mão: um agente escreve prompts para a Claude, e ele conversa apenas com a “meta Claude” que coordena tudo. Ele chegou a prever que, daqui a dez anos, os loops estarão entre o trabalho de que mais se orgulhará. Steinberger foi além: pare de escrever prompts para agentes de código — desenhe os loops que os alimentam. Ele demonstrou ao vivo: o Codex acordando a cada 5 minutos, mantendo um repositório e despachando tarefas, parte do trabalho sendo entregue de forma totalmente autônoma.
O consenso popular diz que programar com IA equivale a escrever bons prompts. O consenso deste grupo: os prompts não estão mortos — estão degenerando de profissão em componente. O sistema além do prompt — o loop — é onde vive a verdadeira diferenciação. E, recentemente, a equipe do Claude Code codificou a tendência em um post oficial no blog, definindo quatro tipos de loop e estabelecendo convenções de engenharia para “agentes que trabalham sozinhos”.
A Essência de um Loop Não é Executar — é Parar
Na definição oficial da Claude, um loop é “um agente repetindo trabalho até que uma condição de parada seja acionada”. Simples — até você perceber que um ano de debates sobre “autonomia da IA” era, na verdade, sobre isto: fazer a IA executar é fácil; fazer com que ela execute na direção certa e depois pare é difícil.
Um loop sem freios cai em duas armadilhas conhecidas. Uma é queimar tokens — Steinberger se autodenomina “o homem com tokens ilimitados” porque tokens grátis são um benefício para funcionários da OpenAI; o resto de nós não tem essa vantagem. A outra é mais sutil: o agente que “parece progredir enquanto gira em círculos” — editando o mesmo arquivo repetidamente sem nunca produzir um teste que passe, aperfeiçoando com confiança uma solução errada.
O consenso da comunidade de engenharia é direto: loops são poderosos e perigosos sem freios. Um loop bem projetado instala três defesas primeiro: uma condição de conclusão (verificável por máquina, como todos os testes passando), um teto rígido (máximo de iterações e máximo de gasto) e detecção de falta de progresso (tocar repetidamente nos mesmos arquivos sem novos testes passando força uma parada). Com “os freios importam mais que o acelerador” bem compreendido, os quatro tipos de loop da Claude se tornam naturais — quatro respostas diferentes para “quem pisa no freio”.
Quatro Loops, Quatro Lógicas de Parada
Loops por turno: o freio é humano
A forma mais básica. Você escreve uma instrução, o agente executa um turno, você confere, escreve a próxima. Você segura o volante o tempo todo. Ideal para tarefas curtas e dispersas que nunca entram em um pipeline. A equipe do Claude Code sugere uma otimização: mover para um arquivo SKILL.md os passos que você normalmente confere manualmente e deixar o agente aceitar o próprio trabalho. Quanto mais quantificáveis forem suas verificações, mais o agente pode julgar a correção por si só — e menos você precisa supervisionar. Este é o ponto final do aprimoramento de prompts: não prompts mais longos, mas realocar a lógica de aceitação da sua cabeça para um arquivo.
Loops de objetivo: o freio é o avaliador
Fixe o objetivo primeiro — “fazer a pontuação Lighthouse da homepage passar de 90; parar após 5 tentativas”. Cada vez que a Claude quiser parar, um modelo avaliador separado julga de acordo com o seu padrão: abaixo da meta, ele volta ao trabalho até o objetivo ser atingido ou as tentativas se esgotarem. A elegância está na separação: o executor nunca discute se algo é bom o suficiente — o avaliador decide. Isso evita a autossatisfação prematura e dá ao loop um sinal limpo de terminação. Padrões quantificáveis — contagens de testes passando, limites de pontuação — são o habitat natural do loop de objetivo.
Loops temporizados: o freio é o relógio
Acionados por intervalo, como um alarme. Alguns trabalhos são repetitivos — a tarefa constante, mudando apenas a entrada (resumir o Slack toda manhã). Outros monitoram sistemas externos — o mais simples é verificar em uma programação. Use /loop para reexecutar um prompt em intervalos; use /schedule para mover o loop para a nuvem, de modo que ele rode enquanto sua máquina dorme. A lógica espelha o cron quase exatamente, com uma diferença: o cron dispara um script fixo, enquanto um loop temporizado dispara um fluxo de trabalho de IA que pode ajustar o próprio comportamento a cada despertar, com base no estado externo.
Loops proativos: o freio é o evento
Acionados por evento ou por tempo, totalmente sem supervisão. Combinados com o modo automático e fluxos de trabalho dinâmicos, cadeias longas se executam sozinhas: varrer o canal de feedback a cada hora; quando chega um relatório de bug, triar, corrigir e responder de ponta a ponta. Cada subtarefa encerra ao atingir seu objetivo; a rotina permanente roda até você desligá-la. O mais autônomo dos quatro — e o que melhor se encaixa em trabalho que chega continuamente, mas tem limites nítidos: triagem de bugs, classificação de issues, atualização de dependências.
O que a Divisão em Quatro Realmente Muda
Por turno, por objetivo, temporizado, proativo — quatro respostas para “quando ele deve parar”: o humano julga, o avaliador julga, o relógio julga, o evento julga. A importância não está em inventar conceitos novos — tarefas agendadas, orquestração e ciclos de feedback existem há anos. A Claude realizou uma taxonomia de engenharia: da mesma forma que a engenharia de software um dia classificou padrões de design, ela nomeou as unidades básicas da automação com IA para que as equipes possam discutir “você está usando um loop de objetivo ou um loop temporizado” em vez de descrever a mesma coisa com vocabulários diferentes.
E quando os loops se tornam unidades projetáveis, a verdadeira mudança é onde fica o centro de gravidade da programação: do design de conteúdo para o design de sistemas de comportamento. Antes, você desenhava o conteúdo de uma única instrução — “escreva Python que processe este CSV”. Agora, você desenha um sistema de comportamento — como ele dispara, como verifica, como se recupera de falhas, como para. O engenheiro deixa de ser “alguém que escreve código” e se torna “alguém que projeta sistemas de comportamento de IA”. A transição lembra a era da migração de monólitos para microsserviços, quando os desenvolvedores pararam de ajustar servidores individuais e passaram a se importar com orquestração, circuit breaking e tracing. A competência central da programação com IA está migrando de “escrever prompts mais precisos” para “projetar loops de comportamento de agente mais confiáveis”.
O Conceito Vai Além da Programação
Assista à recente entrevista de 26 minutos de Jensen Huang: nada de GPUs, nada de computação — uma palavra, Harness. Prompts, descrições de ferramentas, memória, gerenciamento de contexto, decomposição de tarefas, retentativas, avaliação, controle de permissões — o modelo raciocina; o harness organiza o raciocínio em trabalho aceitável. Um harness é o sistema de engenharia que coloca um modelo dentro de um loop maior. A LangChain combinou o Nemotron 3 Ultra com um harness para alcançar 0,86 na avaliação Deep Agents (pontuação máxima: 0,87), enquanto cortava o custo por execução de US$ 43 para US$ 4 — o mesmo modelo, um loop diferente ao redor dele.
A migração de prompt para loop está acontecendo em várias funções: gerentes de produto deixando de escrever PRDs para engenheiros e passando a desenhar loops de pesquisa → requisitos → validação; times de dados deixando de escrever SQL e passando a desenhar loops de coleta agendada → limpeza → análise → alerta; times de operações deixando de configurar regras de alerta e passando a desenhar loops de diagnóstico → localização → reparo → verificação com IA. Mesma moldura, formas diferentes — uma única lógica: quem primeiro decompõe seu fluxo de trabalho em unidades repetíveis sai do trabalho manual e entra no design de sistemas.
Por Onde Começar: Três Perguntas para Encontrar Seu Primeiro Loop
O conselho oficial do Claude Code é agradavelmente modesto: não faça engenharia excessiva no começo. Escolha um gargalo no que você já faz diariamente e faça três perguntas. Uma — verificação: consigo escrever a checagem? Aceitação difusa (“está com boa aparência”) desqualifica uma tarefa por ora; aceitação quantificável (“testes passando”, “API abaixo de 200ms”, “cobertura 5% acima”) marca um candidato a loop. Duas — objetivo: o enunciado do objetivo está claro o suficiente? “Otimizar o desempenho do sistema” não está; “fazer a homepage carregar em menos de 2 segundos” está. Objetivos vagos deixam tanto o modelo quanto você sem saber quando parar. Três — cadência: o trabalho chega em um ritmo fixo? Tarefas diárias, semanais e horárias formam loops com mais facilidade do que tarefas aleatórias — comece por aí e acumule experiência antes de encarar as não agendadas.
Um sim, e você encontrou seu primeiro loop delegável. Você não precisa saltar direto para loops proativos — começar por turnos, com critérios de aceitação escritos em um arquivo, já é um grande ganho de eficiência. A era dos prompts não vai desaparecer da noite para o dia. Mas seu centro de gravidade está se movendo — de “quem escreve melhor” para “quem desenha o loop mais confiável”.
Os verdadeiros projetistas de loops estão apenas agora entrando em cena.
Fontes: Claude Code Team, “Getting Started with Loops” (claude.com/blog, 2026) · Documentação do Claude Code Agent SDK, Agent Loop (code.claude.com) · Boris Cherny / Peter Steinberger no X, 2026 · Addy Osmani, “Loop Engineering”, 2026 · Entrevista de Jensen Huang × Harrison Chase sobre “Harness”, 2026
