Engenharia de loops: loops, rotinas e workflows do Claude Code

TL;DR: Engenharia de loops é a disciplina de fazer agentes repetirem ciclos de trabalho até que uma condição de parada seja atendida — em vez de instruí-los uma interação por vez. Boris Cherny, da Anthropic e criador do Claude Code, descreve o próprio fluxo de trabalho sem rodeios: “Eu não dou mais prompts ao Claude. Tenho loops em execução. São eles que dão prompts ao Claude e decidem o que fazer. Meu trabalho é escrever loops.”¹ O Claude Code agora oferece uma hierarquia completa de recursos para loops — /goal (repete até que um modelo separado confirme uma condição), /loop (execuções locais recorrentes), o plugin oficial Ralph (itera até que uma promessa seja cumprida), rotinas (cron na nuvem) e workflows dinâmicos (o Claude escreve um grafo de orquestração JavaScript e executa até 1.000 subagents com base nele). Nenhum desses recursos é o que sustenta todo o sistema: esse papel cabe à verificação. Um loop só converge quando algo fora do gerador — um teste, um modelo avaliador, uma comparação de pixels, uma verificação automatizada — determina que o trabalho está “concluído”. Faça isso direito e os ganhos dos loops se acumulam; faça errado e você terá uma caminhada aleatória caríssima. Este guia aborda todos os recursos para loops com referências de versão, o padrão Ralph e seus modos de falha, quando loops precisam se transformar em grafos, a hierarquia de verificação, a disciplina de custos e segurança e como manter uma frota permanente em operação. Atualizado para o Claude Code v2.1.234 (agosto de 2026).

O que é loop engineering?

Há dois anos, engenheiros escreviam código-fonte à mão. Depois, agentes passaram a escrever o código a partir de prompts humanos. A mudança em curso agora acontece um nível acima: agentes criam prompts para outros agentes, e o humano escreve o sistema que decide quais prompts serão enviados. Cherny avalia diretamente o tamanho dessa transformação: “Assim como a passagem do código-fonte para os agentes foi enorme, os loops são igualmente importantes e representam uma mudança tão grande quanto.”²

Sua definição é surpreendentemente simples: “Um loop é essencialmente um cron job executado localmente pelo Claude. Uma routine é a mesma coisa, mas executada na nuvem.”³ Essa prática aparentemente exótica — “centenas, às vezes milhares de agentes trabalhando por 5, 10 ou 20 horas” durante a noite,⁴ Claude Code “100% escrito pelo Claude Code há mais de seis meses”⁴ — resume-se a um pequeno conjunto de elementos básicos: um prompt disparado novamente conforme um cronograma ou uma condição, um estado que persiste entre as iterações e uma verificação que encerra a execução.

Anthropic deu nome à disciplina em junho de 2026: loops são “agentes que repetem ciclos de trabalho até que uma condição de parada seja atendida”, e “a qualidade do resultado de um loop depende do sistema ao redor dele”.⁵ Este guia trata justamente desse sistema.

Uma observação sobre a origem dos termos, porque a discussão avançou rapidamente em meados de 2026: o termo “graph engineering” — muitas vezes atribuído a Cherny em publicações virais — foi cunhado pela comunidade (na publicação de Peter Steinberger de 18 de julho, “ainda estamos falando de loops ou já migramos para graphs?”, amplificada por Hamel Husain), não pelo Anthropic nem por Cherny.⁶ A citação amplamente compartilhada “85% dos nossos engenheiros… a maneira de fazer isso é graph engineering” circula apenas em publicações de terceiros; ao preparar este guia, não conseguimos localizá-la em nenhum registro primário de suas palestras (a conversa na YC Startup School, o Odd Lots da Bloomberg e a reportagem da TechCrunch sobre o Meta @Scale), portanto, trate essa atribuição como não verificada. Sua prática real tem o formato de um graph (orquestradores que iniciam subagents implementadores, verificadores e corretores, aninhados até a profundidade 5), mas o vocabulário verificado é loops, routines e workflows — e é esse o vocabulário usado neste guia.

Caminho ideal em cinco minutos

