🔁 /loop — O Intervalo de Execucao
O /loop e o bloco mais basico do loop engineering. Funciona como um cron job para agentes de IA: voce define um intervalo (a cada 5 minutos, a cada hora) e o Claude Code acorda, verifica o estado do mundo, executa o que precisa, e volta a dormir. Sem interacao humana no meio.
"With slash loop, we set an interval for running a prompt. So like, for example, every five minutes, I'm going to check for new GitHub issues in this repo and handle any that come in."
Em portugues: "Com /loop, definimos um intervalo para rodar um prompt. Por exemplo, a cada cinco minutos vou verificar se ha novas issues no GitHub neste repo e tratar qualquer uma que aparecer."
📋 Anatomia de um /loop
Intervalo
Tempo entre cada "acordar" do agente. Tipicamente 5 minutos, 15 minutos, 1 hora.
Fonte externa de input
GitHub issues, um diretorio de arquivos, uma API, um banco de dados. O agente precisa de "algo para olhar".
Prompt de acao
O que fazer quando acordar. "Verifique se ha issues novas. Se houver, trate a mais antiga."
Terminal ativo
O /loop depende do terminal do Claude Code estar rodando. Se fechar, o loop para.
🎯 Ponto de Reflexao
O /loop e poderoso para tarefas repetitivas e previsíveis, mas tem uma limitacao fundamental: tudo roda na mesma sessao do Claude Code. Como Cole aponta mais adiante, "if you loop for a while, you're going to completely bloat your context for your LLM and overwhelm it." O /loop funciona bem para ciclos curtos. Para trabalho prolongado, precisa de algo a mais.
🎯 /goal — O Criterio de Conclusao
Enquanto o /loop define "quando acordar", o /goal define "quando parar". Voce estabelece criterios objetivos de conclusao, e o agente trabalha ate atingi-los. Nao tem intervalo fixo. O agente fica ativo ate que a condicao seja verdadeira.
"So we set some criteria like here is how you know you are done. And then we're forcing the coding agent to work until it is done, kind of like Ralph loops that went viral a few months ago."
Em portugues: "Definimos criterios como 'e assim que voce sabe que terminou'. E entao forcamos o agente a trabalhar ate estar pronto, parecido com os Ralph loops que viralizaram."
Bons criterios de /goal
- ✓"Todos os testes passam"
- ✓"Zero issues abertas no repo"
- ✓"Todas as tarefas no plan.md marcadas como done"
- ✓"Build compila sem erros"
Criterios arriscados
- ✗"O codigo esteja bom" (subjetivo demais)
- ✗"Tudo funcione" (sem metrica verificavel)
- ✗"O app esteja bonito" (imposssivel de avaliar)
- ✗Sem limite de iteracoes (loop infinito)
⚠️ O Risco do /goal Sem Limites
Se o criterio de conclusao for mal definido ou impossivel de atingir, o /goal vira um loop infinito que queima tokens sem parar. Cole menciona que para um app relativamente simples, gastou mais de 1 milhao de tokens. Sempre defina um numero maximo de iteracoes junto com o /goal, ou use timeouts como rede de seguranca.
📅 /routines — Os Jobs Agendados
O /routines e o terceiro bloco. Diferente do /loop (intervalo curto, tarefa repetitiva) e do /goal (trabalhar ate concluir), /routines sao jobs agendados com escopo amplo. Pense em "a cada hora, acorde, olhe o spec document completo, e trate a proxima tarefa da fila".
"And then last, we have slash routines. And so these are the scheduled jobs, like every hour, I want you to wake up, look at some larger spec document, and then handle the next task."
Em portugues: "E por ultimo temos /routines. Sao os jobs agendados. Como: a cada hora, quero que voce acorde, olhe um spec document maior, e trate a proxima tarefa."
🔄 /routines vs /loop: Qual a Diferenca?
| Aspecto | /loop | /routines |
|---|---|---|
| Intervalo | Curto (minutos) | Longo (horas) |
| Escopo por ciclo | Tarefa unica e rapida | Tarefa de um spec maior |
| Input | Evento externo (issue, webhook) | Spec document completo |
| Analogia | Cron job simples | Batch processing agendado |
🧩 Como os Blocos se Combinam
A forca do loop engineering nao esta em nenhum bloco isolado. Esta na combinacao deles para formar um sistema coerente. Boris Cherny, por exemplo, usa /routines para agendar ciclos de trabalho, /goal dentro de cada ciclo para definir quando o agente terminou uma etapa, e /loop para monitorar eventos externos entre os ciclos.
"Loop engineering is combining or creating a system around all these things — routines, slash loop — so that we can give a larger scope of work as input to an AI coding assistant and have it work through it incrementally."
Em portugues: "Loop engineering e combinar ou criar um sistema em torno de todas essas coisas — routines, /loop — para que possamos dar um escopo maior de trabalho como input para um assistente de coding IA e faze-lo trabalhar incrementalmente."
📋 Exemplo de Sistema Combinado
A cada 1 hora, acorda o orquestrador e diz: "olhe o spec, identifique a proxima tarefa pendente."
O orquestrador configura um /goal para o worker: "implemente a feature X. Voce esta done quando todos os testes passarem."
Em paralelo, um /loop monitora a cada 5 minutos se novas issues apareceram no GitHub. Se sim, as adiciona ao spec.
🎯 Ponto de Reflexao
A palavra-chave na citacao de Cole e "incrementalmente". O ponto central de Loop Engineering nao e dar ao agente um projeto inteiro e dizer "faz". E quebrar o trabalho em ciclos pequenos, onde cada ciclo tem escopo limitado e validacao propria. Sem isso, o agente tenta resolver tudo de uma vez e, como Cole alerta, "it will get completely overwhelmed".
🔧 O Loop Skill: Automontagem
Uma das coisas mais interessantes que Cole demonstrou e que o Claude Code tem uma capability interna chamada "loop skill". Voce nao precisa configurar o /loop manualmente. Basta dizer ao Claude Code para carregar o skill, e ele monta o sistema de loop sozinho, decidindo o intervalo e a estrategia.
"You just tell it to use the loop skill. So there's a capability built right into the tool where it knows how to set up these loop systems based on what we ask it to do."
Em portugues: "Voce simplesmente diz para usar o loop skill. Ha uma capability dentro da ferramenta que sabe como montar esses sistemas de loop baseado no que pedimos."
🖥️ O que Cole Demonstrou
Input: spec document simples
Uma lista de tarefas numeradas em plan.md. Nada elaborado.
Claude Code identificou a estrutura
"It says this is sequential task list, it's going to do the first task, and then it's going to schedule a quick wake up."
O loop se auto-configurou
"It wrote the prompt: /loop work through plan.md one task at a time." Cole nao escreveu esse prompt. O Claude Code fez.
Execucao incremental
Em 2 minutos, ja havia completado as 2 primeiras tarefas. Cada wake-up resolve uma tarefa e agenda o proximo.
💡 Insight Importante
O fato do Claude Code montar o loop sozinho e impressionante tecnicamente, mas tem um lado perigoso: voce perde visibilidade sobre como o loop foi configurado. Cole usou um exemplo simples de proposito, mas em sistemas de Boris Cherny com "dezenas de milhares de agentes", a automontagem sem observabilidade e um risco concreto.
❓ Questionamentos
Os tres blocos parecem simples. E sao. Mas a simplicidade esconde armadilhas reais que precisam ser levantadas antes de sair implementando.
Tudo roda na mesma sessao?
Cole levanta um problema estrutural: "you're not really working between different coding agent sessions. Like when you're just using /loop in Claude Code, it's really just continuing in the same coding agent session." Isso significa context bloat inevitavel. Cada iteracao do loop adiciona mais contexto, e o LLM fica progressivamente mais sobrecarregado. E uma limitacao arquitetural, nao um bug.
Qual o custo real de manter esses loops?
Cada wake-up do /loop consome tokens. Cada iteracao do /goal tambem. E /routines, que leem um spec inteiro a cada ciclo, sao especialmente caras. Cole mediu mais de 1 milhao de tokens para um app simples. Para quem paga por token, a conta chega rapido.
E se o loop decidir errado?
Quando o Claude Code auto-monta o loop via skill, ele tambem decide o prompt do proximo ciclo. Se essa decisao for errada, o erro se propaga para todos os ciclos seguintes. Sem human-in-the-loop, voce so descobre o problema quando ja gastou tokens e tempo. Cole chama isso de "the biggest problem with loop engineering right now."
⚠️ O Limite dos Blocos Sozinhos
/loop, /goal e /routines sao primitivas. Sao os tijolos, nao a casa. Sem um sistema de orquestracao que distribua trabalho entre sessoes diferentes, gerencie estado externamente, e permita intervencao humana, esses blocos produzem resultados mediocres para qualquer coisa alem de demos simples. O proximo modulo (1.3) mostra como a arquitetura Orchestrator-Workers resolve exatamente isso.
📋 Resumo do Modulo
Proximo Modulo:
1.3 — Arquitetura Orchestrator-Workers