O Claude Code ganhou um comando /loop que transforma ele num worker de background. Parece pouca coisa, mas muda a categoria do que a ferramenta é.
Funciona assim: você passa um intervalo e um prompt, e o Claude Code executa aquela tarefa repetidamente enquanto a sessão estiver aberta. Tipo um cron, mas onde o "script" é uma instrução em linguagem natural.
Um exemplo concreto: na semana passada, depois de um deploy que mexeu na camada de autenticação, configurei um /loop para monitorar os logs de erro a cada 5 minutos por 48 horas. O prompt era simples: "leia os últimos 100 registros de error.log, filtre por 401 e 403, e me avise se a taxa subir acima de 2% das requisições". No segundo dia, ele flagou um spike de 401 vindo de um client mobile que não tinha recebido o token atualizado. Sem isso, provavelmente só iam perceber quando o suporte reclamasse.
Outras equipes usam para revisar PRs novos de manhã, checar se algum deploy quebrou rotas, ou gerar resumos de commits no fim do dia.
Tem limitações claras: as tarefas expiram em 3 dias, são vinculadas à sessão, e o limite é 50 por sessão. Não é um substituto para pipelines de CI/CD. É mais um assistente de plantão que faz triagem.
O que me interessa é a mudança conceitual. Até agora, ferramentas de IA para código funcionavam sob demanda: você abre, pergunta, recebe, fecha. O /loop inverte isso. O agente fica rodando, observando, agindo quando detecta algo relevante.
Para Tech Leads, a implicação prática é: tarefas repetitivas de baixo risco que consomem atenção do time podem ser delegadas. Não a implementação complexa, mas a vigilância. Monitorar logs depois de um deploy, acompanhar error rates num período crítico, validar que nenhum endpoint novo está retornando 500. Coisas que ninguém quer fazer manualmente por 48 horas seguidas.
Combinado com o auto mode que saiu essa semana, a direção é clara. O Claude Code está deixando de ser um chat que escreve código e virando um agente que opera dentro do fluxo de trabalho.
A tarefa morre quando a sessão fecha
/loop vive na conversa. Fecha o terminal, as tarefas param. Nova conversa, a lista zera. Resume com --continue pode devolver o que ainda não expirou; sessão nova, não. Isso basta para separar a feature de cron da empresa, de GitHub Actions e de qualquer worker que precise sobreviver ao laptop fechado.
O teto de 50 tarefas por sessão e a expiração em três dias reforçam o recorte. Dá para acompanhar um deploy, uma janela de migração, um PR longo. Não dá para "monitorar autenticação para sempre". Quem precisa de duração maior recorre a rotina na nuvem, tarefa no Desktop, ou CI. O /loop é o polling rápido enquanto você ainda está no contexto.
Intervalo mínimo de um minuto e execução só quando a sessão está idle também mudam a expectativa. Se o agente está no meio de um refactor, o check de log espera. Não há catch-up para os intervalos perdidos: quando volta, dispara uma vez. Quem trata isso como Prometheus vai se decepcionar no primeiro incidente real.
A decisão, então, é estreita: esta janela de trabalho precisa de um olho repetido, e eu vou manter a sessão viva por isso? Se a resposta depende de a máquina ficar ligada no fim de semana, a ferramenta errada já foi escolhida.
O prompt precisa de limiar, dono e canal
O exemplo de 401/403 com limiar de 2% funciona porque a instrução já traz recorte, métrica e ação. "Fica de olho nos logs" não traz. Sem limiar o agente resume ruído. Sem canal ele imprime no transcript e ninguém vê. Sem dono, o aviso cai no vazio.
Escreva o prompt como um runbook de uma página: o que ler, como filtrar, qual número dispara, o que fazer (avisar, abrir issue, não aplicar hotfix sozinho), quando parar. /loop 5m sem esse texto só gasta turno. Se o time já tem loop.md no repositório, use para o default da sessão; prompts específicos de incidente continuam na linha de comando.
O dono é uma pessoa, não "o time". Quem recebe o ping às 23h? Quem cancela o loop quando o incidente fecha? Tarefa órfã por três dias é custo de token e de atenção. Liste os loops ativos no começo do dia, como se lista PR.
Canal de escalada precisa ser chato e explícito: mensagem na sessão, thread no chat da equipe, comentário no PR. O agente classificar um spike e "tomar uma providência" em produção é outra categoria de risco. Vigilância escala. Mutação espera humano.
Vigilância sem efeito colateral no repositório
O desenho útil é observar, classificar, avisar. Ler error.log, checar rota, resumir commits, comentar se o CI ficou vermelho. O desenho frágil é o loop que também faz commit, merge, rollback ou kubectl. A cada cinco minutos, a superfície de erro se multiplica.
Se a sessão está em auto mode, o loop herda essa permissão. A combinação é tentadora e ruim para o primeiro uso: um prompt vago, um classificador, um intervalo curto. Comece com modo que ainda pede confirmação para escrita, ou com deny em push e apply. Só então, se o prompt for estreito, relaxe.
PRs novos de manhã e resumo de commits no fim do dia cabem. São triagem. Implementação complexa, incidente com mitigação automática, e "conserta se quebrar" não cabem. O limite de 50 tarefas existe para o scheduler da sessão, não como convite para cinquenta automações de produção.
Uma regra prática: se a ação precisa de postmortem quando der errado, ela não entra no /loop. Entra em pipeline com log, dono e rollback. O agente pode vigiar esse pipeline; a mutação continua no sistema que já tem dono.
O terminal ligado é parte do custo
Enquanto o loop roda, a sessão ocupa máquina, contexto e fatura. Cada iteração reenvia um prompt. Intervalo de cinco minutos durante 48 horas são dezenas de turnos, mesmo quando o resultado é "nada mudou". Para log de autenticação depois de deploy isso pode valer. Para "ver se alguém comentou no PR" às vezes um webhook ou o próprio CI avisam mais barato.
Há também o custo de atenção. Notificação a cada ciclo treina a pessoa a ignorar. Notificação só no limiar exige confiança no prompt. Ajuste o intervalo ao risco da janela: mais curto nas duas primeiras horas do deploy, mais longo depois. Claude pode escolher o intervalo quando você omite o número; para incidente, prefira o cron fixo que você entende.
Background da sessão mantém o loop sem o terminal em primeiro plano. Continua sendo a sua máquina. Política de "agente plantonista" precisa dizer se isso é aceitável à noite, e o que acontece se a máquina dormir.
Se o time já paga observabilidade de verdade, o /loop não compete com ela. Complementa o buraco de duas horas em que ninguém quer abrir o dashboard. Essa honestidade evita o slide em que a feature vira "plataforma de SRE".
Cinquenta jobs e três dias são o envelope
Use o envelope como especificação. Cabe: vigiar erro rate após mudança de auth; reler um log de migração; acompanhar um PR até o merge; lembrar de olhar o canário. Não cabe: job noturno eterno, fan-out para todos os serviços, substituto de pager.
Quando a janela passar de três dias, recrie com intenção ou mova para ferramenta durável. Recriar no automático, para burlar a expiração, só esconde que a tarefa já era infraestrutura. O produto impõe o limite para você não esquecer um loop gasto rodando.
No review da semana, pergunte quais loops existiram, o que escalaram, o que foi falso positivo, o que ninguém leu. Se a lista estiver vazia e o time "usa /loop", a feature é decorativa. Se estiver cheia de mutações, a feature está no lugar errado. O meio-termo chato (poucos loops, prompt estreito, sessão viva, escalada humana) é o único que se sustenta.