Três comandos levam você dos prompts aos loops:

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

A diferença entre eles e um prompt é estrutural, não cosmética: cada um tem uma regra de novo disparo (uma condição, um relógio ou um cron) e precisa de uma regra de parada. Todo o restante deste guia explica como tornar essas duas regras confiáveis.

O loop central e a regra fundamental

Todo sistema de agentes executa o mesmo ciclo interno, que a documentação do Agent SDK do Anthropic consagra como coletar contexto → agir → verificar o trabalho → repetir.⁷ O próprio processo do Claude Code é um loop: avaliar o prompt, chamar ferramentas, ler os resultados e repetir até que uma resposta não tenha chamadas de ferramentas.⁸

Loop engineering envolve esse ciclo interno com loops externos — e herda sua única regra inegociável, reafirmada por todas as fontes sérias da área:

O agente que realiza o trabalho nunca o avalia.

• Documentação do /goal do Anthropic: “a conclusão é decidida por um modelo novo, não pelo modelo que realiza o trabalho”.⁹
• Ensaio do Anthropic sobre design de harness: “Separar o agente que realiza o trabalho daquele que o avalia é uma ferramenta poderosa para lidar com esse problema.”¹⁰
• Cherny, sobre o que os profissionais deixam passar: “A verificação provavelmente é o aspecto mais importante que as pessoas não fazem direito.”³ Em seu exemplo prático, ao instruir uma migração de Electron para Swift em duas semanas: “execute o aplicativo Electron na máquina virtual Mac, faça uma captura de tela e examine-a pixel por pixel. Compare-a com a versão em Swift. Não pare até terminar.”³

A razão é mecânica, não moral: um modelo ao qual se pergunta “você terminou?” apresenta um viés positivo de autoavaliação, e uma transcrição confiante pode convencer uma condição de saída avaliada por modelo a declarar “concluído” antes da hora.¹¹ A verificação externa — uma suíte de testes, um compilador, uma comparação de pixels ou um modelo novo sem interesse na resposta — é o único sinal que resiste a isso.

A escada da autonomia

As superfícies de loop no Claude Code formam uma escada que vai de “pressione Enter novamente” a “é executado sem você”. Cada degrau troca mais autonomia por uma carga maior de verificação:

(A estrutura em degraus segue a taxonomia de julho de 2026 do pardel.dev, o mapa independente mais claro desse espaço.¹¹)

A disciplina dessa escada: comece no degrau mais baixo que resolva seu problema e só avance quando a verificação desse degrau estiver comprovada. Um /goal cuja condição não possa ser expressa como algo verificável ainda não está pronto para se tornar uma routine.

As superfícies de loop em detalhes

(Este guia aborda as próprias superfícies de loop. O guia do Claude Code é a referência completa do CLI — configurações, permissões, hooks, MCP — e o guia de arquitetura de agentes explica como os componentes do harness se combinam; os loops são executados sobre ambos.)

/goal — o loop avaliador-otimizador

/goal <condition> mantém o Claude trabalhando até que a condição seja atendida: “Após cada turno, um modelo pequeno e rápido verifica se a condição foi atendida. Caso contrário, o Claude inicia outro turno em vez de devolver o controle a você.”⁹ O avaliador (Haiku por padrão) responde sim ou não e apresenta um motivo que o Claude usa como orientação para o próximo turno. Ele também funciona em modo headless: claude -p "/goal ..." executa o loop até a conclusão.

Notas de elaboração: torne a condição observável (“os testes passam”, “o endpoint retorna 200”, “zero erros de TypeScript”), não aspiracional (“o código está limpo”). Um verificador vago não oferece direção ao loop — e uma transcrição confiante pode persuadir uma condição avaliada por modelo a concordar, portanto, combine /goal com uma verificação automatizada sempre que houver uma disponível.¹¹

