Equipes de Agentes Especializados: O Que o Padrão AntFarm Acerta — e o Que Esconde

Vinci Rufus publicou esta semana um artigo detalhando o AntFarm, um padrão de orquestração multi-agente para o que ele chama de “Compound Engineering”. A proposta é direta: em vez de um agente generalista que faz tudo, monte um time de agentes especializados — planejador, desenvolvedor, verificador, testador, revisor — cada um com contexto limpo e critérios explícitos de handoff.

A ideia não é nova. Mas a formulação é útil, e os dados que Rufus apresenta merecem análise. Assim como as limitações que ele mesmo reconhece — e as que ficam implícitas.

O Problema Real que AntFarm Endereça

Qualquer pessoa que trabalhou com agentes de IA em sessões longas conhece o fenômeno: o agente começa bem, produz código correto, segue padrões. Duas horas depois, ele esquece decisões que tomou no início da conversa. Reintroduz bugs que já havia corrigido. Ignora convenções que aplicou consistentemente nos primeiros trinta minutos.

Isso não é um bug do modelo. É uma consequência da arquitetura. LLMs operam com janelas de contexto finitas. À medida que a conversa cresce, informações anteriores perdem relevância no cálculo de atenção. O modelo não “esquece” no sentido humano — ele deixa de priorizar.

AntFarm resolve isso da forma mais simples possível: não tenta manter uma conversa longa. Cada agente opera em uma sessão limpa, recebendo apenas os artefatos relevantes do passo anterior. O planejador produz especificações. O desenvolvedor recebe as especificações e implementa. O verificador recebe a implementação e valida contra as especificações. Nenhum deles carrega o histórico completo da conversa.

É uma solução elegante para um problema real. Mas elegância não é suficiência.

Os Números que Importam — e os que Faltam

Rufus define quatro métricas de desempenho para o padrão:

Métrica	Meta
Tempo de ciclo por story	< 30 minutos
Sucesso na primeira tentativa	> 70%
Intervenção humana	< 20%
Taxa de escalação	< 5%

São metas sensatas. Mas observe o que elas revelam por omissão.

Uma taxa de sucesso de 70% na primeira tentativa significa que 30% das stories falham e precisam de retry ou intervenção. Uma taxa de intervenção humana de 20% significa que um em cada cinco ciclos exige um engenheiro. Em um time que processa cinquenta stories por semana, isso são dez intervenções manuais — não insignificante.

A afirmação mais ousada é a projeção de 300% a 700% de ganho de produtividade. Rufus é transparente que esse número vem de sua própria experiência, não de estudos controlados. Isso é honesto, mas precisa ser contextualizado.

A Harvard Data Science Review reporta um potencial de 2x a 10x de produtividade com IA baseada em agentes — um intervalo tão amplo que é quase uma admissão de incerteza. Um levantamento da GitHub mostrou que 93% dos líderes de engenharia esperam ganhos de produtividade com IA, mas apenas 3% reportam impacto transformacional até agora. O estudo de Stanford liderado por Yegor Denisov-Blanch encontrou ganhos de 30% a 40% em tarefas simples de greenfield, com resultados próximos de zero — ou negativos em manutenibilidade — para codebases maduros.

Nenhum desses dados invalida o AntFarm. Mas colocam as projeções de 700% em perspectiva. A distância entre o potencial teórico e o resultado verificado ainda é grande.

O Que a Especialização Realmente Resolve

A contribuição mais substancial do padrão não é velocidade — é integridade.

Quando um único agente planeja, implementa e revisa seu próprio trabalho, existe um conflito de interesse estrutural. O mesmo modelo que cortou um caminho durante a implementação vai racionalizar essa decisão durante a revisão. Não por desonestidade — por consistência interna do modelo.

AntFarm quebra isso separando os papéis:

O verificador não sabe quais compromissos o desenvolvedor fez. Ele recebe a especificação original e a implementação, e valida uma contra a outra.
O testador existe exclusivamente para encontrar falhas. Não tem incentivo para confirmar que o código funciona.
O revisor aplica padrões de qualidade sem contexto sobre as dificuldades da implementação.

Isso espelha algo que engenharia de software já pratica: code review funciona porque o revisor não carrega o viés de quem escreveu o código. A separação de concerns não é apenas um princípio de arquitetura de software — é um princípio de design organizacional.

Nicholas Carlini demonstrou isso em escala quando coordenou 16 instâncias do Claude para construir um compilador C de 100.000 linhas. O maior esforço não foi nos prompts — foi na infraestrutura de coordenação: lock files, task claiming, testes de integração. O que Carlini construiu na prática foi uma versão artesanal do que AntFarm propõe como padrão.

O Que o AntFarm Não Resolve

Rufus é honesto sobre as limitações, e isso merece reconhecimento. Ele afirma explicitamente que o padrão funciona para “tarefas com estado final claro” e luta com “trabalho exploratório, decisões arquiteturais complexas, problemas novos fora da distribuição de treinamento”.

Essa é uma restrição significativa. Vamos decompô-la.

Trabalho exploratório é, por definição, trabalho onde o estado final é desconhecido. Você não sabe exatamente o que vai construir até começar a construir. Prototipagem, spike técnico, investigação de viabilidade — nada disso cabe em uma especificação que o planejador possa produzir de antemão.

