Claude Code durante a noite: loop engineering e Ralph Loop em 2026

Documentação de referência da Ailoot: ailoot.ai/docs/.

O que é loop engineering e porque deve interessar-lhe?#

E a segunda declaração explica a escala:

Por trás destas declarações está um novo papel de engenharia: é o arquiteto dos ciclos, não um operador de teclado.

Faça-o uma vez hoje e, todos os dias, os leads aumentam, os artigos são publicados automaticamente, o bot trata da correspondência e o relatório de métricas chega à sua secretária às 9h. Constrói-o e ele trabalha todos os dias sem si.

Se ainda abre o Claude Code, escreve um prompt, espera, lê e escreve outro prompt, está a perder a maior mudança de 2026. Os modelos tornaram-se suficientemente poderosos para trabalhar em ciclos sem supervisão.

Em que difere o Ralph Loop de um pedido normal ao Claude Code#

At its core, the technique is a simple bash loop around an agent:

O código original que desencadeou toda a onda:

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

Um prompt num ficheiro, com um ciclo infinito à sua volta. E o comentário mais franco do autor:

A Anthropic reuniu a mesma lógica no plugin ralph-loop e nos comandos /loop, /goal e /batch do Claude Code — estão disponíveis diretamente no terminal, sem scripts. O simples facto de a Anthropic ter lançado um plugin para voltar a dar prompts infinitamente desencadeou um debate no GitHub Issue #23084 sobre se isso é justo para o modelo. O debate continua aberto; o plugin funciona.

Três comandos integrados no Claude Code: /loop, /goal, /batch#

/goal é o comando mais parecido com o Ralph Loop. Nos bastidores, um modelo avaliador (Haiku por predefinição) verifica em cada turno se o objetivo foi atingido. Se não, a iteração seguinte inclui uma indicação do que corrigir exatamente. Se sim, para. Abordei /goal em pormenor no guia sobre executar o Claude Code autonomamente durante a noite com /goal — inclui cenários prontos a usar para 14 horas de trabalho.

/batch é um comando raro, mas poderoso. Quando precisa de fazer a mesma alteração em mais de 100 ficheiros (migração de API, substituição de componentes, mudança de nomes), /batch envia cada ficheiro para um subagente separado na sua própria git worktree. As alterações não entram em conflito — cada agente trabalha numa cópia isolada. Saiba mais sobre subagentes no guia sobre subagentes aninhados.

Na descrição do autor, esta abordagem é simplesmente chamada:

Limites rígidos de /loop e /goal:

• Uma tarefa é executada enquanto o Claude Code estiver aberto. Feche o terminal e o ciclo termina. Para um ciclo noturno a sério, use um servidor remoto ou o seu próprio wrapper de shell.
• A duração máxima de uma tarefa recorrente é de 7 dias (após esse período, é eliminada automaticamente como proteção contra ciclos esquecidos).
• Até 50 tarefas simultâneas numa sessão.

Quer criar uma configuração que torne o Claude fiável? O Ralph Loop é apenas uma parte. É útil considerar os três componentes: clone de IA + Second Brain + Context Engineering — esta combinação transforma o Claude de um “assistente que alucina” numa ferramenta a que pode atribuir uma tarefa e depois tratar da sua vida.

Como iniciar o seu primeiro ciclo autónomo em 5 minutos#

5 passos:

1. Abra o projeto no Claude Code

   No terminal, aceda à raiz do projeto e execute claude. Aguarde que o Claude leia CLAUDE.md e indexe o repositório.