Duas mudanças na v2.1.234 tornam o próprio loop mais robusto. Agora, um goal é removido, com uma notificação, quando um turno é encerrado por um erro irrecuperável — autenticação revogada, saldo de créditos esgotado ou estouro de contexto — em vez de continuar ativo em uma sessão que não consegue mais agir. Além disso, quando tarefas em segundo plano mantêm um goal aguardando por mais de 30 minutos, o Claude verifica o andamento delas em vez de esperar indefinidamente (CLAUDE_CODE_GOAL_CHECKIN_MINUTES ajusta o limite; 0 restaura o comportamento anterior de esperar para sempre).³³

/loop — execuções locais recorrentes

/loop [interval] <prompt> executa novamente um prompt conforme um cronograma: fixo (/loop 5m check the deploy), em ritmo próprio (o Claude escolhe o próximo intervalo com base no que observou) ou apenas /loop para uma rotina de manutenção integrada. Nos bastidores estão CronCreate/CronList/CronDelete (cron de 5 campos, 50 tarefas por sessão e expiração em 7 dias) e a ferramenta Monitor, que transmite a saída de um script em segundo plano em vez de fazer polling.¹² O próprio exemplo de lançamento de Cherny: “/loop cuide de todos os meus PRs. Corrija automaticamente os problemas de build e, quando surgirem comentários, use um agente em uma worktree para resolvê-los.”¹³

A limitação relevante: /loop existe dentro da sua sessão. Feche o terminal e o loop será encerrado — é para isso que servem as routines.

O plugin Ralph — iterar até cumprir a promessa

O plugin oficial ralph-wiggum do Anthropic transforma em produto o padrão de força bruta favorito da comunidade: um Stop hook intercepta a tentativa do Claude de encerrar a sessão e reinsere o prompt, fazendo o modelo iterar continuamente em uma única sessão. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" inicia o processo; /cancel-ralph o interrompe. O README deixa claro que --max-iterations é “seu principal mecanismo de segurança” — a correspondência exata da string de conclusão pode falhar para sempre.¹⁴

Workflows dinâmicos — o Claude escreve o graph

Introduzidos no Claude Code v2.1.154 (maio de 2026) e detalhados na publicação de lançamento do Anthropic de 2 de junho de 2026, os workflows dinâmicos representam o maior salto conceitual: “agora, o Claude pode escrever seu próprio harness em tempo real, criado especificamente para a tarefa em questão”.¹⁵ Você descreve a tarefa (ou simplesmente diz “use um workflow”); o Claude escreve um script de orquestração em JavaScript — agent() inicia um subagent com saídas opcionais no schema do JSON, pipeline() conduz itens por etapas, e await/loops/condicionais comuns controlam o fluxo — e um runtime o executa em segundo plano. “Um workflow transfere o plano para o código… O próprio script do workflow mantém o loop, as ramificações e os resultados intermediários, de modo que o contexto do Claude contenha apenas a resposta final.”¹⁶

Limites e formato: 16 agentes simultâneos, 1.000 por execução (“evita loops descontrolados”), sem entrada do usuário durante a execução; scripts salvos em .claude/workflows/ tornam-se comandos slash reutilizáveis; as execuções podem ser retomadas com os resultados dos agentes armazenados em cache.¹⁶ A topologia característica é distribuir / refutar / convergir: agentes de busca independentes, seguidos por verificadores adversariais instruídos a refutar cada descoberta, iterando até que as respostas resistam às contestações. O principal resultado divulgado no lançamento: a migração para Rust da base de código de 535.496 linhas em Zig do Bun — resultando em uma base de código Rust com mais de 1 milhão de linhas — em 11 dias (de 3 a 14 de maio de 2026), realizada por 64 agentes em paralelo, segundo o relato de Jarred Sumner.¹⁵

Agent teams — o graph entre pares

Por trás de CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (research preview desde a v2.1.32, fevereiro de 2026): um líder de equipe e colegas que “trabalham de forma independente, cada um em sua própria janela de contexto, e se comunicam diretamente entre si” — um graph entre pares em vez de uma árvore de subagents, coordenado por meio de uma lista compartilhada de tarefas com dependências, reivindicação de arquivos por bloqueio e caixas de mensagens por agente. Quality gates impostas por hooks (TaskCompleted com código de saída 2 bloqueia) colocam verificações automatizadas entre um colega de equipe e a declaração de “concluído”.¹⁷

