Um Desenvolvedor, Duas Dúzias de Agentes, Zero Alinhamento

Um desenvolvedor. Duas dúzias de agentes. Zero alinhamento.

Não é uma piada sobre escala. É o diagnóstico de Maggie Appleton para a fase em que entramos, e vale a pena levá-lo a sério antes que o próximo ciclo de contratação de agentes torne a situação irreversível.

Por dois anos, a indústria tratou produtividade individual como o problema a resolver. Mais tokens, mais contexto, mais paralelismo. O argumento era simples: se cada desenvolvedor consegue rodar vinte agentes em paralelo, a empresa entrega vinte vezes mais. A aritmética é sedutora. E está errada.

O gargalo mudou de lugar

A observação de Appleton é que escalar indivíduos com agentes de IA não resolve o verdadeiro gargalo do software. Ele apenas o desloca. Antes, o custo estava em escrever código. Hoje, o custo está em decidir o que construir, para quem, com quais prioridades, contra quais restrições. Essa decisão nunca foi um problema individual. É, e sempre foi, um problema de time.

A evidência do que acontece quando o gargalo se desloca está espalhada pelos relatos recentes. A Flatiron descreveu um padrão que já não é exceção: um product manager cobrindo cinco empresas, engenheiros assumindo decisões de produto, gerentes de conta construindo agentes de Slack, times de contabilidade escrevendo queries de banco de dados em linguagem natural. Claude Code substituiu Cursor na maioria dos shops. Velocidade individual aumentou. Coerência de time não.

É fácil olhar para isso e ver eficiência. Olhe de novo. O que você está vendo é um time onde cada pessoa, e cada agente dessa pessoa, está otimizando para um mapa diferente. Não há mapa compartilhado. Há vinte mapas, todos plausíveis, todos parcialmente corretos, nenhum reconciliado.

Como exploramos ao analisar dezenas de milhões de sessões de agentes, desalinhamento entre agentes é um problema real mas tratável. Desalinhamento entre o time e seus agentes é outra coisa. É o tipo de falha silenciosa que não aparece em nenhum dashboard porque cada parte do sistema está funcionando conforme projetada. O que falha é a composição.

Por que alinhamento é um problema de governança

Quando um engenheiro solitário roda um agente, o alinhamento acontece dentro da cabeça dele. Ele sabe o que quer, corrige o agente em tempo real, descarta o que não serve. O loop é curto e privado.

Quando um time de oito pessoas roda duzentos agentes, esse loop não existe mais. Cada decisão passa a depender de três perguntas que antes ficavam implícitas:

Primeiro, qual é o contexto compartilhado? O que o time concorda que é verdade agora, sobre o produto, sobre os clientes, sobre a arquitetura, sobre o que já foi tentado e falhou? Sem resposta a essa pergunta, cada agente reinventa premissas que alguém já derrubou semana passada.

Segundo, qual é a prioridade compartilhada? No que os agentes devem trabalhar, e quem decide quando dois deles querem tocar o mesmo arquivo com intenções incompatíveis? O PMO tradicional sumiu. O que toma seu lugar não é ausência de governança. É um log de decisões distribuído, que ou existe ou não existe.

Terceiro, qual é a verificação compartilhada? Quando três agentes chegam a três respostas diferentes, quem julga? Com base em quê? Com qual memória? Essa pergunta é o coração do problema, e é a primeira a ser esquecida na euforia do paralelismo.

Essas três perguntas são de governança, fantasiadas de perguntas sobre produtividade. Tratá-las como produtividade leva a soluções sobre tokens e filas. Tratá-las como governança leva a soluções sobre superfícies de coordenação.

Um padrão concreto: os três canais da Slack

Se você quer um exemplo de como isso parece na prática, o time de engenharia da Slack publicou algo que merece atenção. Para gerenciar aplicações agênticas de execução longa, eles criaram uma arquitetura de três canais complementares de contexto.

O primeiro é o Director’s Journal, um registro estruturado do que o sistema decidiu e por quê. É memória, mas memória opinativa: não guarda tudo, guarda o que importa para decisões futuras. O segundo é o Critic’s Review, um canal que revisa e poda descobertas imprecisas antes que elas contaminem o raciocínio downstream. O terceiro é o Critic’s Timeline, a cronologia dos eventos, a base factual contra a qual as outras duas camadas são checadas.

Traduzindo para a linguagem que importa: memória compartilhada, correção compartilhada, fatos compartilhados. É quase uma paráfrase das três perguntas de governança acima, implementada em canais de Slack em vez de cerimônias de Scrum.

O ponto não é que todo time deva copiar a Slack. O ponto é que o time da Slack reconheceu que alinhamento precisa de superfície. Precisa de um lugar onde o contexto mora, um lugar onde ele é questionado, um lugar onde ele é datado. Sem essas superfícies, o que chamamos de governança é apenas um post-it na geladeira.

O que Appleton acerta, e o que ela deixa de fora

Appleton é designer, não operadora. A crítica justa ao texto dela é que o argumento é afiado mas ralo em evidência empírica. Aceito a crítica. E mesmo assim o diagnóstico se sustenta, porque ele não depende de medições: depende de uma assimetria estrutural que qualquer pessoa que já tentou coordenar um time com agentes reconhece no primeiro dia.

A parte que ela deixa de fora é o caminho de saída. E aqui vale olhar para a tese de que velocidade de aprendizado virou o moat organizacional. Se a vantagem competitiva não é mais a velocidade individual dos agentes, então ela é a rapidez com que o time aprende a alinhar-se em volta deles. Times que constroem essas superfícies de alinhamento cedo vão compor. Times que tratam alinhamento como custo ou como cerimônia vão ver cada agente adicional deteriorar a coerência, não melhorá-la.

A conta a pagar

O próximo ano vai separar dois tipos de empresa. O primeiro tipo vai medir sucesso em throughput individual: PRs por dia, linhas por agente, tempo de ciclo. Vai parecer que está ganhando por alguns trimestres. Depois vai descobrir que construiu um time de vinte mapas e nenhum território.

O segundo tipo vai tratar alinhamento como artefato de primeira classe. Vai investir em contexto compartilhado, prioridade compartilhada, verificação compartilhada, com a mesma seriedade com que investiu em CI nos anos 2010. Não porque é elegante. Porque é a única forma de impedir que a velocidade dos agentes vire atrito do time.

O moat não é rodar mais agentes. É ter um time que sabe, a qualquer momento, o que os agentes dele concordaram em acreditar. Essa é a parte difícil. Sempre foi.

Fontes

Maggie Appleton. “One Developer, Two Dozen Agents, Zero Alignment.” Abril 2026.
Flatiron. “The AI-Pilled Compounding Startup.” Abril 2026.
Slack Engineering. “Managing Context in Long-Run Agentic Applications.” Abril 2026.
Robonomics. “Org Design in the Age of AI.” Abril 2026.

Ajudamos times a governar a camada de alinhamento antes que a velocidade dos agentes vire atrito do time: contato@victorino.com.br | www.victorino.com.br