Claude Code Autónomo

Duas ideias estão a reconfigurar a forma como os engenheiros conduzem agentes de IA: os loops Ralph Wiggum e a engenharia baseada em threads.

O Ralph é o manual para manter um agente a correr sozinho. As threads são o manual para escalar e medir essa autonomia. Ligadas juntas, são um sistema funcional para construir software sem um humano ao volante.

Este post é a ligação.

O Modelo Unificado

Aqui está como as peças se encaixam:

A engenharia baseada em threads fornece o esqueleto. O teu modelo mental são threads: base, paralelas, em cadeia, fusão, grandes e de longa duração. Cada tipo de thread tem a sua própria função.

Os loops Ralph conduzem as L-threads. O padrão de stop hook, a promessa de conclusão e o desenvolvimento verificação-primeiro transformam execuções autónomas longas em algo em que podes realmente confiar.

A verificação é o que mantém tudo de pé. Sem ela, as threads terminam demasiado cedo e os loops giram para sempre.

Thread Types × Verification → Reliable Autonomous Work
     ↓
Ralph Loops = Implementation of L-Threads
     ↓
Result: Features shipping while you sleep

A Stack de Verificação

A regra do Boris Cherny cabe numa frase: dá sempre ao Claude uma forma de verificar o seu trabalho.

Aparece em cada camada do modelo unificado:

Uma coisa importa mais do que as outras. Quanto mais longa é a thread, mais a sua verificação tem de correr sozinha. Ninguém revê uma L-thread de 26 horas à mão. O sistema tem de se verificar a si próprio.

Construir a Stack Completa

Aqui está uma configuração funcional que cola todos os conceitos:

Camada 1: Especificação (O Pin)

Cada execução autónoma começa com uma especificação. Essa especificação é o teu pin. Impede o agente de inventar o problema.

## Feature: User Dashboard
 
### Scope
 
- Display user metrics
- Show recent activity
- Add export functionality
 
### Out of Scope
 
- Real-time updates (Phase 2)
- Mobile responsiveness (Phase 2)
 
### Acceptance Criteria
 
- [ ] Metrics load in under 2 seconds
- [ ] Activity shows last 30 days
- [ ] Export generates valid CSV

Aponta para código existente quando podes. Diz o que o agente não deve fazer. Define o que "feito" parece em termos concretos.

Camada 2: Verificação Orientada por Testes

Escreve os testes primeiro. Esses testes são a camada de verificação que torna as L-threads confiáveis.

// For each acceptance criterion, create a test
tests/
  dashboard/
    metrics.test.ts      # Verifies metrics load time
    activity.test.ts     # Verifies activity display
    export.test.ts       # Verifies CSV generation

Os agentes a correr executam testes vezes sem conta. Um loop não pode fechar até os testes ficarem verdes. Nada vago. Sem saídas antecipadas.

Camada 3: O Stop Hook

Define o teu stop hook para impor verificação:

// stop-hook.js
module.exports = async function (context) {
  // Run test suite
  const testResult = await runTests();
 
  if (testResult.failed > 0) {
    return {
      decision: "block",
      reason: `${testResult.failed} tests failing. Continue work.`,
    };
  }
 
  // Check for completion promise
  if (!context.output.includes("complete")) {
    return {
      decision: "block",
      reason: "Completion promise not found. Verify all work is done.",
    };
  }
 
  return { decision: "allow" };
};

O stop hook é o segurança. Ignora o que o Claude pensa. Só se preocupa se os testes passam.

Camada 4: Seleção de Thread

Agora escolhe o tipo de thread que se adequa ao trabalho:

Funcionalidade pequena, um ficheiro: Thread base. Prompt, o agente trabalha, revisão.

Cinco funcionalidades independentes: P-threads. Abre cinco terminais, atribui uma funcionalidade a cada um.

Migração de base de dados com três fases: C-thread. Verifica após cada fase antes de continuar.

Decisão de arquitetura crítica: F-thread. Obtém opiniões de três agentes, compara resultados.

Build de funcionalidade durante a noite: L-thread com loop Ralph. Define e deixa correr antes de ir dormir.

Refatoração multi-ficheiro com sub-tarefas: B-thread. O orquestrador cria workers para cada ficheiro.

Camada 5: Estado de Checkpoint

Mantém o estado fora do agente. Isto é especialmente importante para L-threads:

## Progress: User Dashboard
 
### Completed
 
- [x] Set up test infrastructure
- [x] Implement metrics API endpoint
- [x] Create metrics display component
 
### In Progress
 
- [ ] Implement activity feed
 
### Remaining
 
- [ ] Add export functionality
- [ ] Performance optimization

O agente reescreve este ficheiro enquanto trabalha. Se a janela de contexto encher e o agente reiniciar, lê o ficheiro de progresso e continua de onde parou.

Verificação de UI: A Peça em Falta

Os testes podem passar enquanto o ecrã está quebrado.

Qualquer thread que toque UI precisa de verificação baseada em screenshots por cima do conjunto de testes:

Workflow extension for UI work:

1. Complete implementation
2. Take screenshots of affected components
3. Review each screenshot for visual issues
4. Rename verified screenshots with "verified_" prefix
5. Do NOT output completion promise yet
6. Run one more loop to confirm all screenshots verified
7. Only then output "complete"

É isso que força a revisão visual. O Claude não tem forma de saltar a verificação de screenshot e ainda chamar o trabalho de concluído.

Escalar com Loom

O próximo nível é a orquestração estilo Loom.

O Loom é um ambiente construído para agentes em vez de humanos. Liga os loops Ralph em sistemas reativos.