Routines — loops que continuam após você fechar o laptop

Uma routine é “uma configuração salva do Claude Code: um prompt, um ou mais repositórios e um conjunto de conectores, agrupados uma vez e executados automaticamente” na nuvem gerenciada pelo Anthropic ou em seus próprios runners self-hosted.¹⁸ Há três tipos de gatilho, que podem ser combinados: agendamento cron (mínimo de 1 hora), disparo por API (POST .../routines/{id}/fire) e eventos de GitHub. São criadas por meio de /schedule ou claude.ai/code/routines. As execuções ocorrem de forma autônoma — sem prompts de aprovação — e é exatamente por isso que a ressalva da documentação é essencial: um status de execução verde “não significa que a tarefa do seu prompt foi bem-sucedida. Abra a execução, leia a transcrição e confirme o que o Claude realmente fez.”¹⁸

O Anthropic executa “talvez 20 ou 30 dessas routines todos os dias” em suas próprias bases de código — limpeza de código morto, cobertura de testes e lançamento de experimentos.³

O elenco de apoio

Subagents em segundo plano (padrão desde a v2.1.198) mantêm o trabalho delegado fora do seu contexto; o painel /agents permite monitorá-los. Mensagens entre sessões (v2.1.224) transformam sessões independentes em um graph de troca de mensagens por meio de SendMessage, com uma doutrina de segurança que vale a pena adotar: uma mensagem de outra sessão “nunca conta como seu consentimento”.¹⁹ Runners self-hosted (v2.1.224, Team/Enterprise) executam sessões e routines na nuvem usando suas próprias máquinas — a infraestrutura para frotas em escala organizacional.²⁰

O Ralph Pattern

A comunidade chegou primeiro. Em julho de 2025, Geoffrey Huntley publicou o ensaio que batizou a técnica em homenagem ao personagem de Os Simpsons: Ralph é literalmente

while :; do cat PROMPT.md | claude-code ; done

— sua frase de uma linha exatamente como foi publicada — um repositório, uma tarefa por iteração, contexto novo a cada passagem, com arquivos de especificações e progresso no sistema de arquivos mantendo o estado entre as iterações e testes/linters atuando como “contrapressão”.²¹ A forma headless moderna da mesma estrutura é claude -p "$(cat PROMPT.md)" em um loop de shell, que é essencialmente o que o próprio harness de compilador C da Anthropic executou.²³ Os resultados que ele alegou ter alcançado (o MVP de um contrato de US$ 50 mil por US$ 297 em tokens; seis repositórios durante uma noite em um hackathon) vieram acompanhados de limites igualmente claros: apenas projetos greenfield, implementações com placeholders e duplicadas como modos de falha recorrentes e “LLMs são espelhos da habilidade do operador”.

A Anthropic nunca usa esse nome em seu material de engenharia, mas o padrão agora é doutrina oficial em duas frentes: o ensaio de novembro de 2025 sobre agentes de longa duração prescreve exatamente essa estrutura — um agente inicializador criando listas de recursos e arquivos de progresso, seguido por novos agentes de programação em cada janela de contexto que “iniciam a sessão lendo o arquivo de notas de progresso e os logs de commit do git”²² — e o projeto do compilador C de fevereiro de 2026 executou dezesseis agentes Claude em paralelo — “criei um harness que coloca a Claude em um loop simples”, como descreve Nicholas Carlini — com bloqueios de tarefas baseados em arquivos e o git como camada de sincronização, produzindo cerca de 100 mil linhas de Rust em aproximadamente 2.000 sessões por cerca de US$ 20 mil.²³ A frase do ensaio sobre verificação resume toda a teoria do padrão: “é importante que o verificador de tarefas seja quase perfeito”.

Por que um contexto novo supera uma única sessão longa: a eficácia diminui à medida que o contexto de uma sessão fica cheio — o consenso entre profissionais coloca o limiar de desvio em torno de 100 mil tokens — e os resumos de compactação são paráfrases com perdas que transformam erros em prosa confiante.²⁴ O design de Ralph, com novas instâncias e arquivos, evita ambos. (O looping na mesma sessão do plugin oficial abre mão de parte disso em troca de conveniência; para execuções longas, a forma headless com estado externo continua sendo o padrão mais robusto.)

