Engenharia Baseada em Threads

Como você sabe, de verdade, que está ficando melhor em engenharia assistida por IA?

Não "sentindo que sou produtivo." Contando. Medindo. Mostrando, com números, que essa semana foi melhor do que a anterior.

A engenharia baseada em threads é o framework que torna isso possível. Cada pedaço de trabalho assistido por IA vira uma unidade discreta chamada thread. Quando o trabalho aparece como threads, você consegue ajustá-las.

Uma thread é uma unidade de trabalho de engenharia ao longo do tempo, conduzida por você mais um agente.

Dois nós em toda thread precisam de um humano:

1. O começo. Você faz o prompt ou planeja.
2. O fim. Você revisa ou valida.

E o meio? O agente cuida disso com tool calls.

Essa é a thread base. Toda vez que você abre o Claude Code e roda um prompt, você iniciou uma thread. O agente executa tool calls (lê arquivos, escreve código, roda comandos), e quando para, você verifica o resultado.

Ideia simples. Consequências grandes.

O insight central: tool calls equivalem aproximadamente a impacto (assumindo que o prompt valia a pena rodar).

Antes de 2023, as tool calls eram você. Você editava o código. Você abria os arquivos. Você rodava os comandos. A cadeia toda era manual.

Hoje você aparece no começo (prompt) e no fim (revisão). O meio roda sozinho.

Quem rodar mais tool calls úteis ganha de quem rodar menos. Esse é o novo placar.

Quando a thread base faz sentido, escalar vem em seguida. Seis padrões cobrem quase todo workflow assistido por IA.

1. Thread Base

A fundação. Um prompt, trabalho do agente, uma revisão.

Todos os padrões abaixo se constroem sobre esse. Uma thread base instável significa que nada mais acima funciona também.

Use para: Tarefas simples, correções rápidas, mudanças em arquivo único.

2. P-Threads (Execução Paralela)

Várias threads rodando ao mesmo tempo.

Boris Cherny, que criou o Claude Code, mantém cinco instâncias do Claude Code abertas no terminal, numeradas de 1 a 5. Além disso, roda de 5 a 10 na interface web do Claude Code.

Chame de 10 a 15 threads paralelas. Um agente entrega o auth, outro trabalha nos endpoints de API, outro escreve testes. Você prompta, vai para a próxima aba, prompta, vai para a próxima, prompta. Depois volta para revisar.

Use para: Tarefas independentes, revisões de código, branches de features, pesquisa.

Como melhorar: Abra mais janelas de terminal. Empurre agentes em segundo plano para a interface web do Claude Code. Fork de terminais com tooling customizado.

3. C-Threads (Workloads Encadeados)

Trabalho em múltiplas fases com checkpoints humanos entre as fases.

Às vezes o trabalho não cabe em uma janela de contexto. Ou as apostas são altas o suficiente para você querer olhar cada passo antes do próximo começar.

C-threads dividem o trabalho em fases:

• Fase 1: Migração de banco de dados
• Fase 2: Atualizações de API
• Fase 3: Mudanças no frontend

Você revisa entre as fases. Qualquer coisa quebrada é pega cedo, antes de virar um rollback enorme.

Use para: Deploys em produção, grandes refatorações, migrações sensíveis, workflows de múltiplos passos.

Trade-off: Sua atenção. C-threads custam mais tempo humano. Rode-as quando o risco justificar.

A ferramenta ask user question no Claude Code suporta C-threads nativamente. Um agente pode pausar no meio do workflow e te perguntar algo antes de avançar para a próxima fase.

4. F-Threads (Fusão)

Um prompt, muitos agentes, depois você mescla os melhores resultados.

Pense em "melhor de N" em workflows inteiros. Dispare o mesmo prompt para quatro agentes. Veja todas as quatro saídas. Escolha o vencedor. Ou combine as peças mais fortes de várias saídas em algo melhor do que qualquer uma sozinha.