2. Defina um objetivo e uma condição de paragem

   O objetivo é aquilo que tem de ser feito. A condição de paragem indica como o Claude saberá que terminou. Idealmente, é um comando que devolve 0 ou 1. Exemplo: “Objetivo: os 23 testes em tests/api/*.test.ts têm de passar. Parar quando pnpm test devolver exit 0.”

3. Execute /goal

   Comando:

   /goal Todos os testes em tests/api/*.test.ts têm de passar. Execute pnpm test, leia os erros, corrija-os e execute-o novamente. Pare quando o código de saída = 0. Máximo de 20 iterações.
   

   O Claude inicia o ciclo: executa os testes — deteta uma falha — abre o ficheiro — corrige-a — volta a executá-los.

4. Defina um limite de orçamento

   Utilize /usage num separador em segundo plano para monitorizar a utilização. Defina um limite de tokens ou de dinheiro para o dia, para não gastar todo o seu saldo num único ciclo. Saiba mais no guia sobre como não esgotar os limites do Claude Code.

5. Trate da sua vida

   Volte dentro de 30 minutos. Se a tarefa for simples, já aparecerá “DONE, todos os testes passam”. Se for mais complexa, leia o relatório: “parou na iteração 20, motivo X”. Corrija manualmente aquilo que o ciclo não conseguiu e, depois, reinicie-o.

Padrão de verificação: como o Claude verifica o próprio trabalho num ciclo#

Há três tipos de verificadores:

1. Técnico (código de saída) — o mais fiável. pnpm test, npm run lint, tsc --noEmit, playwright test. Devolvem 0 ou 1, sem necessidade de interpretação. O /goal também funciona assim — utiliza nos bastidores o modelo avaliador Haiku, que verifica em cada turno se a condição foi cumprida (até 4000 caracteres).

2. Modelo avaliador — um segundo modelo analisa o resultado do primeiro e avalia-o segundo uma grelha de critérios. É útil para tarefas sem uma verificação formal (“O estilo de escrita é bom?” “O design corresponde à marca?”). Na Anthropic, isto chama-se Claude Code Review — um modo em que um agente revisor separado procura erros lógicos, casos limite e problemas de segurança no trabalho do agente principal. Segundo dados internos da Anthropic, encontra 84% dos problemas em PRs de grande dimensão (contra 16% com a abordagem de referência).

3. Verificação personalizada — um script de shell que escreve. “Se os registos não contiverem a palavra ERROR, está concluído.” “Se o ficheiro output.json existir e puder ser analisado, está concluído.” “Se a página /pricing devolver 200, está concluído.”

Na abordagem do autor, as skills incluem uma análise adversarial separada para o Claude após cada fase. Eis um modelo de prompt que coloco em CLAUDE.md ou num comando:

Encontra 10 razões pelas quais este projeto pode ter corrido muito mal. 
Coloca-te na situação de algo ter corrido mal. 
Posso rever esta história muitas vezes — 
antes de a publicar.

O erro mais comum dos principiantes é iniciar um ciclo sem um verificador. O agente anda às voltas: escreve código, não o verifica, pensa que terminou, passa à iteração seguinte e volta a escrever o que já fez. Três horas depois, está tudo uma confusão e a fatura é de $200.

A melhor regra: escreva primeiro o verificador e só depois inicie o ciclo. Se não consegue enunciar a condição de paragem numa linha, a tarefa ainda não está pronta para ser autónoma.

Como não gastar milhares de dólares durante a noite: limites de orçamento e condições de paragem#

Três travões essenciais para qualquer ciclo noturno:

1. Limite de iterações. --max-iterations 20. O ciclo não pode executar mais de N vezes — mesmo que o verificador não seja acionado. Se não tiver atingido a condição de paragem após 20 iterações, a tarefa está bloqueada e precisa de intervenção humana.

2. Limite de tokens ou de dinheiro. /usage limit 50 — não mais de $50 por dia. À medida que se aproxima do limite, o ciclo para por si e envia um alerta. Isto protege contra uma situação descontrolada.

3. Verificação de progresso com contrato explícito. A comparação de HEAD abaixo deteta novos commits, não todas as alterações ao código. Use-a só num worktree isolado em que cada iteração que altera código registe um commit local de controlo antes da comparação. Alterações úteis ainda sem commit não mudam HEAD; sem esse contrato, um hash igual pode indicar estagnação falsamente. Guarde também o resultado do verificador: um commit novo prova uma alteração registada, não melhoria nem aprovação da tarefa.

Estrutura ilustrativa de um wrapper com estas três verificações. As linhas de custos e invocação do agente são exemplos específicos do executor, não uma receita de instalação CLI verificada; confirme as interfaces da versão instalada antes de adaptar. Para verificar progresso pelos commits, exija um commit local de controlo em cada iteração que altere código. Se o executor deixar alterações sem commit, pare para revisão em vez de as classificar como «sem progresso».

#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0

for i in $(seq 1 $MAX_ITER); do
  # Limite de dinheiro
  CURRENT_COST=$(claude usage --json | jq '.cost_usd')
  if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
    echo "STOP: budget cap $MAX_COST_USD reached"
    break
  fi

  # Executar
  OUTPUT=$(claude code -p "$PROMPT" --auto-accept)

  # Verificação de conclusão
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: completion signal"
    break
  fi

  # Só mede progresso nos commits: cada iteração com alterações deve criar um commit de controlo.
  # HEAD não deteta alterações úteis ainda sem commit.
  CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
  if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
    STAGNATION=$((STAGNATION + 1))
    if [ "$STAGNATION" -ge 3 ]; then
      echo "STOP: stagnation 3 iterations"
      break
    fi
  else
    STAGNATION=0
  fi
  PREV_HASH="$CURRENT_HASH"
done

Valide a verificação de progresso antes de expandir este esqueleto: uma edição sem commit deve ser tratada como trabalho não registado; um commit de controlo altera HEAD; só o verificador separado pode provar sucesso. Três comparações com o mesmo commit indicam ausência de alterações registadas segundo o contrato, não que todos os ficheiros de trabalho ficaram iguais. A seguir, pode acrescentar: um alerta do Slack quando parar, um relatório automático do Telegram de manhã e uma notificação push quando o orçamento atingir 80%. O princípio é o mesmo: um ciclo precisa de travões, não apenas de um acelerador.

5 cenários prontos a usar para ciclos noturnos#

Cenário 1: Fazer passar os testes que falham

/goal Existem 47 testes que falham na pasta tests/. Objetivo: fazê-los passar a todos.
Execute pnpm test, leia stderr, abra o ficheiro com o erro, corrija-o e execute pnpm test novamente.
Pare quando exit 0. Máximo de 30 iterações.

Cenário 2: Refatorização em grande escala em 200 ficheiros

/batch Substitua o cliente de API antigo apiV1 pelo novo apiV2 em todos os ficheiros sob src/**/*.ts.
Cada ficheiro recebe a sua própria worktree. Após a substituição, execute tsc --noEmit; corrija os erros.
Una as worktrees no final.