O alerta deixado pelo padrão também é instrutivo: um profissional executou o plugin com um prompt vago e max_iterations: 0 — que significa infinito, não desativado — e a Claude fez a si mesma a mesma pergunta de esclarecimento 1.966 vezes, enquanto o Stop hook sequestrava todas as mensagens seguintes.²⁵ Limites de iteração não são opcionais.

Quando loops se tornam grafos

Um único loop pressupõe que suas iterações sejam independentes ou estritamente sequenciais. No momento em que um trabalho paralelo tem dependências — a tarefa B precisa da saída da A, dois agentes editariam o mesmo arquivo — loops livres entram em conflito, e você precisa de uma estrutura explícita: uma lista de tarefas com arrays de dependências, reivindicação de arquivos e disciplina de merge. Esse é o verdadeiro conteúdo do debate entre loops e grafos: loops para um repositório e um objetivo; grafos quando o trabalho paralelo exige ordenação.²⁶

As opções de grafos, em ordem crescente de infraestrutura:

1. Workflows dinâmicos — dependências expressas no fluxo de controle da JavaScript; barreiras apenas quando uma etapa realmente precisa de todos os resultados anteriores. As topologias nomeadas pela Anthropic: distribuir e sintetizar, verificação adversarial, gerar e filtrar, torneio (“Inicie N agentes para que cada um tente realizar a mesma tarefa usando abordagens diferentes” e depois julgue-os em pares) e loop até concluir.¹⁵
2. Equipes de agentes — uma lista compartilhada de tarefas com rastreamento de dependências e um líder que aprova os planos; o grafo é composto por dados, não por código.¹⁷ Um padrão mudou nessa configuração: desde a v2.1.233, as ferramentas de tarefas (TaskCreate/Get/Update/List, TodoWrite) ficam desativadas por padrão no Opus 4.8, Sonnet 5, Fable 5 e versões posteriores — a documentação deixa explícito que agentes sem as ferramentas Task “se coordenam por mensagens, em vez da lista compartilhada de tarefas”; portanto, em uma configuração padrão da geração atual, a lista de tarefas simplesmente não existe, sem qualquer aviso. Defina CLAUDE_CODE_ENABLE_TODO_TOOLS=1 para restaurá-la.³³
3. Orquestradores externos — a expansão em escala da comunidade: o Gas Town de Steve Yegge executa de 20 a 30 instâncias da Claude Code em DAGs de “beads” respaldados pelo git (75 mil linhas de Go em 17 dias; segundo seu próprio relato, também “um devorador de dinheiro” que exige muita habilidade do operador);²⁷ o claude-flow/Ruflo (cerca de 31 mil estrelas) organiza swarms em uma hierarquia de rainha/trabalhadores; engines no estilo LangGraph acrescentam uma máquina de estados tipada por cima, com a Claude Code dentro dos nós.

A própria formalização de Cherny para essa trajetória é a escala Steps of AI Adoption, publicada pela Anthropic em julho de 2026: Controlado (0 agentes) → Assistido (cerca de 1) → Paralelo (cerca de 10) → Autonomia supervisionada (cerca de 100, quando “a maioria dos agentes é iniciada pela Claude, não por humanos”) → Nativo em IA (mais de 1.000). Seu conselho: “em cada etapa… você precisa encontrar e eliminar o próximo conjunto de gargalos e construir o próximo conjunto de proteções”.²⁸

Engenharia de verificação

Tudo o que veio antes é infraestrutura. Esta seção é o produto.

A escala de progressão da Anthropic, segundo o documento atual de práticas recomendadas: dê à Claude algo que produza um resultado de aprovação ou reprovação e “o loop se fecha sozinho” → uma condição /goal reavaliada por um avaliador separado → um Stop hook como “uma barreira determinística” → “um subagent de verificação ou um workflow dinâmico que confira as próprias conclusões faz com que um novo modelo tente refutar o resultado, para que o agente que realiza o trabalho não seja o mesmo que o avalia”.²⁹ A norma de evidências associada: “Faça a Claude mostrar evidências em vez de apenas afirmar que teve sucesso”.

