Paralelizar subagentes não economiza tempo, adia a conta da revisão

Se as tarefas são independentes, disparar tudo em paralelo parece estritamente melhor do que rodar uma de cada vez. O meu próprio skill de desenvolvimento guiado por plano registra o caso que sustenta essa intuição: quatro módulos independentes, cerca de cinco minutos em paralelo contra cerca de vinte minutos em sequência. O número é real e eu continuo usando esse padrão.

Só que ele mede uma coisa só, o tempo de execução dos quatro dispatches. Quando as quatro saídas voltam, alguém precisa abrir cada uma e comparar com o que foi pedido. Essa parte não roda em paralelo.

Paralelizar subagente não é economia. É adiantar a execução e adiar a conta da revisão.

Os cinco minutos contra vinte dependem de dois pressupostos

O primeiro está explícito no caso: os módulos precisam ser independentes de verdade. Sem arquivo em comum, sem estado compartilhado, sem um dispatch esperando a saída do outro. Quando essa condição não vale, o paralelismo não poupa nada. Ele produz conflito para desfazer depois, e desfazer conflito sai mais caro do que teria saído rodar em sequência desde o começo.

O segundo pressuposto fica implícito, e é o que quebra com mais frequência. O tempo de revisão por saída precisa ser pequeno o bastante para não anular o ganho. Quatro dispatches de cinco minutos seguidos de quatro revisões de dez minutos cada não são mais rápidos que a sequência que você evitou. São mais lentos, com o agravante de que a demora aparece depois, quando você já acha que terminou.

A conta só fecha se revisar as quatro saídas custar menos do que os quinze minutos que o paralelismo poupou. Esse é o teste, e ele não tem nada a ver com quantos dispatches a ferramenta aceita disparar de uma vez.

O modelo errado multiplica o desperdício pelo número de dispatches

A minha regra de dispatch é chata de propósito. O code-reviewer e o test-verifier rodam em Sonnet por padrão. Opus fica reservado para diff que mexe em dinheiro, segurança, concorrência, migração de schema ou lógica de trading. São os lugares onde um problema não pego se acumula em vez de aparecer no dia seguinte.

Recomendo decidir o modelo de cada dispatch antes de acionar qualquer paralelismo. O motivo é aritmético. Pela minha estimativa, rodar tudo em Opus queima algo como cinco vezes o custo em tokens do Sonnet para tarefas que não pedem esse nível de raciocínio: busca de código, escrita de teste, geração de documentação. Disparar N subagentes de uma vez sem essa decisão tomada multiplica o desperdício por N, e o tempo que você ganhou no relógio some na fatura. É estimativa minha, não benchmark publicado. O que importa aqui não é a precisão do múltiplo, é que ele multiplica.

A revisão não encolhe porque o dispatch foi paralelo

Quando eu passo implementação para o Codex, a política é propor e só então confirmar. Nada de disparo automático, mesmo quando a tarefa parece óbvia. E a regra que vem junto é mais dura que a primeira: nunca confiar no resumo que o próprio agente faz do que fez. O que vale é o diff lido contra a intenção original. Fez o que foi pedido, só o que foi pedido, e nada que a intenção não autorizava.

Essa leitura não fica mais barata porque quatro saídas voltaram juntas. Cada uma exige a checagem inteira, do mesmo tamanho que exigiria sozinha. O tempo de execução deixa de crescer com o número de dispatches quando você paraleliza; o tempo de revisão continua crescendo com ele do mesmo jeito.

Com poucos dispatches e checagem rápida, o paralelismo ainda ganha, e é por isso que eu uso. Com muitos dispatches, ou com diffs longos e lógica sensível, disparar um de cada vez e revisar na hora costuma sair mais barato no total. A revisão imediata pega o desvio enquanto o contexto ainda está fresco, e não quatro saídas depois.

Duas perguntas antes de disparar

Antes de acionar vários subagentes de uma vez eu faço duas perguntas. Os módulos são independentes de verdade, sem arquivo nem estado em comum? E dá para revisar todas as saídas em menos tempo do que teria levado rodar tudo em sequência, cada uma no modelo certo para o que ela faz? Se qualquer uma das respostas for não, o caso dos cinco minutos contra vinte não se aplica ali, e o paralelismo apenas trocou o lugar da demora.

A condição que derrubaria esse argumento é fácil de enunciar. Se revisar quatro saídas custasse o mesmo tempo que revisar uma, o gargalo estaria mesmo na execução, e disparar tudo de uma vez seria sempre a escolha certa. Não é o que eu vejo enquanto leio diff contra intenção, um de cada vez.