Cenário 3: Monitorização da produção durante a noite

/loop 30m A cada 30 minutos, verifique https://your-app.example.com/api/health.
Se não devolver 200, leia os registos, encontre a causa, corrija-a e volte a implementar.
Registe cada iteração em /tmp/night-monitor.log.

Cenário 4: Importar um grande conjunto de dados com deduplicação

/goal Importe o ficheiro CSV /tmp/import.csv (12,000 linhas) para a tabela clients.
Para cada linha, verifique se existe um duplicado pelo endereço de e-mail; se não existir, insira-a; se existir, atualize-a.
Registe os conflitos em /tmp/conflicts.log. Pare quando a última linha tiver sido processada.

Cenário 5: Processo de artigos (configuração típica)

Para um serviço online ou uma agência que precisa regularmente de artigos SEO, o cenário é o seguinte:

/loop 8h A cada 8 horas: abra o ficheiro backlog de temas e procure temas com o estado 'queued'.
Se houver um tema, execute a skill para escrever um guia.
Publique em dev. Altere o estado para 'review'. Notifique a pessoa responsável no Telegram.

O que fornecer em cada iteração: CLAUDE.md e Second Brain como estado#

Três camadas de “memória” do projeto transformam um prompt pontual num ciclo controlado:

1. CLAUDE.md — a constituição do projeto. O que é o produto, qual é a stack, quais são as regras e o que nunca se deve fazer. O Claude lê este ficheiro no início de cada sessão e de cada iteração do ciclo. Sem ele, o Claude tem de “reabrir” o projeto de cada vez — consumindo contexto e aumentando o risco de alucinações. Encontre um modelo pronto a usar e 6 regras no guia CLAUDE.md.

2. Second Brain — uma pasta de conhecimento empresarial: produto, público, objetivos, economia, marketing. Não código — significado. Quando o ciclo escreve um artigo ou procura uma resposta para o apoio ao cliente, consulta o Second Brain e responde com o contexto do projeto, em vez de partir do nada.

3. Context engineering — aquilo que fornece exatamente ao Claude em cada iteração. Não a pasta Second Brain inteira, nem todo o repositório — apenas o que é relevante. O Plan Mode ajuda: o Claude determina de que ficheiros a tarefa precisa e lê apenas esses. Saiba mais no guia Plan Mode.

