Subi uma orquestração de cinco subagentes para refatorar um módulo de auth. Me custou $11, levou doze minutos e produziu um resultado pior do que simplesmente fazer em uma única thread. Subagentes são superestimados para builders solo, e as demos do Twitter mostrando enxames de agentes bonitos não estão te contando a parte em que fica caro e estranho.
Não me entenda errado. Subagentes são um recurso real com usos reais. Mas o conselho padrão — "quebre tudo em agentes especializados" — está errado para a pessoa construindo um produto sozinha. Na maioria das vezes você quer um agente flat, de thread única, que simplesmente faz o trabalho. Deixa eu explicar por quê.
O que um subagente realmente custa
Quando você spina um subagente, você não está apenas delegando uma tarefa. Você está spinando um contexto novo que não sabe nada sobre sua thread principal. Então você tem que briefá-lo. Todo subagente precisa dos arquivos relevantes, das convenções, do objetivo, reexplicados do zero. Esse briefing são tokens. O trabalho do subagente são tokens. Então ele reporta de volta, e sintetizar seu relatório na thread principal são mais tokens.
Para uma tarefa paralela com fronteiras limpas, esse overhead vale a pena. Para uma tarefa onde as peças estão entrelaçadas — o que descreve a maioria do código real — você paga o imposto do briefing repetidamente, e os subagentes continuam pisando nos pés uns dos outros porque nenhum deles consegue ver o quadro completo.
A versão de thread única simplesmente... já tem o contexto. Ela leu os arquivos uma vez. Ela se lembra do que fez três passos atrás. Sem briefing, sem síntese, sem overhead de coordenação. Frequentemente é tanto mais barata quanto melhor.
O problema da fragmentação de contexto
Aqui está o sutil. O motivo pelo qual agentes são bons em codificar é o contexto compartilhado — o modelo mantém o problema, os arquivos e suas próprias decisões anteriores em um lugar e raciocina sobre tudo isso. Subagentes destroem isso. Cada um vê uma fatia.
Então o subagente A corrige o tratamento de erros à sua maneira. O subagente B, briefado separadamente, corrige a validação de uma maneira diferente. Nenhum sabe o que o outro fez. Você, na thread principal, agora tem que reconciliar duas mudanças localmente razoáveis que não se encaixam. Já gastei mais tempo reconciliando saídas de subagentes do que os subagentes economizaram. Essa é a armadilha.
Para um builder solo, sua vantagem é que você mantém o quadro completo na sua cabeça e o agente o mantém no contexto. Fragmentar isso para parecer uma equipe é fantasiar de ser uma organização que você não tem.
Quando subagentes realmente compensam
Não estou dizendo nunca. Aqui está onde eu realmente os uso:
- Trabalho verdadeiramente paralelo e independente. "Rode a suite de testes enquanto você também faz lint no código." Sem estado compartilhado, sem reconciliação. Fan-out limpo.
- Isolamento de contexto intencional. Quando uma subtarefa inundaria meu contexto principal com lixo que não quero poluindo a thread principal — como ler 40 arquivos para responder uma pergunta. O subagente lê os 40, retorna a única resposta, meu contexto principal fica limpo. Esse é um ótimo uso.
- Pesquisa delimitada. "Vá descobrir como funciona a auth dessa biblioteca e reporte de volta." A exploração é bagunçada; eu só quero a conclusão.
Note o padrão: subagentes ganham seu lugar quando a subtarefa é independente e resumível. Quando o valor está em manter a bagunça fora da thread principal, não em fingir ser uma equipe.
A fantasia da orquestração
Existe um gênero de conteúdo que vende o sonho multi-agente — um agente planejador, um agente codificador, um agente revisor, um agente testador, todos coordenando como uma pequena empresa. Parece incrível num diagrama. Para um builder solo é principalmente uma forma de transformar uma tarefa de $0,50 em uma de $6.
O planejador re-explica a tarefa ao codificador. O codificador produz trabalho. O revisor, com seu próprio contexto novo, relê tudo para revisá-lo. O testador relê novamente. Cada handoff reprocessa o mesmo código. Você recriou a ineficiência de uma grande equipe — todo o overhead de comunicação — sem o benefício, porque ainda é só você e o modelo.
Um agente capaz em uma única thread planeja, codifica e se auto-verifica enquanto mantém tudo no contexto. Você lê o diff no final. Esse é o seu revisor. Você é o organograma.
Minha regra
Default para flat. Uma thread, um agente, contexto completo. Uso um subagente apenas quando consigo responder sim a: essa subtarefa é independente, e quero apenas o resumo de volta?
# A pergunta que faço antes de spintar:
# - Independente do trabalho principal? (sem estado compartilhado para reconciliar)
# - Resumível? (quero uma conclusão, não saída bruta)
# Ambos sim -> subagente. Caso contrário -> mantém flat.
Todo o resto fica na thread principal, onde o contexto é inteiro e a conta é pequena.
O enxame de agentes parece o futuro. Para uma pessoa entregando um produto, geralmente é uma fantasia. Tire a fantasia e simplesmente faça o trabalho em uma thread. Seu orçamento de tokens vai agradecer, e o código também.