A Anthropic paga aos seus engenheiros 80.000 dólares por mês. Esses engenheiros agora integram 8 vezes mais código por dia do que faziam há um ano. Não porque o modelo ficou mais inteligente. Mas porque pararam de enviar prompts ao Claude e começaram a construir sistemas que enviam prompts por eles.
Brian Cherny, chefe do Claude Code na Anthropic: "Eu não envio mais prompts ao Claude. Tenho loops em execução que enviam prompts ao 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 neste fim de semana.
O que é um loop, na verdade
Um prompt é uma instrução única. Um loop é um objetivo no qual a IA continua trabalhando até alcançá-lo.
A diferença está em 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 novamente2Loop | o sistema encontra 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 | realizar 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 real.
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. Uma compilação que funciona 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 o 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 | sem devolver metade para você no meio da tarefa1011Condição 4 | "concluído" é objetivo, não uma questão de opinião12 | se a qualidade é subjetiva, um humano ainda vence
Bons primeiros loops:
1Triagem de falhas de CI | diariamente, classifica falhas, rascunha correções2Atualização de dependências | semanalmente, verifica atualizações, abre PRs3Passagens de Lint-e-fix | em cada PR, aplica 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 traz as cinco.
1 - A automação (o batimento cardíaco)
É isso que torna um loop um loop real e não apenas uma execução única. Um gatilho dispara em um cronograma ou evento, entrega a tarefa ao Claude e traz os resultados de volta sem que você precise verificar.
1/loop | reexecuta um prompt em um intervalo2/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 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, rascunhar 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 rederiva 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 entrada, 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 — captura o que o primeiro justificou para si mesmo.
1Agente Criador | modelo rápido e barato - explora, implementa, rascunha2Agente Verificador | 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, rascunhar correções para os frequentes
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 rascunhadas, 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 tem 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. 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 3h 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 verifica a correção contra testes e regras de segurança5Passo 5 | barreira passa - abre PR e vincula ticket 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 problemas difíceis e um conjunto de PRs que já passaram por revisão automatizada. Você não enviou 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 baixa. Cria outro sinal. O loop de crescimento de produto lê ambos os sinais junto com a análise e identifica que o atrito de 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 sobre o 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 terminado, sinaliza cedo demais. 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 falhar objetivamente o trabalho, não um "parece bom para mim" suave.
Desvio de objetivo em sessões longas. As restrições desaparecem no turno 47 conforme 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 abrir.
Rendição cognitiva. A tentação de parar de formar uma opinião e aceitar o que o loop retornar. 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 tokens que se acumulam. Cada iteração do loop relê o contexto completo e a pilha cresce a cada passagem. Acompanhe o custo por alteração 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 forma:
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 condição de parada4Passo 4 | ENTÃO coloque em um cronograma
Agendar algo que você não tornou confiável manualmente é exatamente como 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 alteração aceita. Se o loop te dá dez resultados e você rejeita seis, você está fazendo o trabalho de revisão que deveria ter sido poupado.
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 integram 8 vezes 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á enviando 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.