Por que funciona: Mais tentativas aumentam as chances de sucesso. Um agente pode travar enquanto outro acerta. Quatro ângulos batem em um.

Use para: Prototipagem rápida, perguntas de pesquisa, decisões de arquitetura, revisões de código onde a confiança importa.

O futuro da prototipagem: F-threads vão dominar a prototipagem rápida. Lance vários agentes, passe o mesmo problema para eles, funda as saídas. Mais compute compra mais confiança.

5. B-Threads (Big/Meta)

Uma thread que contém outras threads dentro dela.

É aqui que as coisas ficam meta. Prompts disparam outros prompts. Sub-agentes criam mais sub-agentes. Um agente orquestrador roda um planejador, depois um construtor, depois um revisor.

Do seu lugar como engenheiro, você ainda só prompta no começo e revisa no fim. Por baixo, múltiplas threads rodam sozinhas.

O exemplo mais claro: Sub-agentes. Diga ao Claude Code para "usar sub-agentes para lidar com essas três tarefas" e ele cria três threads dentro de si mesmo. Um prompt seu, três threads rodando.

Use para: Mudanças complexas em múltiplos arquivos, workflows de time de agentes, builds orquestrados.

O padrão: Agentes escrevem prompts para você. O orquestrador escreve prompts para os agentes trabalhadores. A saída sobe 10x sem o esforço subir 10x.

6. L-Threads (Longa Duração)

Autonomia estendida sem humano no loop.

A thread base, esticada até o limite. Não 10 tool calls. Tente 100. Não 5 minutos. Tente 5 horas. Boris já rodou threads por mais de 26 horas.

L-threads precisam de:

• Prompts fortes (grande planejamento equivale a grande prompting)
• Verificação sólida (para o agente saber quando terminou)
• Estado com checkpoint (para o trabalho sobreviver aos limites de contexto)

A ligação com Ralph: A técnica Ralph Wiggum é construída em torno de L-threads. Um stop hook mantém o agente em loop até o trabalho estar realmente feito. Sem saídas antecipadas. Sem precisar de mão na roda.

Use para: Builds de features durante a noite, grandes bases de código, queima do backlog.

Mais um tipo de thread aponta para onde a engenharia está indo.

Z-threads: Threads de toque zero. Confiança total nos seus agentes. Nenhum nó de revisão.

Isso não é vibe coding. É engenharia agêntica com tanta verificação e tantas proteções que revisar a saída é genuinamente opcional.

O agente deploya para produção. Monitora analytics. Decide se a mudança funcionou. Itera.

A maioria dos engenheiros ainda não está lá. Mas tudo aponta nessa direção. O objetivo: sistemas confiáveis o suficiente para a revisão parar de ser necessária.

Todo padrão de thread volta a quatro fundamentos:

1. Contexto: O que o agente sabe
2. Modelo: Qual modelo está rodando
3. Prompt: O que você está pedindo
4. Ferramentas: O que o agente pode tocar

Acerte esses quatro e você tem agentes. Qualquer otimização de thread cai em um deles.

• Prompts melhores significam threads mais longas
• Contexto melhor significa trabalho mais preciso
• Ferramentas melhores significam mais capacidades
• Modelos melhores significam maior confiabilidade

Para L-threads especialmente, o stop hook carrega o peso.

Quando seu agente tenta parar, o stop hook intercepta:

1. O agente tenta completar
2. O stop hook roda código de validação
3. Decisão: A tarefa está realmente completa?
4. Se não: Bloqueia a parada, continua iterando
5. Se sim: Permite a conclusão

Esse é o núcleo técnico dos loops Ralph. O stop hook não deixa o agente sair quando acha que terminou. Deixa o agente sair quando o trabalho está verificado.

A engenharia baseada em threads te dá algo que você pode medir de verdade.

1. Rode Mais Threads (P-Threads)

