"Eu não estou mais digitando prompts no Claude. É o loop que está rodando, e é o loop que decide o que fazer em seguida, instruindo o Claude. Meu trabalho se tornou escrever os loops."
Estas são as palavras ditas publicamente por Boris Cherny, que lidera o Claude Code (apresentado no The New Stack e em artigos de Addy Osmani).
Enquanto muitos de nós ainda estamos refinando prompts para melhorar a precisão, a pessoa que constrói a ferramenta já se afastou de ser o "prompter".
Quando você pensa sobre isso, enquanto o "turno humano"—sentar em frente a uma tela, esperar por uma resposta da IA, verificá-la 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 seu IDE em novembro de 2024 e não o 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 (relatadamente mais de 200 PRs).
O criador da ferramenta não escreve código ele mesmo, mas mudou para o lado de "observar se o loop está girando corretamente". Hoje, vou detalhar isso em um 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 posso sentir minhas mãos se tornando mais livres quanto mais eu migro.
Artigo Relacionado: Introdução ao Vibe Coding: 6 Passos para Pessoas que Não Sabem Codar 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. Anteriormente, os humanos sentavam-se no meio de uma troca onde o humano instruía, a IA respondia, e o humano verificava e corrigia. No design de loops, 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 transferidas para o lado da IA. Você simplesmente espera por uma notificação quando estiver pronto.
Addy Osmani, do Google, escreveu o mesmo em um artigo intitulado Loop Engineering, descrevendo-o 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 que a IA escreva prompts para você. Este é o núcleo.
No entanto, o próprio Addy alerta: "Ainda está nos estágios iniciais, e estou um tanto cético. Você realmente precisa ter cuidado com os custos de tokens." Voltaremos a esta 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 engenharia de loops. Como as explicações online frequentemente contêm erros, vou focar nos pontos-chave com base na documentação de execução agendada oficial.
O comportamento muda dependendo do que você passa para ele:
- 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 decidirá o intervalo entre 1 minuto e 1 hora (autogerenciado). - 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 toda vez. Para pará-lo, pressione Esc enquanto espera (tarefas criadas por solicitações em linguagem natural não param com Esc; você deve pedir para deletá-las). No modo autogerenciado, se o Claude determinar que a tarefa está realmente concluída, ele terminará sem agendar a próxima execução.
O modo autogerenciado tem uma vantagem sutil: ele se ajusta automaticamente, esperando um curto período se uma build estiver quase terminada e mais tempo se nada estiver acontecendo. Às vezes, um mecanismo chamado "Monitor" é usado para transmitir saída em segundo plano em vez de polling, o que geralmente é mais barato do 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, com precisão, tarefas recorrentes expiram 7 dias após a criação (elas executam 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 ele não tiver expirado.
Existem três métodos de agendamento, escolhidos por caso de uso:
- Cloud (Routines): Executa no lado da Anthropic. Funciona mesmo se sua máquina estiver fechada. Intervalo mínimo é de 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 em 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, corrigi-la, 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 só decidem se aceitam as sugestões.
- Sincronização de Documentos: Detectar mudanças na fonte e manter o README ou especificações atualizados.
O 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 for 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 Execuções Descontroladas e Esquecimento com "Arquivos de Estado"
Existem dois medos com loops: repetir a mesma falha e consumir tokens infinitamente.
É aqui 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 obstrução a 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 quase a mesma conclusão 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 é transferido entre sessões por meio de commits 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 próprias 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 bash simples:
Ao alimentar o mesmo prompt infinitamente e usar um arquivo Markdown com o plano como estado compartilhado no disco, a IA lê a cada vez e decide "o que fazer em seguida" por si mesma. 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 for realmente alcançada.
No entanto, se você deixar tudo para uma IA, ela dirá "OK" para o código que escreveu. É aqui que separar a IA que cria (Maker) e a IA que inspeciona (Checker) é eficaz. Nas minhas próprias operações, separo a implementação e a verificação em agentes diferentes, e não dou ao lado de verificação a intenção da implementação—mostro apenas os requisitos e deixo que ele 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 uma perspectiva diferente" no loop—projetar essa verificação em múltiplas camadas é um dos trabalhos que os humanos devem manter.
Autonomia de Design em Três Estágios
Confiar tudo de uma vez levará a acidentes. É mais seguro separar o nível de envolvimento em camadas:
- L1 (Manual): Humanos digitam prompts e verificam cada um. A maneira 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ê vir o alcance da confiabilidade. Nas minhas primeiras vezes, assisti aos logs em uma tela lateral para ver "onde ele fez 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 à medida que rodam. Isso é o que Addy enfatizou; se você definir o intervalo muito curto, pode custar uma boa quantia durante a noite. O modo autogerenciado é melhor do que intervalos fixos porque espera quando deve, reduzindo o desperdício.
- Operações Irreversíveis: O prompt de manutenção embutido só executa ações irreversíveis como push ou exclusão dentro do "intervalo já permitido na conversa". Ao escrever seus próprios prompts, é mais seguro definir os limites para operações destrutivas você mesmo.
- Desaparece em 7 Dias: Tarefas
/looprecorrentes expiram 7 dias após a criação. Se quiser executá-lo 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 ele reaja no momento em que um evento ocorrer, use push via Channels.- Colocar um
loop.md(.claude/loop.mdou~/.claude/loop.md) permite que você substitua o prompt padrão de um/loopsimples pelo seu próprio. É útil para escrever tarefas de rotina como "corrigir se o CI do branch de release estiver vermelho". - Até 50 tarefas agendadas por sessão. Você pode ver a lista com
CronListe deletar por ID comCronDelete.
Resumo
Anteriormente, o tempo que eu passava em frente à tela era o limite superior do progresso. Agora, um loop que lê um arquivo de estado enquanto eu durmo avança 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 funciona (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 seja 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ê estiver interessado em utilizar Claude Code/Codex ou usar IA para operações no X, junte-se a nós.
