A Anthropic paga aos seus engenheiros US$ 80.000 por mês. Esses engenheiros agora fazem o merge de 8x mais código por dia do que faziam há um ano. Não porque o modelo ficou mais inteligente. Mas porque eles pararam de fazer prompts para o Claude e começaram a construir sistemas que fazem prompts para eles.
Brian Cherny, chefe do Claude Code na Anthropic: "Eu não faço mais prompts para o Claude. Tenho loops rodando que fazem prompts para o Claude e descobrem o que precisa ser feito. Meu trabalho é escrever loops."
A maioria dos desenvolvedores lê isso e não faz ideia do que significa na prática. Ao final deste artigo, você saberá — e terá tudo o que precisa para construir o seu primeiro loop neste fim de semana.
O que é um loop, na verdade
Um prompt é uma instrução única. Um loop é um objetivo que a IA continua perseguindo até alcançá-lo.
A diferença é quem está no comando. Com um prompt, você guia o Claude manualmente em cada etapa. Com um loop, você define o objetivo uma vez e o sistema executa o ciclo completo por conta própria — encontrando o trabalho, executando-o, verificando o resultado e decidindo o que vem a seguir. Tudo isso sem você precisar estar na cadeira.
1Prompt | você digita, o Claude responde, você digita de novo2Loop | o sistema encontra o trabalho, o Claude executa,3 | o sistema verifica o resultado, repete até concluir
Todo loop real tem cinco estágios:
1Descoberta | encontrar o que precisa ser feito2Planejamento| decidir como fazer3Execução | fazer o trabalho4Verificação | conferir em relação ao objetivo5Iteração | não terminou? insira o resultado de volta e recomece
Três deles fazem todo o trabalho pesado.
A verificação é o coração. Sem uma checagem real do resultado, você não tem um loop — você tem o agente concordando consigo mesmo repetidamente. A checagem precisa ser objetiva. Um teste que passa ou falha. Um build que compila ou não. Um linter que retorna zero ou diferente de zero. Não um segundo agente solicitado a "revisar". Dois otimistas concordando não é verificação.
O estado é o que faz o loop aprender. A cada passagem, a IA precisa lembrar do que já tentou, ou repetirá o mesmo erro para sempre. Um loop real mantém um registro fora da conversa — o que foi feito, o que falhou, o que vem a seguir. O agente esquece entre as sessões. O arquivo, não.
Uma condição de parada é o que mantém a sanidade. Um loop sem saída roda até ter sucesso, quebrar ou esgotar seu orçamento. Todo loop sério tem duas formas de parar: sucesso e um limite rígido. Sem isso, você construiu uma máquina que cobra de você em silêncio.
O teste de 4 condições antes de construir qualquer coisa
Um loop só compensa seu custo quando todas estas quatro condições são verdadeiras. Se faltar uma, mantenha como um prompt manual.
1Condição 1 | a tarefa se repete pelo menos semanalmente2 | menos que semanalmente - o custo de configuração nunca se paga34Condição 2 | algo pode rejeitar automaticamente resultados ruins5 | um teste, build, linter, verificação de tipo6 | sem barreira automatizada - você volta a revisar cada diff78Condição 3 | o agente pode fazer o trabalho de ponta a ponta9 | não devolver metade para você no meio da tarefa1011Condição 4 | "concluído" é objetivo, não uma questão de opinião12 | se a qualidade for uma questão de gosto, um humano ainda vence
Bons primeiros loops:
1Triagem de falhas de CI | diariamente, classificar falhas, redigir correções2Atualização de dependências | semanalmente, escanear atualizações, abrir PRs3Passagens de Lint-and-fix | em cada PR, aplicar correções de estilo automaticamente4Rascunhos de Issue-para-PR | em bases de código com forte cobertura de testes
Loops ruins para começar - mantenha um humano no comando:
1Reescritas de arquitetura | questão de julgamento, o loop irá se desviar2Código de auth ou pagamentos | erros irreversíveis são caros demais3Deploys em produção | precisa de uma barreira de aprovação humana4Trabalho de produto vago | "concluído" não é objetivo
Os cinco blocos de construção
Todo loop funcional é montado a partir de cinco partes. O Claude Code oferece todas as cinco.
1 - A automação (o batimento cardíaco)
É isso que torna um loop um loop de fato e não apenas uma execução que você fez uma vez. Um gatilho dispara em um cronograma ou evento, entrega a tarefa ao Claude e traz os resultados de volta sem que você precise ficar checando.
1/loop | reexecuta um prompt em um ritmo definido2/goal | continua até que uma condição que você escreveu seja verdadeira3hooks | disparam comandos em pontos do ciclo de vida do agente4cron | roda após você fechar o laptop via GitHub Actions
O mais importante é o /goal. Um modelo pequeno e separado verifica se a condição foi atendida — assim, o agente que escreveu o código não é o mesmo que o avalia.
1/loop 30m /goal "Todos os testes em test/auth passam e o lint está limpo."2Escanear src/auth por falhas, redigir correções, abrir PR quando o objetivo for atingido.
2 - Habilidades (escreva o conhecimento do projeto uma vez)
Uma habilidade é como você para de explicar o mesmo contexto de projeto a cada sessão. Um arquivo SKILL.md contém as instruções, convenções e regras que o loop lê a cada execução.
Sem habilidades, o loop redescobre todo o seu projeto do zero a cada ciclo. Com habilidades, a intenção se acumula — as convenções, os passos de build, as coisas que deram errado antes — escritas uma vez, lidas para sempre.
1skills/2 ci-triage.md - regras de classificação, padrões de correção, critérios de escalonamento3 frontend.md - Tailwind, Next.js, SEO, regras de acessibilidade4 security.md - padrões de auth, validação de input, lista de "não tocar"5 deps.md - regras de atualização, verificações de compatibilidade, padrões de rollback
A automação chama a habilidade pelo nome. O trabalho recorrente permanece sustentável em vez de apodrecer dentro de um cronograma que ninguém atualiza.
3 - Sub-agentes (mantenha o criador longe do verificador)
A coisa estrutural mais útil em qualquer loop. Separe o agente que escreve do agente que verifica.
O modelo que escreveu o código é generoso demais ao avaliar seu próprio trabalho. Um segundo agente com instruções diferentes — e às vezes um modelo mais forte — detecta o que o primeiro convenceu a si mesmo de que estava certo.
1Agente criador | modelo rápido e barato - explora, implementa, redige2Agente checador | modelo forte, alto esforço - revisa, verifica, rejeita
1.claude/agents/2 explorer.md | somente leitura, modelo rápido, encontra o que precisa ser feito3 implementer.md | escreve a correção, roda os testes4 reviewer.md | auditoria de segurança, qualidade de código, barreira objetiva
Um modelo. Três especialistas. O loop roda enquanto você não está olhando e o verificador é a única razão pela qual você pode realmente se afastar.
4 - Conectores (para que ele aja, não apenas sugira)
A diferença entre um loop que diz "aqui está a correção" e um loop que abre o PR, vincula o ticket e avisa no Slack assim que o CI estiver verde.
1GitHub | ler repos, criar branches, abrir PRs, reagir a webhooks2Linear | atualizar tickets, vincular PRs, fechar itens quando a verificação passar3Slack | postar resultados de triagem, avisar humanos sobre escalonamentos4Sentry | investigar alertas ao vivo, redigir correções para os de alta frequência
Sem conectores, o loop descreve o que faria. Com conectores, ele faz.
5 - O arquivo de estado (o agente esquece. O arquivo, não.)
A peça que parece simples demais para importar, mas é a espinha dorsal de todo loop funcional. Um arquivo markdown fora da conversa que registra o que foi feito, o que falhou e o que vem a seguir.
1# Estado do loop - ci-triage23## Última execução42026-06-09 03:30 UTC - 7 falhas classificadas, 3 correções redigidas, 4 escalonadas56## Em progresso7- claude/fix-auth-token-refresh - testes passando localmente, aguardando CI89## Concluído hoje10- claude/bump-axios-1.7.4 - mergeado, CI verde1112## Escalonado para humanos13- src/billing/refund.ts - testes falhando de 3 formas, causa raiz incerta1415## Lições aprendidas16- 2026-06-08: PowerShell apresenta problema de TLS no runner Windows. Use bash.17- 2026-06-07: tests/e2e/checkout requer segredo de webhook do Stripe. Pular se ausente.
A execução de amanhã lê este arquivo e retoma de onde parou. Sem ele, cada execução recomeça do zero.
Como é um loop real
Triagem de falhas de CI — um dos melhores primeiros loops porque a verificação é automática e os riscos de um resultado ruim são baixos.
1Gatilho | diariamente às 3 da manhã ou em evento de falha de CI2Habilidade | ci-triage.md3Leitura de estado | STATE.md - o que falhou ontem, o que foi corrigido
O loop roda:
1Passo 1 | lê falhas de CI do GitHub via conector2Passo 2 | classifica cada uma: env / flake / bug / dependência / infra3Passo 3 | para cada falha corrigível - abre worktree, envia agente implementador4Passo 4 | agente revisor checa a correção contra testes e regras de segurança5Passo 5 | barreira passa - abre PR e vincula ticket do Linear6Passo 6 | barreira falha - escala para a caixa de entrada de triagem humana7Passo 7 | atualiza STATE.md8Passo 8 | posta resumo noturno no Slack
Pela manhã, você acorda com uma mensagem no Slack, uma caixa de entrada de triagem apenas com os problemas difíceis e um conjunto de PRs que já passaram pela revisão automatizada. Você não precisou dar um único prompt.
O loop que gera valor composto em todo o negócio
A versão mais poderosa não é um único loop. São múltiplos loops escrevendo em um sistema de artefatos compartilhado para que aprendam uns com os outros.
Na SuperDesign, seus loops cobrem suporte, SEO, crescimento de produto e anúncios. Cada um tem seu próprio gatilho e fluxo de trabalho. Mas todos escrevem no mesmo repositório de sinais compartilhado.
O loop de suporte nota cinco usuários perguntando como exportar algo. Ele cria um sinal:
1tipo: sinal2título: Exportar é difícil de encontrar3frequência: 54categoria: atrito5tags: [feedback, precificação, conversão]
O loop de SEO nota uma página com tráfego forte, mas conversão ruim. Cria outro sinal. O loop de crescimento de produto lê ambos os sinais junto com a análise de dados e identifica que o atrito na exportação é maior do que os dados brutos sugeriam — porque agora duas fontes independentes confirmam o mesmo problema. O loop de anúncios encontra uma lacuna de palavras-chave e a insere diretamente no loop de SEO.
1Loop de suporte | encontra atrito, escreve sinal2Loop de SEO | encontra lacuna de conteúdo, escreve sinal3Loop de produto | lê ambos os sinais, identifica prioridade4Loop de anúncios| encontra lacuna de palavras-chave, alimenta loop de SEO
Nenhum desses loops são automações isoladas. Eles operam a partir de uma base de conhecimento compartilhada do que o negócio está aprendendo. Cada loop torna todos os outros mais inteligentes. Isso é valor composto.
As falhas sobre as quais ninguém te avisa
O loop Ralph Wiggum. Um agente destinado a sinalizar conclusão apenas quando terminar, sinaliza antes da hora. O loop sai do trabalho pela metade e continua rodando e cobrando enquanto não produz nada. Correção: uma barreira rígida que pode reprovar o trabalho objetivamente, não um "parece bom para mim" subjetivo.
Desvio de objetivo em sessões longas. As restrições desaparecem por volta do turno 47 à medida que o contexto se resume. Correção: um AGENTS.md permanente que o agente relê no início de cada execução.
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 existe e o que você entende. A conta que dói não é a de tokens. É o dia em que você depura um sistema que ninguém na equipe leu. Correção: leia cada diff que o loop abre.
Rendição cognitiva. A vontade de parar de formar uma opinião e aceitar o que o loop retorna. Projetar o loop é a cura quando você faz isso com julgamento, e o acelerador quando você faz isso para evitar pensar. Mesma ação, resultado oposto.
Custos de token que se acumulam. Cada iteração do loop rele o contexto completo e a pilha cresce a cada passagem. Acompanhe o custo por mudança aceita. Abaixo de 50% de taxa de aceitação, o loop custa mais do que economiza.
A ordem de construção que realmente funciona
Todos que entregam loops que sobrevivem em produção fazem da mesma maneira:
1Passo 1 | torne UMA execução manual confiável primeiro2Passo 2 | transforme-a em uma habilidade - salve as instruções em SKILL.md3Passo 3 | envolva a habilidade em um loop - adicione a barreira e a condição de parada4Passo 4 | ENTÃO coloque em um cronograma
Agendar algo que você não tornou confiável manualmente é exatamente como os loops explodem enquanto você dorme. Prove uma vez. Reforce. Então automatize.
A métrica que importa não é tokens gastos ou tarefas tentadas. É o custo por mudança aceita. Se o loop te dá dez resultados e você rejeita seis, você está fazendo o trabalho de revisão que ele deveria economizar.
A mudança que já aconteceu
Em 2024, a alavancagem estava no prompt. Melhor prompt, melhor resultado, melhor desenvolvedor. Em 2026, a alavancagem está um andar acima — o sistema que decide no que o Claude trabalha, quando, com qual barreira e qual estado sobrevive entre as execuções.
Os engenheiros da Anthropic fazem o merge de 8x mais código por dia não porque encontraram uma maneira melhor de fazer perguntas ao Claude. Mas porque pararam de fazer perguntas e começaram a construir sistemas que fazem perguntas ao Claude em seu nome — continuamente, durante a noite, enquanto dormem.
O loop não torna o trabalho mais fácil. Ele muda onde o trabalho acontece. De digitar prompts para projetar o sistema que digita prompts. De segurar a ferramenta para construir a fábrica.
A maioria dos desenvolvedores continuará fazendo prompts manualmente e se perguntando por que a lacuna continua aumentando. Alguns passarão um fim de semana construindo seu primeiro loop — uma automação, uma habilidade, um arquivo de estado, uma barreira — e nunca mais olharão para trás.
