"Não estou mais digitando prompts no Claude. O loop é quem está rodando, e é o loop que decide o que fazer em seguida, chamando o Claude. Meu trabalho se tornou escrever os loops."
Essas são palavras ditas publicamente por Boris Cherny, que lidera o Claude Code (destaque no The New Stack e em artigos de Addy Osmani).
Enquanto muitos de nós ainda refinamos prompts para melhorar a precisão, a pessoa que constrói a ferramenta já deixou de ser o "prompter".
Quando você pensa sobre isso, enquanto o "turno humano" — sentar na frente de uma tela, esperar uma resposta da IA, verificar e dar instruções novamente — estiver envolvido, o limite de velocidade é determinado pela velocidade das suas próprias mãos.
Loop Engineering é a ideia de remover esse turno humano da estrutura. Boris está totalmente comprometido com isso; ele diz que deletou sua IDE em novembro de 2024 e não a abriu desde então. Ele afirma que quase todas as suas contribuições para o Claude Code no último mês foram escritas pelo próprio Claude Code (mais de 200 PRs, segundo relatos).
O criador da ferramenta não escreve código ele mesmo, mas passou para o lado de "observar se o loop está girando corretamente." Hoje, vou analisar isso no nível de especificação técnica, não apenas como uma vibe. Também estou em processo de migrar para o lado do loop e sinto minhas mãos se tornando mais livres conforme mais eu migro.
Artigo relacionado: Introdução ao Vibe Coding: 6 Passos para Pessoas que Não Sabem Programar Criarem Apps com Claude. A Era da Produção Interna nos Fins de Semana Chegou
https://note.com/nobel/n/n8192ec07d689
Loop Engineering Significa uma Mudança de Papéis
Em outras palavras, sua posição muda. Antes, os humanos ficavam no meio de uma troca onde o humano instruía, a IA respondia, e o humano verificava e corrigia. No design de loop, os humanos são responsáveis por projetar o mecanismo de circulação (o loop), enquanto a tentativa e erro e a verificação dos resultados são transferidos para o lado da IA. Você simplesmente espera por uma notificação quando terminar.
Addy Osmani, do Google, escreveu a mesma coisa em um artigo intitulado Loop Engineering, descrevendo como "substituir a pessoa que digita prompts por um mecanismo que digita prompts em nome dela." O ponto de alavancagem mudou da habilidade de escrever bons prompts para como projetar um sistema que permite à IA escrever prompts para você. Esse é o núcleo.
No entanto, o próprio Addy adverte: "Ainda está nos estágios iniciais, e estou um tanto cético. Você realmente precisa ter cuidado com os custos de tokens." Voltaremos a essa armadilha na segunda metade.
As Especificações Técnicas do /loop
O Claude Code tem uma habilidade embutida chamada /loop (a partir da v2.1.72). Esta é a porta de entrada mais fácil para a loop engineering. Como as explicações online frequentemente vêm com erros, vou focar nos pontos principais com base na documentação oficial de execução agendada.
O comportamento muda dependendo do que você passa para ele:
- Ambos intervalo e prompt:
/loop 5m check if the deployment is finished and let me knowserá executado em intervalos fixos. - Apenas prompt:
/loop check if the CI passed and respond to review comments. O Claude decide o intervalo por conta própria, entre 1 minuto e 1 hora (ritmo próprio). - Nada passado:
/loop. O prompt de manutenção embutido (continuar trabalho inacabado, cuidar de PRs, limpeza leve) ou um arquivoloop.mdque você colocou será executado.
O intervalo pode ser colocado no início, como 30m, ou no final, como every 2 hours. As unidades são s / m / h / d. Você também pode passar outros comandos, como /loop 20m /review-pr 1234, para executar habilidades salvas a cada vez. Para pará-lo, pressione Esc enquanto espera (tarefas criadas via solicitações em linguagem natural não param com Esc; você precisa pedir para deletá-las). No modo ritmo próprio, se o Claude determinar que a tarefa está realmente concluída, ele termina sem agendar a próxima execução.
O modo ritmo próprio tem uma vantagem sutil: ele se ajusta automaticamente, esperando um tempo curto se uma build está quase terminando e mais tempo se nada está acontecendo. Às vezes, um mecanismo chamado "Monitor" é usado para transmitir saída em segundo plano em vez de polling, o que geralmente é mais barato que disparar um prompt em intervalos fixos.
Deixe-me corrigir um equívoco comum encontrado em artigos de origem. Às vezes é escrito que as tarefas são "automaticamente deletadas 3 dias após a criação", mas precisamente, tarefas recorrentes expiram 7 dias após a criação (elas são executadas uma última vez e desaparecem). Além disso, /loop tem escopo de sessão e desaparece quando você inicia uma nova conversa. Se você fechá-lo, pode retornar com --resume se não tiver expirado.
Existem três métodos de agendamento, escolhidos por caso de uso:
- Nuvem (Routines): Executa no lado da Anthropic. Funciona mesmo se sua máquina estiver fechada. Intervalo mínimo é 1 hora.
- Desktop Scheduled Tasks: Executa na sua máquina e pode tocar em arquivos locais.
- /loop: Apenas enquanto a sessão estiver aberta. Mínimo de 1 minuto, conveniente para polling durante uma sessão.
A divisão de trabalho é: use Routines ou GitHub Actions para residência permanente sem intervenção humana, e /loop para monitoramento durante uma sessão.
Tarefas Padrão Onde Loops São Eficazes
Tarefas na sua rotina onde você repete "verificar e corrigir um pouco" são geralmente adequadas para loops. Existem três padrões comuns:
- Patrulha de Bugs: Detectar problemas ou falhas em testes, ler a causa, corrigir, executar testes e criar um PR em intervalos regulares.
- Revisão Contínua: Monitorar mudanças no código e continuar apontando áreas de preocupação. Humanos apenas decidem se aceitam as sugestões.
- Sincronização de Documentos: Detectar mudanças na fonte e manter o README ou especificações atualizados.
A característica comum entre esses três é que o objetivo pode ser claramente julgado, como "testes passam" ou "PR é criado". Por outro lado, tarefas com critérios ambíguos não são adequadas para loops. Se o ponto de parada não está claro, ele continuará rodando e consumindo tokens. Para sua primeira tarefa, é mais seguro escolher uma onde o sucesso ou fracasso seja óbvio à primeira vista.
Prevenindo Descontrole e Esquecimento com "Arquivos de Estado"
Há dois medos com loops: repetir a mesma falha e consumir tokens infinitamente.
É aí que projetar com um único arquivo de estado no projeto é eficaz. Seja STATE.md ou todo.md, a IA lê e escreve o objetivo atual / itens concluídos / próximos passos / pontos de travamento durante cada loop. Mesmo que a sessão seja cortada, a IA não perde o controle de "onde está e para onde está indo."
Isso não é apenas uma prática aleatória; a própria Anthropic chegou a uma conclusão quase idêntica em Effective harnesses for long-running agents (novembro de 2024). A configuração deles usa dois papéis: um agente inicializador para configurar o ambiente e um agente de codificação para progredir uma funcionalidade por sessão. O progresso é transmitido entre sessões via commits no git e um arquivo claude-progress.txt. Para trabalhos longos, a compressão por sumarização é insuficiente. A política é escrever em um arquivo estruturado uma vez e reconstruir o contexto.
Nas minhas operações, uso tasks/state.md como um hub para estado compartilhado, que tanto o lado de brainstorming quanto o lado de implementação leem antes de agir. É o mesmo que o artigo: "Não confie no contexto, confie no arquivo." É simples, mas sem isso, o loop se perde na segunda volta.
O Método Ralph e a Separação entre Criador e Verificador
Existe uma versão extrema do loop chamada método "Ralph". Popularizado por Geoffrey Huntley, a fonte original é apenas um loop simples em bash:
Ao alimentar o mesmo prompt infinitamente e usar um arquivo Markdown com o plano como estado compartilhado em disco, a IA lê a cada vez e decide "o que fazer em seguida" por conta própria. Parece imprudente, mas porque há um arquivo de estado, ele avança a cada volta. O Claude Code também tem um plugin oficial ralph-loop que continua reenviando o mesmo prompt até que uma condição de conclusão (promessa de conclusão) seja atendida. Há uma restrição de que a declaração de conclusão só deve ser emitida quando realmente alcançada.
No entanto, se você deixar tudo para uma única IA, ela dirá "OK" ao código que ela mesma escreveu. É aí que separar a IA que cria (Maker) e a IA que inspeciona (Checker) é eficaz. Nas minhas operações, separo implementação e verificação em agentes diferentes, e não dou ao lado de verificação a intenção de implementação — mostro apenas os requisitos e deixo que avalie de forma independente. Aprendi da maneira mais difícil que auto-revisões na mesma sessão são inevitavelmente lenientes.
Incorporar um "agente de revisão com perspectiva diferente" no loop — projetar essa verificação em múltiplas camadas é uma das tarefas que os humanos devem manter.
Autonomia de Design em Três Estágios
Entregar tudo de uma vez vai levar a acidentes. É mais seguro separar o nível de envolvimento em camadas:
- L1 (Manual): Humanos digitam prompts e verificam cada um. A forma tradicional.
- L2 (Loop Semiautônomo): Seguir um arquivo de estado e observar um conjunto específico de tarefas até a conclusão com
/loop. - L3 (Residente): Executar continuamente via Routines ou GitHub Actions sem intervenção humana.
É realista começar com L2. Execute uma tarefa até a conclusão com /loop e observe o comportamento. Suba para L3 assim que você enxergar o alcance da confiabilidade. Nas primeiras vezes, assisti aos logs em uma tela secundária para ver "onde ele cometeu um julgamento errado."
Armadilhas (Saiba Disso Primeiro)
Como escrevi apenas sobre os lados bons, aqui estão três pontos onde você pode ficar preso:
- Custos de Tokens: Loops consomem mais conforme rodam. É o que Addy enfatizou; se você definir o intervalo muito curto, pode custar uma boa quantia durante a noite. Ritmo próprio é melhor que intervalos fixos porque espera quando deve, reduzindo desperdício.
- Operações Irreversíveis: O prompt de manutenção embutido só toma ações irreversíveis como push ou delete dentro do "escopo já permitido na conversa." Ao escrever seus próprios prompts, é mais seguro definir você mesmo os limites para operações destrutivas.
- Desaparece em 7 Dias: Tarefas
/looprecorrentes expiram 7 dias após a criação. Se quiser executar por mais tempo, migre para Routines ou tarefas Desktop.
Notas para Usuários Intermediários
/loope/goalsão diferentes./loopexecuta por intervalo. Se quiser continuar a cada turno até que uma condição seja atendida, use/goal. Se quiser que reaja no momento em que um evento ocorrer, use push via Channels.- Colocar um
loop.md(.claude/loop.mdou~/.claude/loop.md) permite substituir o prompt padrão de um/loopvazio pelo seu próprio. É útil para escrever tarefas rotineiras como "corrigir se o CI da branch de release estiver vermelho." - Até 50 tarefas agendadas por sessão. Você pode ver a lista com
CronListe deletar por ID comCronDelete.
Resumo
Antes, o tempo que eu passava na frente da tela era o limite superior do progresso. Agora, um loop que lê um arquivo de estado enquanto durmo progride uma funcionalidade de cada vez, e minha manhã começa verificando esse progresso.
Antes de melhorar o conteúdo (precisão do prompt), projete a forma como ele roda (separação de loops, gerenciamento de estado e verificação). A alavancagem mudou para lá — este é o ponto comum nas histórias de Boris, Addy e do harness da Anthropic. Acredito que não é uma teoria difícil, mas um acúmulo constante de designs simples, como decidir quando parar antes de iniciar o loop.
Informações úteis que não podem ser compartilhadas no X estão sendo compartilhadas no LINE OpenChat. Se você tem interesse em utilizar Claude Code/Codex ou usar IA para operações no X, junte-se a nós.