O principal princípio operacional que tive de interiorizar à custa de erros:

Estas três camadas formam os três pilares da metodologia: clone de IA (ensinou o seu estilo e as suas regras ao Claude através de skills e do CLAUDE.md), Second Brain (significado empresarial em ficheiros) e Context Engineering (aquilo que fornece em cada pedido). Sem os três, o ciclo torna-se um ciclo infinito com uma fatura crescente.

O que acontece em cada sessão? Tarefas diferentes: um ciclo corrige erros, outro escreve novas funcionalidades, um terceiro revê os PRs da equipa, um quarto otimiza o desempenho e um quinto prepara a documentação. Não se trata de um grande agente generalista. São dezenas de agentes especializados, cada um com a sua própria skill, objetivo e verificador.

A mudança fundamental de perspetiva:

Para um empresário sem programadores, isto significa algo concreto. Tem uma conta Claude por $200/mês e um portátil normal. Pode iniciar 5 ciclos em paralelo — apoio ao cliente, artigos, métricas, testes de um novo produto e monitorização da concorrência. Cada um funciona no seu próprio separador do Claude Code. De manhã, lê o resumo. Esta já é a norma de trabalho no verão de 2026.

Quatro falhas comuns dos ciclos autónomos#

Falha 1: “Ciclo de alucinação”

O agente decide que terminou, embora o verificador não tenha sido acionado. Ou não há verificador. Três horas depois, o Claude diz: “Está tudo feito!” — mas os testes falham, a página não abre e nada funciona. Já gastou $80 em iterações inúteis.

Solução: um verificador rigoroso (o exit code do comando), não uma verificação verbal.

Falha 2: “O orçamento esgotou-se durante a noite”

Sem um limite de orçamento, um ciclo é uma granada sem cavilha.

Solução: /usage limit ou um script externo que utilize claude usage --json para parar o ciclo quando atingir um limite.

Falha 3: “O ciclo perdeu o contexto entre iterações”

Na iteração 1, o Claude tomou uma decisão arquitetural. Na iteração 7, já se tinha esquecido dela e tomou a decisão oposta. Ao fim de 15 iterações, o código é uma confusão.

Solução: uma camada de estado através de CLAUDE.md e da pasta Second Brain. O ciclo escreve todas as decisões arquiteturais num ficheiro que lê na iteração seguinte.

Falha 4: “A condição de paragem é imprecisa — o ciclo nunca termina”

/goal "Torna a página bonita" — o que significa “bonita”? Sem uma métrica inequívoca, o ciclo nunca para. Continua a funcionar até atingir o limite de iterações ou de orçamento.

Solução: a condição de paragem tem de ser sempre mensurável. Não “bonita”, mas “Lighthouse Performance ≥ 90, Accessibility ≥ 95”. Não “funciona”, mas “os testes em tests/pricing.test.ts passam”.

Quando não é necessário usar loop engineering#

Não são adequadas para um ciclo autónomo:

• Tarefa criativa pontual. Um site para um novo produto, um logótipo, um memorando estratégico. Um ciclo é excessivo neste caso; é mais fácil escrever um prompt e aperfeiçoar o resultado manualmente.
• Tarefa sem verificador. Se não consegue expressar a condição de paragem como um código de saída ou um sinal inequívoco, não inicie o ciclo; caso contrário, será uma fogueira interminável.
• Tarefa que exige avaliação subjetiva. “Faz com que soe melhor”, “melhora a UX para ser mais agradável” — estas tarefas precisam de si, não de um ciclo.
• Área nova e desconhecida. Se não compreende o que significa “concluído”, não execute o Claude num ciclo. Primeiro, compreenda a tarefa; depois, automatize-a.

E a principal regra que aprendi com os erros:

A pergunta principal antes de iniciar um ciclo é: Consigo descrever numa linha como saberei que o Claude terminou? Se sim, o ciclo pode ajudar. Se não, defina primeiro uma condição verificável e só depois inicie o ciclo.

Loop engineering é uma camada sobre tudo o que já sabe acerca do Claude Code. Primeiro, precisa dos três pilares: clone de IA + Second Brain + Context Engineering. Sem eles, o ciclo degrada-se a partir da iteração 5. Continue a explorar a Ailoot em ailoot.ai.