Decisões arquiteturais exigem julgamento que cruza múltiplas dimensões simultâneas: performance, manutenibilidade, custo, prazo, capacidade do time, dívida técnica existente. Um agente planejador pode listar trade-offs. Mas a ponderação entre eles requer contexto organizacional que nenhuma sessão limpa de agente possui.

Problemas fora da distribuição são, por natureza, o tipo de trabalho que mais agrega valor. Se o problema já tem solução conhecida, a automação é relativamente simples. O trabalho difícil — e valioso — está nos problemas que ninguém resolveu antes.

A regra prática de Rufus é instrutiva: “Se você consegue descrever o estado final em uma frase clara, AntFarm provavelmente pode construí-lo.” Mas inverta a lógica: se o trabalho mais valioso da sua equipe é justamente aquele cujo estado final não cabe em uma frase, qual percentual do seu pipeline o AntFarm realmente cobre?

A Camada Invisível: Governança

Aqui está o que a formulação do AntFarm deixa implícito mas não endereça: quem governa o time de agentes?

O padrão define papéis e fluxos. O planejador produz especificações, o desenvolvedor implementa, o verificador valida. Mas pergunte:

Quem decide se a especificação do planejador é adequada? O padrão assume que o planejador produz especificações corretas. Mas planejamento é a etapa que mais exige contexto de negócio — exatamente o tipo de contexto que agentes em sessões limpas não possuem.
Quem resolve conflitos entre agentes? Se o verificador rejeita a implementação e o desenvolvedor rejeita a objeção no retry, quem arbitra?
Quem audita o fluxo? Ciclos de retry silenciosos podem mascarar problemas sistêmicos. Sem observabilidade sobre o padrão de falhas, o time otimiza cegamente.
Quem atualiza os critérios? As instruções de cada agente são estáticas. Mas padrões de código evoluem, requisitos mudam, lições são aprendidas. Quem propaga essas mudanças?

Operamos nosso próprio sistema multi-agente na Victorino Group — com agentes especializados para diferentes funções, cada um com instruções explícitas e critérios de handoff. A experiência nos ensinou que montar o time é a parte fácil. A parte difícil é a governança: garantir que os agentes operem dentro de limites definidos, que falhas sejam detectadas antes de se propagarem, que o sistema evolua com o contexto organizacional.

O Ralph Loop, padrão documentado por Geoffrey Huntley em meados de 2025, ilustra o mesmo princípio por um ângulo diferente: um loop bash que cria instâncias frescas de agentes com o filesystem como memória. A ideia central é idêntica ao AntFarm — sessões limpas, artefatos como handoff. Mas Huntley enfatiza algo que Rufus menciona de passagem: o filesystem se torna a camada de governança. O que está escrito é o que vale. O que não está escrito não existe.

Essa é a lição. A orquestração sem governança é automação frágil. Funciona até não funcionar, e quando falha, falha de formas difíceis de diagnosticar.

Compound Engineering: A Promessa e a Condição

Rufus cunhou o termo “Compound Engineering” em janeiro de 2026 para descrever a ideia de que cada tarefa completada por agentes facilita a próxima — via acúmulo de conhecimento codificado, padrões validados e artefatos reutilizáveis.

O conceito é atraente. E contém uma verdade importante: agentes que operam sobre uma base de código bem estruturada, com testes sólidos e padrões documentados, produzem resultados melhores do que agentes operando sobre código legado desorganizado. Isso é consistente com o estudo de Stanford que mostra correlação entre qualidade do codebase e ganhos de produtividade com IA.

Mas a premissa de acúmulo composto tem uma condição que muitas vezes fica implícita: o acúmulo só funciona se a qualidade dos artefatos produzidos é consistentemente alta. Se agentes introduzem dívida técnica — e a evidência sugere que isso acontece, especialmente em codebases maduros — o efeito composto pode ser negativo. Cada artefato de qualidade inferior torna o próximo mais difícil.

Compound Engineering não é inevitável. É condicional. E a condição é governança.

O Que Levar Daqui

AntFarm é uma formulação útil de um padrão que a indústria está convergindo organicamente. Times de agentes especializados com handoffs explícitos funcionam melhor que agentes generalistas em sessões longas. Isso é empiricamente verificável e conceitualmente sólido.

Mas três distinções importam para quem está avaliando a adoção:

Primeiro: especialização de agentes é uma técnica. Governança de agentes é uma disciplina. O AntFarm endereça a primeira. A segunda é o que determina se o sistema funciona em produção ou apenas em demonstrações.

Segundo: as projeções de produtividade precisam ser calibradas com dados independentes. A distância entre 3% de organizações reportando impacto transformacional e projeções de 700% de ganho não é um argumento contra a abordagem — é um argumento para rigor na medição.

Terceiro: o limiar de aplicabilidade é mais restritivo do que parece. “Tarefas com estado final claro” exclui uma parcela significativa do trabalho de engenharia que mais agrega valor. Saber onde o padrão se aplica é tão importante quanto saber como implementá-lo.

A especialização é o começo. A governança é o trabalho.

Para discutir como implementar times de agentes especializados com a camada de governança adequada para sua organização, entre em contato: contato@victorino.com.br | www.victorino.com.br