Artigos
Chega de Fan-out sem critério: orquestração em quatro camadas com Claude Haiku 5.5 na prática
O Claude Haiku 5.5 é rápido e barato, mas disparar todas as tarefas em paralelo para ele só amplifica erros de julgamento, viés de avaliação e riscos de Supply Chain. Veja como estruturar uma arquitetura em camadas com Fable no julgamento, Opus na orquestração, Sonnet e Haiku na implementação, validação por CI e aceite no Opus — e saiba quando o Fan-out realmente vale a pena.
· 8 min de leitura
O Claude Haiku 5.5 foi lançado em 7 de outubro de 2026. Para prompts de até 100,000 tokens, o custo é um vigésimo do Sonnet 5.5, e a latência é a menor de toda a geração atual do Claude.
Sendo tão barato e rápido, a tentação é imediata: quebrar todas as tarefas de código em pedaços menores, disparar tudo em paralelo para um enxame de Haiku e esperar o resultado.
Para protótipos, isso pode até funcionar. Em um ambiente de engenharia de produção, porém, você esbarra rapidamente em três gargalos:
- Modelos menores lidam mal com ambiguidade. O posicionamento oficial do Haiku 5.5 é para classificação, extração, roteamento e tarefas de subagent que exigem alto volume e baixa latência. Quando o requisito carrega ambiguidades de negócio e depende do contexto do sistema como um todo, ele tende a entregar um código com cara de pronto, mas que apostou na direção errada.
- Pedir para um modelo escolher a melhor solução introduz viés de avaliação. Ao jogar dezenas de implementações para um modelo grande revisar, ele tende a escolher a versão com a arquitetura "visualmente mais elegante", e não necessariamente a que está correta na lógica e na execução.
- Privilégios escalam junto com a quantidade de Workers. Se você permitir que subagents paralelos instalem pacotes ou alterem configurações por conta própria, cada um dos N Workers vira uma porta de entrada a mais para pacotes maliciosos.
Por isso, migrei para uma abordagem de Hierarchical Orchestration (orquestração hierárquica): cada camada faz estritamente aquilo em que é boa, e o paralelismo do Haiku só entra onde realmente faz sentido.
Indo direto ao ponto: o Fable pensa e planeja, o Opus distribui e faz o aceite, o Sonnet cuida da implementação principal, e o Haiku assume apenas tarefas mecânicas ou de busca com validação automatizada. Os candidatos passam primeiro pelo CI antes de qualquer modelo bater o olho.
Arquitetura em quatro camadas: julgamento, orquestração, validação e aceite#
Entrada do requisito
│
▼
[Camada de Julgamento] Fable: decisões de arquitetura, quebra de tarefas, critérios de aceite
│
▼
[Camada de Orquestração] Opus Main Session: apenas distribui, sem refazer a quebra
├─► Caminho A: complexo, mas com escopo claro ──► Implementação com Sonnet
├─► Caminho B: tarefa mecânica ──► Um único Haiku
├─► Caminho C: exploração/múltiplas abordagens ──► Vários Haiku, cada um em seu Git Worktree
│
▼
[Camada de Validação] Build, Type Check, Test, Benchmark (Caminho C mantém só o top 2–3)
│
▼
[Camada de Aceite] Opus consolida segundo os critérios de aceite
Escalation Path se falhar: Haiku tenta corrigir 2 vezes ➔ Sonnet ➔ Devolve para Opus
O papel de cada modelo nessa estrutura foi definido pelo seu posicionamento oficial e custo. Abaixo estão os números da documentação oficial da Anthropic em 8 de outubro de 2026, com valores em dólares por milhão de tokens:
| Modelo |
Posicionamento oficial |
Latência |
Preço de Input / Output |
| Claude Fable 5.1 |
Raciocínio de alta complexidade e fluxos agentic de longa duração |
Mais lenta |
$10 / $50 |
| Claude Opus 5.5 |
Coding agentic de longa duração e trabalho com base de conhecimento |
Média |
$4 / $20 |
| Claude Sonnet 5.5 |
O melhor equilíbrio entre velocidade e capacidade |
Rápida |
$2 / $10 |
| Claude Haiku 5.5 |
Classificação, extração, roteamento e tarefas de subagent de alto volume e baixa latência |
Mais rápida |
A partir de $0.10 / $0.50 |
O preço do Haiku 5.5 funciona em duas faixas: se o prompt ultrapassar 100,000 tokens, o valor sobe para $0.50 / $2.50.
Camada de Julgamento: Fable para decisões de arquitetura e critérios de aceite#
Nem todo requisito precisa passar pelo Fable. Por ser a camada mais cara e lenta, só recorro a ele quando há ambiguidade nos requisitos, integrações complexas entre múltiplos sistemas ou decisões estruturais de arquitetura a serem tomadas.
O Fable precisa entregar três artefatos:
- O desenho da solução
- A quebra das tarefas
- Os Acceptance Criteria (critérios de aceite) verificáveis por testes para cada subtarefa
O raciocínio e a decomposição precisam nascer na mesma camada. Quem consegue enxergar os pontos cegos do sistema é quem tem capacidade de desenhar subtarefas com fronteiras limpas; deixar a arquitetura com o modelo A e a quebra com o modelo B quase sempre resulta em contratos e interfaces mal definidos.
Tarefas de segurança são uma exceção. Os modelos Claude desta geração contam com classificadores de segurança que retornam stop_reason: "refusal" quando uma requisição é bloqueada, o que pode causar falsos positivos mesmo em fluxos legítimos de análise de vulnerabilidades. Como o classificador do Fable 5.1 cobre grande parte do conteúdo de segurança ofensiva — e a própria documentação aponta que ele não foi desenhado para essa área —, prefiro delegar a análise inicial para o Opus 5.5, que permite auditar código-fonte em busca de falhas sem atritos desnecessários.
Camada de Orquestração: Opus apenas distribui, sem refazer a quebra#
O Opus atua como a Main Session, responsável pelo roteamento e pelo despacho das tarefas. Essa camada não redesenha a arquitetura nem faz uma segunda decomposição do trabalho.
- Caminho A, complexo mas com escopo bem definido: tarefas com regras de negócio densas, mas cujas interfaces já estão delimitadas, vão para o Sonnet. Ele é o cavalo de batalha da implementação.
- Caminho B, tarefas puramente mecânicas: Boilerplate, renomeação de variáveis, testes unitários triviais ou atualização de documentação ficam a cargo de um único Haiku.
- Caminho C, exploração e otimização: tuning de performance, alternativas para queries SQL complexas ou Regex, e investigação de Flaky Test disparam o Fan-out: múltiplos Haiku entram em cena, cada um testando uma abordagem em um Git Worktree isolado.
Independentemente do caminho escolhido, todo código produzido segue direto para a camada de validação.
Camada de Validação: primeiro as máquinas, depois o modelo#
Um padrão muito comum é pegar todo o código gerado em paralelo e jogar para o Opus ou Sonnet fazer o code review via prompt.
O problema é que LLMs são facilmente seduzidos por código bem formatado e com tipagem elegante, o que não garante em nada que os casos de borda foram atendidos. Por isso, as soluções candidatas precisam passar pelo crivo automatizado da máquina primeiro:
- Build e Type Check: compila sem erros e respeita os tipos.
- Unit / Integration Tests: passa em todos os testes unitários e de integração.
- Benchmark / Profiling: mede consumo de memória e latência.
Se quebrou nos testes automatizados, é descartado na hora. No Caminho C, o Opus só recebe os 2–3 melhores candidatos que passaram por todos os checks, poupando context window e token.
Camada de Aceite: Opus consolida; se falhar, escala#
Por fim, o Opus consolida o resultado confrontando-o com os critérios de aceite estabelecidos lá atrás pela camada de julgamento. Se um Worker travar, seguimos um Escalation Path bem definido:
- Se o Haiku falhar e não resolver após 2 tentativas automáticas de correção, o ciclo é interrompido.
- O Sonnet assume a tarefa para corrigir o problema.
- Se nem o Sonnet passar no aceite, isso geralmente indica uma contradição nas premissas ou na quebra da tarefa. O trabalho é devolvido ao Opus, que decide se o caso deve subir de volta ao Fable para um novo desenho.
Três regras essenciais antes de rodar em produção#
Não faça Fan-out às cegas#
Tarefas simples não precisam de múltiplos Workers, e tarefas ambíguas demais estão além do alcance de modelos menores. O paralelismo com vários Haiku só compensa quando o espaço amostral de soluções é amplo e existe uma suite de testes automatizados capaz de validar o resultado rapidamente.
Isole os ambientes e trave o Lockfile#
O Git Worktree isola apenas as alterações no sistema de arquivos, garantindo que Workers paralelos não sobrescrevam o trabalho uns dos outros; ele não restringe acesso à rede nem impõe limites de execução. Para mitigar o risco de Supply Chain Attack, você precisa rodar tudo em sandbox e proibir terminantemente que os Workers instalem dependências não homologadas ou editem o Lockfile. Liberar comandos de instalação sem controle é um convite para Agents injetarem scripts e pacotes suspeitos na sua codebase.
Baseie o aceite em métricas, não na opinião do modelo#
Resultados de testes, cobertura de código, uso de memória e latência são métricas determinísticas, reproduzíveis e comparáveis. O feedback em texto gerado por um modelo pode servir como apoio, mas nunca como critério definitivo para homologar a qualidade do código.
Modelos baratos devem ser usados nos lugares certos#
O Haiku 5.5 barateou brutalmente o paralelismo, mas paralelizar código por si só não torna a resposta correta. Quando você separa julgamento, despacho, validação e aceite, a velocidade e o baixo custo deixam de ser uma armadilha e viram uma vantagem competitiva real.
Essa divisão em camadas nada mais é do que o Graph que apresentei em AI Agents nada mais são do que um time ágil: quem começa, para quem passa o bastão e para onde escalar quando algo quebra.