Você consegue adicionar mais agentes paralelos? Boris está em 10 a 15. Você consegue chegar a 5? Consegue chegar a 3?

Meça: Threads concorrentes rodando.

2. Rode Threads Mais Longas (L-Threads)

As threads conseguem ir mais longe em tool calls antes de você precisar intervir?

Meça: Média de tool calls por thread antes da intervenção.

3. Rode Threads Mais Espessas (B-Threads)

As threads conseguem ficar dentro de threads? Um prompt consegue se expandir em cinco sub-agentes?

Meça: Trabalho por prompt que você escreve.

4. Rode Menos Checkpoints

Você consegue reduzir o número de revisões humanas? Sua verificação gera confiança suficiente para pular algumas?

Meça: Fases que rodam antes de uma verificação manual.

Melhoria em qualquer uma dessas quatro dimensões é melhoria real como engenheiro agêntico. Essa é a métrica. É assim que você sabe.

Veja como isso parece em um dia real:

Segunda de manhã: Cinco features para entregar.

Jeito antigo: Feature 1. Pronto. Feature 2. Pronto. Repete. Cinco sessões sequenciais.

Jeito baseado em threads:

1. Escreve specs para todas as cinco features (fase de planejamento)
2. Lança cinco instâncias paralelas do Claude Code (P-threads)
3. Passa uma feature para cada instância
4. Revisa os primeiros resultados prontos enquanto o resto roda
5. Algumas features precisam de fases divididas (C-threads)
6. A mais difícil cria sub-agentes (B-thread)
7. A tarefa da noite roda como L-thread com loop Ralph

As mesmas cinco features. Só que agora você está rodando mais threads, threads mais espessas e threads mais longas.

Engenharia baseada em threads e loops Ralph se encaixam juntos.

Ralph responde à pergunta: como mantenho um agente rodando de forma confiável até estar genuinamente pronto?

Engenharia baseada em threads responde: como escalo o uso de agentes e meço que estou melhorando?

Ralph entrega L-threads. A engenharia baseada em threads diz quando L-threads batem P-threads e quando B-threads são a chamada certa.

O stop hook por trás do Ralph é o mesmo stop hook que mantém L-threads vivas. Desenvolvimento verification-first é o que faz qualquer padrão funcionar.

Os engenheiros que estão na frente não estão só "usando IA." Eles pensam em threads.

Toda tarefa começa com uma pergunta: que tipo de thread é essa? Paralelizar? Encadear? Aninhar sub-threads dentro?

O gargalo mudou. Antes era "quão rápido consigo codar?" Agora é "quantas threads úteis consigo rodar?"

Escale seu compute. Escale seu impacto.

Comece pequeno:

1. Audite seu trabalho: Quantas threads você roda agora? (Para a maioria dos engenheiros: 1.)

2. Adicione uma P-thread: Abra um segundo terminal. Rode uma tarefa paralela enquanto o primeiro agente ainda está ocupado.

3. Cronometre suas threads: Conte tool calls antes de intervir. Acompanhe esse número.

4. Tente uma C-thread: Quebre uma tarefa grande em fases explícitas. Revise entre as fases.

5. Trabalhe em direção a L-threads: Monte a verificação. Deixe um agente rodar 30 minutos sem supervisão.

O ponto não é chegar a 15 Z-threads paralelas amanhã. O ponto é ganho constante e mensurável. Mais threads. Threads mais longas. Threads mais espessas. Menos checkpoints.

Essa é a única forma real de saber que você está melhorando. Não sentindo. Contando.

• Adicione loops Ralph Wiggum para autonomia de L-thread
• Explore workflows assíncronos para rodar agentes paralelos
• Estude design de sub-agentes para arquiteturas de B-thread
• Construa feedback loops para padrões de verificação

A engenharia baseada em threads transforma o código com IA de artesanato em prática mensurável. Você consegue rastrear. Consegue melhorar. Consegue escalar.

Comece a contar suas threads.