As três classes de feedback, segundo o ensaio sobre Agent SDK: feedback baseado em regras (“regras claramente definidas para uma saída, seguidas de uma explicação sobre quais regras falharam e por quê” — a melhor forma), feedback visual (capturas de tela, diffs de pixels) e LLM como avaliador (rubricas imprecisas — nas palavras da Anthropic, “geralmente não é um método muito robusto”).⁷ Prefira-as nessa ordem; uma verificação determinística existente supera um avaliador que apenas dá sua opinião.

Condições de convergência. A análise crítica mais incisiva sobre loops — publicada por Yoko Li em agosto de 2026 — reduz a convergência a quatro requisitos: um estado-alvo definido, um estado atual observável, edições locais precisas e regras de parada externas ao gerador. O número mais marcante de seu experimento instrumentado: 67% dos tokens gastos pelo loop não produziram nenhuma melhoria, porque nada informava ao loop que os retornos haviam se tornado logarítmicos.³⁰ Limites de orçamento não são apenas controle de custos; são uma regra de parada de último recurso.

Integridade dos testes. Segundo a doutrina da Anthropic para agentes de longa duração: “É inaceitável remover ou editar testes, pois isso pode resultar em funcionalidades ausentes ou com bugs”.²² Loops exploram as especificações — passam nos testes visíveis enquanto falham na intenção oculta —, portanto, o próprio verificador precisa ser protegido do agente que ele avalia.

Avalie os resultados, não os caminhos. Segundo o ensaio sobre evals: “Avalie o que o agente produziu, não o caminho que ele percorreu”, use avaliadores baseados em código quando o critério for objetivo e avaliadores baseados em modelos para rubricas, além de calibrá-los: “Você não saberá se seus avaliadores estão funcionando bem sem ler as transcrições e as notas de muitas tentativas”.³¹

Há ainda outra distinção ignorada pela maior parte das discussões: quando todas as verificações de um loop são determinísticas, nenhum modelo deveria fazer parte dele. Um monitor de desvio que compara timestamps, um verificador de links, um sentinela de build — tudo isso são scripts de shell executados em uma programação: zero tokens, segundos por execução e repetibilidade perfeita. Reserve loops orientados por modelos para iterações que exigem julgamento. O loop mais barato é aquele que nunca chama um modelo.

Disciplina de custos e segurança

A objeção mais frequente da comunidade à engenharia de loops é o custo, e os relatos de incidentes confirmam essa preocupação: um bug de criação de subagents consumindo 4 milhões de tokens em cinco minutos; loops noturnos gastando milhares de dólares; limites de uso atingidos “muito mais rápido do que o esperado”.³² Uma dessas barreiras mudou desde então: a partir da v2.1.234, uma sessão continua automaticamente quando o limite de uso do claude.ai é redefinido (desative em /config → “Continue automatically at usage limit”) — um loop noturno que antes encerrava ao atingir o limite agora é retomado quando a janela reabre, o que torna os controles de orçamento abaixo mais importantes, não menos.³³ A disciplina resultante, com cada item associado a um controle já disponibilizado:

Essa última linha merece um parágrafo próprio, pois explica como os profissionais mais agressivos mantêm a segurança: transforme a pull request no raio de impacto. Os agentes permanentes em segundo plano de Cherny — um melhorando continuamente a arquitetura, outro procurando abstrações duplicadas — enviam PRs sem acionamento humano;² nada é integrado sem revisão. Um loop sempre ativo cujo pior caso é “uma branch não integrada” pode operar intensamente; um loop que grava na main, não. Promova loops gradualmente: comece apenas com observação (relatórios, sem gravações), conquiste confiança ao longo de execuções monótonas e só então avance para a proposição de mudanças — com a prova de ordenação (“a limpeza só é executada depois que a verificação retorna o novo marcador”) e uma declaração completa do raio de impacto registradas antes da instalação do agendamento. A economia desse caminho de promoção é o tema de Loops vencem quando a verificação é barata: o custo da verificação, não a construção do loop, determina o que pode ser executado sem supervisão.

