Artigos
Pára de fazer Fan-out às cegas: arquitetura de orquestração em quatro camadas com o Claude Haiku 5.5 na prática
O Claude Haiku 5.5 é rápido e barato, mas atirar-lhe todas as tarefas em paralelo apenas amplifica falsos julgamentos, viés de avaliação e riscos de Supply Chain. Este artigo disseca uma arquitetura em camadas com julgamento pelo Fable, orquestração pelo Opus, implementação pelo Sonnet e Haiku, validação em CI e aceitação pelo Opus — e mostra que tarefas realmente justificam o Fan-out.
· 7 min de leitura
O Claude Haiku 5.5 foi lançado a 7 de outubro de 2026. Para prompts até 100,000 tokens, o seu preço é um vigésimo do Sonnet 5.5, e a sua latência é a mais rápida de toda a geração atual do Claude.
Sendo tão barato e rápido, a tentação é óbvia: dividir todas as tarefas de coding, dispará-las em paralelo para um conjunto de instâncias do Haiku e dar o trabalho por concluído.
Isto até pode funcionar durante a fase de protótipo. Mas num ambiente de engenharia em produção, vai bater de frente com três problemas muito depressa:
- Modelos pequenos não lidam bem com ambiguidade. O posicionamento oficial do Haiku 5.5 foca-se em classificação, extração, encaminhamento e subagent — tarefas de grande volume e baixa latência. Quando os requisitos trazem ambiguidade de negócio e exigem o contexto de todo o sistema, ele tende a entregar resultados que parecem completos, mas que adivinharam a direção errada.
- Deixar o modelo escolher a resposta introduz viés de avaliação. Se submeter dezenas de outputs a um modelo grande, ele terá tendência a escolher a versão com «melhor aspeto arquitetural», em vez daquela cuja lógica e execução estão efetivamente corretas.
- As permissões amplificam-se com o número de Workers. Se permitir que subagents em paralelo instalem pacotes ou alterem configurações automaticamente, lançar N Workers significa abrir N portas de entrada para pacotes maliciosos.
Por isso, mudei para uma abordagem de orquestração hierárquica (Hierarchical Orchestration): cada camada faz estritamente aquilo em que é boa, e o paralelismo do Haiku é reservado apenas para onde é realmente necessário.
A conclusão primeiro: O Fable pensa e estrutura, o Opus despacha e valida, o Sonnet assume a implementação principal, e o Haiku trata de tarefas mecânicas e de exploração que permitam verificação automatizada. As soluções candidatas passam primeiro pelo CI, só depois vão ao modelo.
Arquitetura em quatro camadas: julgamento, orquestração, validação e aceitação#
Entrada de requisitos
│
▼
[Camada de Julgamento] Fable: decisões de arquitetura, divisão de tarefas, critérios de aceitação
│
▼
[Camada de Orquestração] Opus Main Session: apenas despacha, não refaz a divisão
├─► Caminho A: complexo com limites claros ──► Implementação com Sonnet
├─► Caminho B: tarefas mecânicas ──► Único Haiku
├─► Caminho C: exploração, múltiplas soluções ──► Vários Haiku, cada um no seu Git Worktree
│
▼
[Camada de Validação] Build, Type Check, Test, Benchmark (Caminho C mantém apenas o top 2–3)
│
▼
[Camada de Aceitação] Opus consolida segundo os critérios de aceitação
Em caso de falha, escala: Haiku tenta corrigir 2 vezes sem sucesso ➔ Sonnet ➔ Devolve ao Opus
A camada onde cada modelo opera foi definida com base no seu posicionamento oficial e custo. Abaixo estão os valores da documentação oficial da Anthropic a 8 de outubro de 2026, com preços em dólares por milhão de tokens:
| Modelo |
Posicionamento oficial |
Latência |
Preço Input / Output |
| Claude Fable 5.1 |
Raciocínio de alta complexidade e trabalho agentic de longa duração |
Mais lenta |
$10 / $50 |
| Claude Opus 5.5 |
Agentic coding e trabalho de conhecimento de longa duração |
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, encaminhamento e subagent de alto volume e baixa latência |
A mais rápida |
A partir de $0.10 / $0.50 |
O preço do Haiku 5.5 divide-se em dois escalões: se a prompt ultrapassar os 100,000 tokens, passa para $0.50 / $2.50.
Camada de julgamento: o Fable define a arquitetura e os critérios de aceitação#
Nem todos os requisitos justificam o Fable. É a camada mais cara e lenta; reservo-a apenas para requisitos ambíguos, que envolvam integração entre múltiplos sistemas, ou para decisões estruturais de arquitetura.
O Fable tem de entregar três coisas:
- Desenho da solução
- Divisão de tarefas
- Critérios de aceitação (Acceptance Criteria) verificáveis por testes para cada subtarefa
O raciocínio e a decomposição têm de nascer na mesma camada. Só quem compreende os pontos cegos do sistema consegue recortar subtarefas com fronteiras limpas; deixar a arquitetura para A e a divisão para B costuma resultar em interfaces mal definidas.
A cibersegurança é uma exceção. Esta geração de modelos Claude inclui classificadores de segurança: quando um pedido é bloqueado, devolve stop_reason: "refusal", e até tarefas legítimas de segurança podem ser apanhadas por engano. O classificador do Fable 5.1 cobre grande parte dos tópicos de segurança, e a documentação oficial refere que ele não foi desenhado para essa área; já o Opus 5.5 permite procurar vulnerabilidades no código-fonte. Por isso, em requisitos como a correção de vulnerabilidades de segurança, passo a análise inicial diretamente ao Opus.
Camada de orquestração: o Opus apenas despacha, não refaz a divisão#
O Opus atua como Main Session, responsável pelo encaminhamento e atribuição de trabalho. Esta camada não questiona a arquitetura nem faz uma segunda decomposição.
- Caminho A, complexo mas com limites claros: tarefas com lógica complexa mas fronteiras de interface bem definidas vão para o Sonnet. É o motor principal de implementação.
- Caminho B, tarefas puramente mecânicas: código de suporte (Boilerplate), renomeação de variáveis, adição de testes unitários triviais ou documentação vão para um único Haiku.
- Caminho C, tarefas de exploração e otimização: afinação de desempenho, abordagens alternativas para SQL ou Regex complexos, depuração de Flaky Test — só aqui se ativa o Fan-out: disparam-se múltiplos Haiku, cada um a explorar soluções num Git Worktree isolado.
Independentemente do caminho percorrido, o output tem de passar sempre pela camada de validação.
Camada de validação: máquinas primeiro, modelos depois#
Uma abordagem comum é despejar todo o código gerado em paralelo no Opus ou Sonnet e pedir-lhe uma revisão via prompt.
O problema é que os modelos deixam-se seduzir por código bem indentado e com tipagem impecável, o que não significa de todo que passe os testes de casos limite. Por isso, as soluções candidatas têm de passar primeiro pelo crivo das máquinas:
- Build e Type Check: compilação sem erros e tipos corretos
- Unit / Integration Tests: testes unitários e de integração verdes
- Benchmark / Profiling: medição de desempenho e memória
O que não passar nos testes automatizados é descartado de imediato. No Caminho C, o Opus analisa apenas os 2–3 melhores candidatos validados por estas métricas, poupando context window e tokens.
Camada de aceitação: o Opus consolida, escala se falhar#
No final, o Opus consolida o resultado com base nos critérios de aceitação definidos na camada de julgamento. Se um Worker encravar, segue-se o caminho de escalamento (Escalation Path):
- O Haiku falha: tenta corrigir 2 vezes de forma autónoma; se continuar a falhar, interrompem-se as tentativas.
- O Sonnet assume a tarefa para aplicar a correção.
- Se nem o Sonnet conseguir cumprir os critérios de aceitação, isso normalmente indicia uma contradição na divisão da tarefa ou nos pressupostos iniciais. A tarefa regressa ao Opus, que decide se deve voltar ao Fable para uma nova decomposição.
Três regras antes de levar isto para produção#
Não faças Fan-out às cegas#
Tarefas simples não precisam de múltiplos Workers; tarefas com forte ambiguidade estão além do alcance de modelos pequenos. Apenas tarefas de exploração com um «espaço de soluções amplo» e «verificáveis rapidamente por testes automatizados» justificam a execução paralela de vários Haiku.
Isola o ambiente e tranca o Lockfile#
O Git Worktree isola alterações de código, impedindo que Workers paralelos sobreponham ficheiros; não impõe restrições de rede nem limita o acesso do código ao sistema. Para mitigar o risco de Supply Chain Attack, é imprescindível usar uma sandbox e proibir os Workers de instalar pacotes não auditados ou alterar o Lockfile. Abrir permissões de instalação de forma indiscriminada é convidar o Agent a introduzir scripts e dependências de proveniência duvidosa no repositório.
Resultados de testes, cobertura, consumo de memória e latência são os únicos critérios reprodutíveis e comparáveis. As avaliações textuais do modelo servem como referência, mas nunca como critério de aceitação para a qualidade do código.
Modelos baratos usam-se no sítio certo#
O Haiku 5.5 torna o paralelismo acessível, mas o paralelismo por si só não torna as respostas corretas. Separar o julgamento, o despacho, a validação e a aceitação é o que transforma o baixo custo e a velocidade em vantagens reais.
Esta estrutura em camadas é, no fundo, o Graph de que falei em Um AI Agent é basicamente uma equipa ágil: quem faz primeiro, a quem entrega quando acaba e a quem escala quando algo corre mal.