Nível 1: Loop Ralph único (L-thread) Nível 2: Múltiplos loops Ralph em paralelo (P-threads de L-threads) Nível 3: Cadeias orquestradas de loops (B-threads contendo L-threads) Nível 4: Sistemas de produto autónomos (agentes que fazem ship, observam e iteram)

No Nível 4, os agentes:

• Fazem ship atrás de feature flags
• Fazem deploy sem revisão de código
• Observam analytics
• Decidem se as mudanças funcionaram
• Iteram automaticamente

Este é o endpoint da Z-thread. Zero input humano. Autonomia total.

Economia dos Loops Autónomos

Manter um agente a correr custa cerca de $10,42 USD por hora no Sonnet.

Isso reinicia a matemática.

O custo não é o limite. O limite é quanto trabalho confiável consegues definir.

As equipas que acertam nos loops verificação-primeiro vão fazer ship a uma taxa diferente das que não acertam. Não um pouco diferente. Uma taxa completamente diferente.

Padrões de Integração Comuns

Padrão 1: Planeamento + L-Thread

1. C-thread para planeamento (tu verificas o plano)
2. Contexto fresco
3. L-thread para implementação (loop Ralph)
4. Revisão final

Porque funciona: Planeamento e implementação vivem em contextos separados. Gastas a tua atenção no plano. O build corre sozinho.

Padrão 2: Sprint de Funcionalidades com P-Thread

1. Escreve especificações para múltiplas funcionalidades
2. Ativa P-threads (uma por funcionalidade)
3. Cada P-thread corre como uma L-thread internamente
4. Revê as funcionalidades concluídas à medida que terminam

Porque funciona: O paralelismo vive ao nível da funcionalidade. A autonomia vive ao nível da implementação.

Padrão 3: Arquitetura com F-Thread

1. Define a questão de arquitetura
2. Ativa F-thread (3-4 agentes)
3. Cada agente propõe uma solução
4. Compara resultados, escolhe o melhor
5. Implementa a solução escolhida com L-thread

Porque funciona: Tens várias perspetivas sobre as decisões que custam caro errar. Uma vez escolhido, o build corre de forma autónoma.

Padrão 4: Orquestração com B-Thread

1. Agente principal recebe tarefa grande
2. Decompõe em sub-tarefas
3. Cria agentes workers (cada um corre mini L-thread)
4. Agrega resultados
5. Agente principal verifica e faz commit

Porque funciona: O trabalho divide-se de forma limpa. Cada worker mantém um foco estreito. O agente principal mantém a thread unida.

Modos de Falha e Soluções

As Threads Terminam Demasiado Cedo

Causa: Verificação fraca Solução: Adiciona mais testes. Torna os critérios de conclusão objetivos. Usa verificação de screenshots para UI.

As L-Threads Giram Para Sempre

Causa: Tarefa impossível ou promessa de conclusão em falta Solução: Define máximo de iterações. Adiciona critérios de conclusão explícitos. Certifica-te de que o agente sabe quando emitir a promessa.

As P-Threads Criam Conflitos

Causa: Agentes a editar os mesmos ficheiros Solução: Isola por funcionalidade ou ficheiro. Usa git worktrees. Traça linhas duras entre trabalho paralelo.

As B-Threads Perdem Coerência

Causa: Sub-agentes desviam-se do objetivo principal Solução: Melhores especificações. Mais pontos de controlo. O orquestrador revê o output dos sub-agentes.

A Verificação Passa Mas o Trabalho Está Errado

Causa: Os testes não cobrem o requisito real Solução: Critérios de aceitação mais rigorosos. Verificação de screenshots para UI. Revê manualmente as primeiras execuções.

O Caminho de Implementação

Começa onde estás. Constrói em direção à autonomia total uma semana de cada vez.

Semana 1: Corre threads base confiáveis. Verifica cada resultado manualmente.

Semana 2: Adiciona P-threads. Corre dois agentes em paralelo. Gere a mudança de contexto.

Semana 3: Implementa verificação orientada por testes. Escreve testes antes da implementação.

Semana 4: Experimenta a tua primeira L-thread. Usa o stop hook. Define um número máximo de iterações. Observa correr.

Semana 5: Escala as L-threads. Corre-as durante a noite. Confia na verificação.

Semana 6: Adiciona B-threads. Deixa o teu agente criar sub-agentes. Orquestra mudanças multi-ficheiro.

Semana 7: Experimenta F-threads. Obtém múltiplas opiniões sobre decisões de arquitetura.

Semana 8: Combina padrões. P-threads de L-threads. B-threads contendo F-threads.

Mede cada semana. Quantas threads. Quanto tempo correram. Quantos pontos de controlo o trabalho precisou.

O Destino

A engenharia de software está a avançar em direção a loops autónomos escalados através de pensamento baseado em threads.

• Mais threads: Paralelismo em cada nível
• Threads mais longas: Horas e dias, não minutos
• Threads mais espessas: Agentes a criar agentes a criar agentes
• Menos pontos de controlo: A verificação substitui a revisão

Os developers que trabalham desta forma não estão apenas "a usar IA." Estão a gerir fábricas de software autónomas.

O Ralph dá-te o loop. As threads dão-te a forma. A verificação dá-te a confiança.

Junta os três e tens sistemas que fazem ship enquanto dormes.

Próximos Passos

• Começa com loops Ralph Wiggum para as bases das L-threads
• Aprende engenharia baseada em threads para o modelo mental
• Estuda feedback loops para padrões de verificação
• Explora workflows assíncronos para gestão de P-threads
• Constrói agentes personalizados para orquestração B-thread

O loop é simples. A verificação é o que importa. As threads são o multiplicador.

Agora começa a construir.