A objeção mais profunda não é o custo, mas a capacidade de revisão — loops produzem código mais rápido do que humanos conseguem revisá-lo de forma significativa.³⁴ Não existe uma resposta engenhosa; existe apenas honestidade quanto ao escopo: loops sem supervisão pertencem exatamente aos cenários em que a verificação pode ser realizada por máquinas e a nenhum outro. “Se você não consegue verificar, não entregue.”²⁹

Operando uma frota

O estado final da engenharia de loops não é um único loop, mas uma frota permanente. Veja como essa prática funciona quando se estabiliza:

• Especificações como arquivos. Cada loop é uma especificação versionada — nome, nível, agendamento, objetivo, verificador, ferramentas permitidas, orçamento, timeout — armazenada no repositório ao qual atende. Se você executou a mesma verificação manual três vezes, ela deve virar uma especificação.
• Dois níveis, promoção conquistada. Loops de observação leem qualquer coisa, gravam apenas no próprio diretório de relatórios e podem ser agendados imediatamente. Loops de ação interferem no mundo e exigem a prova de ordenação, a declaração do raio de impacto e um verificador diferente de quem produziu o trabalho — tudo documentado antes mesmo de o agendamento existir. Os loops começam como observação e conquistam a promoção.
• A divisão entre execução e modelo. Verificações determinísticas são executadas como scripts (zero tokens, 1–2 segundos); loops de modelo ficam reservados para tarefas que exigem julgamento. O pulso diário de uma frota pode não custar nada.
• Contratos de relatório. Uma linha por verificação, PASS|FAIL <check>: <reason>, adicionada a um arquivo de relatório datado. Se você não consegue definir uma linha PASS compreensível de relance, o loop ainda não está pronto. Um loop de resumo lê os relatórios da frota para que a pessoa responsável leia uma página, não trinta.
• Baselines que se mantêm sozinhas. Os melhores monitores de desvio derivam suas expectativas do artefato que protegem — os timestamps registrados no próprio guia, os hashes do próprio lockfile — assim, atualizar o artefato também atualiza o monitor, sem criar uma segunda fonte da verdade que possa ser esquecida.
• Agendamento que resiste ao tempo. Frotas locais usam o agendador do sistema operacional (launchd, cron, timers do systemd) para invocar um script executor; frotas na nuvem usam routines. Loops vinculados à sessão (/loop) servem para trabalhos que você acompanha de perto.

É assim que a ideia de Cherny, “meu trabalho é escrever loops”, ganha forma concreta: o trabalho humano passa a ser especificar verificações, verificadores e orçamentos — e ler os relatórios.

Os dois primeiros loops que vale a pena criar

Se você está começando uma frota do zero, dois loops compensam o investimento imediatamente — ambos comprovados no harness deste próprio site:

O loop de gate — maker-checker para tudo o que você publica. Um avaliador novo (sem memória das rodadas anteriores) pontua o artefato segundo um critério explícito; você aplica todos os problemas identificados; outro avaliador faz uma nova análise; o loop para quando atinge o critério ou o limite rígido de rodadas. Duas observações práticas após usá-lo em uma maratona de quinze posts: correções podem introduzir novos defeitos (a correção de uma rodada atribuiu um dado à fonte errada, algo detectado pelo avaliador da rodada seguinte), e os avaliadores erram nos dois sentidos — um deles “corrigiu” com toda a confiança uma afirmação verdadeira, por isso correções específicas são verificadas na fonte antes de serem aplicadas. O checker não é a autoridade; a fonte é.

O groundskeeper — o ponto de entrada do nível de ação. Uma correção pequena e objetivamente verificável por execução, feita em uma branch, com os testes passando antes da abertura do PR, e o loop nunca faz o merge. Duas regras mantêm tudo seguro: qualquer ponto ambíguo é sinalizado, não corrigido (a primeira execução supervisionada recusou corretamente um falso positivo do detector), e uma falha preexistente na main é relatada como tal, nunca incorporada ao diff do loop.

