Dynamic workflows no Claude Code: 100 agentes, uma resposta

Todo mundo está compartilhando o número da manchete, mas o paralelismo não é o que torna os dynamic workflows interessantes. Subir cem agentes é fácil; cem agentes cometendo o mesmo erro plausível com toda a confiança é o resultado padrão. O que a Anthropic entregou de verdade é uma camada adversarial: agentes atacam o problema por ângulos independentes, outros agentes tentam refutar o que eles encontraram, e a execução segue iterando até as respostas convergirem. A refutação é o produto. O paralelismo é só o motor.

A prova concreta

O anúncio da Anthropic abre com o Jarred Sumner (criador do Bun) usando dynamic workflows pra portar o Bun de Zig pra Rust: cerca de 750.000 linhas de Rust, 99,8% da suíte de testes existente passando, e só onze dias entre o primeiro commit e o merge — centenas de agentes em paralelo, com dois revisores por arquivo. Repare por que isso funcionou: portar um runtime tem uma definição de pronto brutal e verificável por máquina (a suíte de testes). O workflow não deu certo porque era grande; deu certo porque o "pronto" era verificável.

Como ligar

Dois caminhos, os dois dentro do Claude Code (CLI, Desktop e a extensão do VS Code — além da API, Amazon Bedrock, Vertex AI e Microsoft Foundry):

1. Só pedir. Comece o pedido com "Create a workflow to…". Na primeira vez que um workflow dispara, o Claude Code mostra o que está prestes a rodar e espera a sua confirmação.
2. Ativar o ultracode. Fica no menu de effort, define o esforço como xhigh e deixa o Claude decidir sozinho quando uma tarefa merece um workflow.

Ele já vem ligado nos planos Max, Team e Enterprise (e quando você usa o Claude Code pela API). No Pro você precisa ativar por conta própria no /config — então, se você nunca viu um workflow disparar, provavelmente o motivo é esse, não o seu prompt.

Quando compensa (e quando só queima dinheiro)

A Anthropic avisa sem rodeios: um workflow consome muito mais tokens que uma sessão normal, e a recomendação é que a primeira execução seja uma tarefa pequena e bem delimitada. Meu filtro como EM tem três checagens — e eu quero as três antes de aprovar o plano:

• A tarefa se espalha naturalmente. Caça a bugs no código inteiro, migrações que atravessam milhares de arquivos, revisões de segurança — exatamente os casos de uso que a Anthropic cita.
• O "pronto" é verificável por máquina. Uma suíte de testes, uma rubrica, um diff que compila. Se você não consegue escrever a regra de verificação, a etapa de refutação não tem o que refutar.
• Errar sai caro. Se um agente sozinho resolve em dois minutos, o workflow é imposto, não ferramenta.

O ângulo de carreira: especificação é a habilidade que viaja

O que esse recurso cobra de você, sem dizer: o gargalo saiu de escrever código e foi pra especificar o "pronto" com precisão suficiente pra um enxame de agentes se auto-verificar. E essa é a mesma habilidade que faz dev brasileiro ser contratado por time internacional — escrever critérios de aceite que um estranho (humano ou agente) consegue executar, de forma assíncrona, sem você na sala. Cada especificação de workflow que você escreve é um treino de comunicação nível staff, em inglês, com feedback imediato sobre se ficou precisa o bastante.

Hoje: escolha uma tarefa real e bem delimitada — uma auditoria de um módulo só, não do repositório inteiro. Escreva a regra de verificação primeiro ("pronto significa a suíte passando e cada achado citando arquivo e linha"), depois peça ao Claude Code pra criar um workflow e leia o plano antes de confirmar. Veja quanto ele gasta antes de apontar isso pra algo maior.

Fontes

• Anthropic — Introducing Dynamic Workflows in Claude Code