Vale adotar um detalhe operacional das frotas: forneça aos loops de modelo não supervisionados um lease de sessão — adie qualquer execução enquanto houver uma sessão interativa ativa no mesmo repositório. Dois processos gravando em um único checkout acabarão intercalando commits; o lease faz o loop ceder espaço ao humano por definição.

Perguntas frequentes

O que é engenharia de loops?

É a prática de fazer agentes de IA repetirem ciclos de trabalho até que uma condição de parada seja atendida, em vez de fornecer prompts a cada turno. O trabalho de engenharia deixa de ser escrever prompts e passa a ser projetar o loop: sua regra de reexecução (uma condição, um agendamento, um evento), seu estado entre iterações, seu verificador e seu orçamento. Anthropic deu nome à disciplina em junho de 2026; suas interfaces do Claude Code são /goal, /loop, o plugin Ralph, routines e workflows dinâmicos.

O que é um Ralph loop?

É um padrão de autonomia por força bruta batizado por Geoffrey Huntley em julho de 2025: executar o Claude Code em um loop while do shell, fornecendo a ele o mesmo prompt com um contexto novo a cada iteração, enquanto arquivos de progresso e o git mantêm o estado entre as passagens e os testes funcionam como contrapressão. Anthropic oferece um plugin oficial chamado ralph-wiggum, que executa o loop dentro da sessão por meio de um Stop hook, tendo --max-iterations como principal mecanismo de segurança.

Como executo o Claude Code em um loop?

Escolha o nível mais baixo que atenda à necessidade: /goal <condition> para iterar até que um avaliador independente confirme uma condição; /loop <interval> <prompt> para execuções recorrentes enquanto sua sessão estiver aberta; /ralph-loop para iterar em uma única tarefa até uma promessa de conclusão; /schedule para criar uma routine na nuvem que seja executada via cron sem depender da sua máquina. No modo headless, claude -p dentro de um loop do shell com uma verificação externa é a forma clássica.

Os loops substituem os prompts?

O prompt não desaparece — ele muda de lugar. Você o escreve uma vez na especificação do loop, que volta a dispará-lo; cada vez mais (com workflows dinâmicos e a ideia de Cherny de que “na verdade, é outro Claude que cria os prompts”), um agente orquestrador escreve os prompts de cada tarefa. O que substitui a elaboração de prompts como atividade humana é o projeto da verificação: definir condições que uma máquina ou um modelo sem contexto prévio possa conferir.

Qual é a diferença entre loop, routine e workflow no Claude Code?

Um loop (/loop) executa novamente um prompt de acordo com um agendamento dentro da sua sessão local e termina junto com ela. Uma routine é a mesma ideia preparada para execução em uma infraestrutura de nuvem — acionada por cron, API ou eventos do GitHub, sem precisar de um laptop. Um workflow é o grafo de orquestração de uma única execução: um script JavaScript escrito pelo Claude que inicia e coordena até 1.000 subagents, mantendo loops e ramificações no código, não no contexto.

Quanto custam os loops de agentes?

A resposta honesta vai de “zero a um valor desastroso”, e a variável é o projeto. Monitores determinísticos não custam nada — são scripts executados de acordo com um agendamento. Loops de modelo são cobrados por iteração: limite-os (--max-iterations, --max-budget-usd), torne os retornos observáveis para que o loop possa parar quando houver ganhos decrescentes e trate cada limite como uma regra de parada, não como um inconveniente. Os post-mortems de falhas — milhares de dólares gastos durante a noite, 4 milhões de tokens em poucos minutos — têm uma causa em comum: a ausência de uma condição de parada externa.

Quando um loop deve se tornar um grafo?

Quando o trabalho paralelo passa a ter dependências: uma tarefa precisa da saída de outra ou dois agentes precisariam alterar os mesmos arquivos. Loops lidam com um repositório e um objetivo; grafos (workflows dinâmicos, equipes de agentes, orquestradores externos) acrescentam ordenação de dependências, reserva de arquivos e disciplina de merge. Use grafos apenas quando as colisões realmente surgirem — a estrutura adicional tem custos de observabilidade e configuração.

Registro de alterações