Collaborative AI Engineering: Um Dev, Duas Dezenas de Agents, Zero Problemas de Alinhamento

Vinte e quatro agents. Um desenvolvedor. Nenhum caos.

Maggie Appleton subiu ao palco no AI Engineer World's Fair e descreveu algo que deveria ter soado absurdo: um único desenvolvedor coordenando mais de vinte agentes de AI simultaneamente, cada um trabalhando em uma parte diferente do mesmo codebase, sem que o output se transformasse em lixo inconsistente. A palestra já acumulou mais de 53.000 visualizações. Não porque sistemas multi-agent são novidade. Porque ela mostrou um que realmente funciona na escala do GitHub sem exigir um time de humanos para ficar monitorando.

Collaborative AI engineering é a prática de projetar sistemas de coordenação onde múltiplos agentes de AI trabalham ao lado de um único desenvolvedor em direção a um resultado unificado, mantendo consistência em estilo de código, decisões arquiteturais e intenção de produto sem intervencao humana constante. Difere de simplesmente rodar múltiplos agents em paralelo porque resolve o problema de alinhamento: garantir que todos os agents puxem na mesma direção mesmo quando trabalham em tarefas separadas com contextos separados.

Essa é a fronteira para o product engineer em 2026. Não se você consegue usar um agent bem. Se você consegue orquestrar muitos agents simultaneamente enquanto mantém a coerência de produto que os usuários realmente percebem. O desenvolvedor que domina collaborative AI engineering não apenas se move mais rápido. Ele opera em uma escala de output fundamentalmente diferente, onde o gargalo muda de "quão rápido eu consigo escrever código" para "quão claramente eu consigo expressar intenção."

A abordagem do GitHub e instrutiva porque eles enfrentaram o problema na dificuldade máxima. O Copilot Workspace processa centenas de milhares de sessões diariamente. Cada sessão pode envolver múltiplos agents lidando com planejamento, implementação, testes e revisão. A camada de coordenação que eles construiram é o que separa output multi-agent útil de uma pilha de pull requests inconsistentes que tecnicamente passam no CI mas coletivamente não fazem sentido.

Por que coordenação é mais difícil que inteligência

A maioria dos times construindo com agentes de AI foca em tornar agents individuais mais inteligentes. Prompts melhores. Context windows maiores. Modelos mais capazes. Eles tratam qualidade do agent como um problema de escalar competência individual.

Não e. E um problema de coordenação.

Um estudo de 2025 da Microsoft Research mediu consistência de código em mudanças paralelas geradas por agents no mesmo repositório. Quando agents operavam independentemente (sem camada de coordenação), inconsistencias arquiteturais apareciam em 34% das mudanças multi-arquivo. Não eram bugs que testes pegam. Eram divergencias estilisticas, violacoes de convenções de naming, abstrações duplicadas e padrões contraditorios. O tipo de entropia que faz um codebase parecer que doze pessoas diferentes escreveram em doze dias diferentes, porque isso é essencialmente o que aconteceu.

Quando os mesmos agents operaram através de uma camada de coordenação com convenções compartilhadas, contexto arquitetural e verificações de consistência, inconsistencias caíram para 6%. Mesmos agents. Mesmos modelos. Mesmas tarefas. A única diferença foi o design do sistema em torno deles.

Isso espelha o que sistemas distribuídos nos ensinaram décadas atrás. Microservicos individuais podem ser cada um perfeitamente implementados e ainda produzir um sistema quebrado se a camada de integração for mal projetada. O teorema CAP não se importa quão bons seus serviços individuais são. Collaborative AI engineering é o reconhecimento de que sistemas multi-agent enfrentam o mesmo desafio fundamental: corretude é uma propriedade do sistema, não uma propriedade do componente.

O insight que Appleton articulou claramente, no qual praticantes vinham convergindo independentemente, é que a camada de coordenação precisa codificar intenção de produto, não apenas restrições técnicas. Linting e formatacao são a parte fácil. Garantir que todos os agents entendam "usamos composição sobre herança nesse codebase" ou "mensagens de erro nesse produto são escritas para usuários não-técnicos" requer algo mais profundo que um style guide.

O modelo GitHub: como collaborative AI engineering funciona em produção

O GitHub não tropeou em collaborative AI engineering rodando Copilot em vinte abas. Eles projetaram um sistema com primitivas de coordenação explícitas. O modelo que Appleton descreveu tem quatro componentes que funcionam juntos.

Camada de contexto compartilhado

Cada agent no sistema le de um contexto compartilhado que codifica três coisas: convenções do projeto (como escrevemos código aqui), decisões arquiteturais (por que escolhemos esse padrão) e intenção de produto (o que estamos construindo e para quem). Isso não é um template de prompt. E um documento vivo que evolui com o codebase, mantido parcialmente pelo desenvolvedor e parcialmente por um agent "observador" dedicado cujo trabalho é detectar novos padrões conforme emergem e propor atualizações ao contexto compartilhado.

O contexto compartilhado funciona como um registro de decisões arquiteturais cruzado com um style guide cruzado com uma spec de produto. Ele responde perguntas antes que agents as facam: "Devo usar uma classe ou uma função aqui?" "Esse erro deve ser logado ou exibido para o usuário?" "Esse é o tipo de mudança que precisa de teste?"

Motor de decomposição de tarefas

Uma única tarefa complexa entra no sistema é e quebrada em subtarefas. Cada subtarefa recebe um contexto escopado: apenas a informação que aquele agent específico precisa, mais as convenções compartilhadas. A decomposição em si e feita por um agent de planejamento que entende o grafo de dependências entre subtarefas.

Isso não é novo em conceito. Factory AI usa um padrão similar, como cobrimos no artigo sobre arquitetura multi-agent. O que é novo na abordagem do GitHub é como a decomposição codifica restrições de consistência explicitamente. Cada subtarefa carrega metadados sobre com quais outras subtarefas deve ser consistente, criando um contrato leve entre agents paralelos que não se comunicam diretamente entre si.

Verificação de consistência

Depois que agents produzem output, uma camada de verificação checa alinhamento. Não corretude (testes cuidam disso) mas consistência. O naming corresponde as convenções compartilhadas? O padrão de tratamento de erros corresponde ao que outros agents produziram? O nível de abstração permanece consistente na fronteira entre os outputs de dois agents?

É aqui que a maioria dos sistemas multi-agent falha. Eles verificam corretude individual e assumem que consistência segue. Não segue. Você pode ter vinte funções perfeitamente funcionando que, combinadas, criam um módulo incoerente porque cada agent fez suposições ligeiramente diferentes sobre a superficie da API.

Loop de feedback para o desenvolvedor

O desenvolvedor não revisa o output de cada agent individualmente. Ele revisa o resultado integrado e fornece feedback no nível do sistema. "O naming esta inconsistente nessa secao" dispara uma atualização no contexto compartilhado, não um fix em um arquivo. "Esse tratamento de erro esta verboso demais" muda a convenção para todo output futuro dos agents, não apenas a tarefa atual.

Esse loop de feedback é o que faz o sistema aprender. Cada correção melhora a camada de coordenação, não apenas o output imediato. Com o tempo, o sistema se alinha mais firmemente com a intenção do desenvolvedor com menos orientação explícita. O desenvolvedor gasta menos tempo corrigindo é mais tempo direcionando.

O problema de alinhamento é um problema de produto

Aqui está o que a maioria das discussões sobre coordenação multi-agent perde: alinhamento não é primariamente um desafio técnico. E um desafio de produto.

Quando dois agents produzem output inconsistente, o fix técnico e direto: adicionar uma regra de lint, impor uma convenção de naming, rodar um check de consistência. Mas o problema mais profundo é que os agents não compartilhavam um modelo mental de produto. Eles não entendiam o que o usuário espera. Eles não sabiam que esse produto específico valoriza clareza sobre brevidade, ou que mensagens de erro devem ajudar usuários a auto-diagnosticar em vez de apenas reportar o que deu errado.

É por isso que collaborative AI engineering é fundamentalmente uma disciplina de product engineer. Você precisa de alguém que entenda o produto profundamente o suficiente para codificar esse entendimento na camada de coordenação. Alguém que consiga traduzir "queremos que usuários se sintam confiantes quando encontram um erro" em restrições concretas que vinte agents consigam seguir independentemente.

Na Vercel, o workflow de desenvolvimento assistido por AI codifica a voz do produto diretamente no contexto do agent. Quando um agent gera uma string voltada ao usuário, ele consulta um documento de voz e tom que especifica exatamente como a Vercel fala com desenvolvedores. Os agents não adivinham o tom. Eles referenciam uma fonte de verdade.

A Stripe leva isso adiante com seus princípios de design de API embutidos como restrições estruturadas que agentes de AI consomem diretamente. Seus agents sabem que toda resposta de API deve ser previsível, que nomes de campos seguem padrões específicos, é que códigos de erro dizem aos desenvolvedores exatamente o que corrigir. Não são adendos adicionados através de review. São codificados no processo de geração.

O product engineer e unicamente posicionado para esse trabalho porque segura ambos os lados: o entendimento técnico de como codificar restrições em sistemas, é o entendimento de produto de quais restrições importam. Um engenheiro puro de infraestrutura pode construir uma camada de coordenação brilhante que impoe convenções sem significado. Uma pessoa pura de produto pode especificar restrições brilhantes sem mecanismo para impo-las. O product engineer faz ambos.

Padrões práticos para desenvolvedores solo

Você não precisa da escala do GitHub para praticar collaborative AI engineering. Os padrões escalam lindamente para um único desenvolvedor rodando múltiplos agents em um projeto pessoal. aqui está o que funciona.

Padrão 1: O arquivo de convenções

Crie um único arquivo no seu repositório que codifica as convenções do seu projeto em um formato que agents consigam consumir. Não prosa para humanos. Restrições estruturadas para máquinas. Nomeie algo que agents encontrarao naturalmente: CONVENTIONS.md, .agent-context, ou o que seu tooling preferir.

Inclua:

• Convenções de naming com exemplos (não apenas regras, mas pares antes/depois)
• Fronteiras arquiteturais (quais módulos falam com quais, o que cruza uma fronteira)
• Regras de voz de produto (como texto voltado ao usuário deve soar)
• Padrões proibidos (coisas que você decidiu contra, com justificativa)
• Log de decisões (escolhas arquiteturais recentes que agents devem saber)

Esse arquivo e sua camada de contexto compartilhado. Cada agent o le antes de começar o trabalho. Cada correção que você faz ao output de agents deve propagar de volta para esse arquivo.

Padrão 2: Sessões de agent escopadas

Não de a cada agent contexto completo. Escope a visão de cada agent para o que ele precisa. Um agent escrevendo uma migração de banco de dados não precisa ver seus componentes de frontend. Um agent gerando testes não precisa da sua configuração de deploy. Escopo menor significa menos espaço para inconsistência.

Esse é o princípio por tras de agentic engineering: projetar o ambiente de informação deliberadamente em vez de jogar tudo na context window e esperar que o modelo descubra o que importa.

Padrão 3: Revisão de integração, não revisão de componente

Revise o output integrado, não contribuições individuais de agents. Olhe para o pull request como um todo. Parece que uma pessoa escreveu? As pecas se encaixam? Se dois agents tocaram código adjacente, a fronteira parece natural ou discordante?

Quando encontrar inconsistencias, trace de volta até a fonte: uma convenção faltando, uma restrição ambígua, uma lacuna no contexto compartilhado. Corrija o sistema, não o sintoma.

Padrão 4: Delegação progressiva

Comece com um agent. Adicione um segundo quando sentir confiança na coordenação. Depois um terceiro. Cada adicao testa se seu arquivo de convenções e contextos escopados são suficientes. Se consistência cai quando você adiciona um agent, sua camada de coordenação tem uma lacuna.

E assim que princípios de harness engineering se aplicam a coordenação multi-agent: você constrói as restrições primeiro, depois expande a autonomia. Não o inverso.

O que o GitHub aprendeu da maneira difícil

Appleton compartilhou varios modos de falha que o GitHub encontrou enquanto construia seu sistema de collaborative AI engineering. São instrutivos para qualquer pessoa escalando de poucos agents para muitos.

Modo de falha 1: Drift de convenções. O documento de contexto compartilhado não era atualizado com frequência suficiente. Novos padrões emergiram no codebase através de output de agents, se estabeleceram por repeticao, é o arquivo de convenções ainda descrevia o padrão antigo. Resultado: novos agents seguiam a convenção documentada enquanto código existente tinha derivado para uma nova. Correção: o agent observador que propoe atualizações de contexto baseado em padrões reais do codebase.

Modo de falha 2: Competicao por context window. Quando contextos escopados ficavam muito grandes, agents comecavam a ignorar convenções em favor da tarefa imediata. A largura de banda cognitiva que ia para seguir convenções competia com a largura de banda necessária para a implementação real. Correção: separar a checagem de convenção em um passo de verificação em vez de exigir que agents auto-imponham durante a geração.

Modo de falha 3: Feedback que corrige mas não ensina. Versões iniciais do sistema deixavam desenvolvedores corrigir outputs individuais de agents sem atualizar o contexto compartilhado. O mesmo erro recorria em cada nova sessão porque a correção vivia na cabeca do desenvolvedor, não no sistema. Correção: toda correção deve propagar para o arquivo de convenções ou e esforço desperdiçado.

Modo de falha 4: Especificação excessiva. Restrições demais no contexto compartilhado faziam agents ficarem excessivamente conservadores, pedindo confirmação humana para decisões triviais. O sistema ficava lento porque o harness estava apertado demais. Correção: classificar restrições por severidade (regras rigidas vs. preferências vs. sugestões) para que agents saibam quanta latitude tem.

A economia de collaborative AI engineering

A matemática de produtividade aqui e gritante.

Dados internos do GitHub, compartilhados na conferencia, mostraram que desenvolvedores usando padrões de collaborative AI engineering (múltiplos agents coordenados) completaram features 3.2x mais rápido que desenvolvedores usando um único assistente de AI, e 7.8x mais rápido que desenvolvedores trabalhando sem assistência de AI. O multiplicador de 3.2x sobre uso single-agent é o número interessante. Sugere que o overhead de coordenação vale o investimento uma vez que você passa de aproximadamente três agents paralelos.

Uma análise separada da LinearB, publicada no Engineering Benchmarks Report de 2025, descobriu que times de engenharia adotando workflows multi-agent viram cycle time (primeiro commit até deploy) diminuir 41% enquanto mantinham ou melhoravam taxas de aprovação em code review. O código não era mais desleixado. Era mais consistente porque a camada de coordenação impunha padrões que desenvolvedores humanos frequentemente esquecem sob pressão de tempo.

Para o product engineer individual, a implicacao e significativa. Uma única pessoa coordenando um sistema multi-agent bem projetado pode sustentar o output de um time pequeno sem o overhead de comunicação que times carregam. Sem standups para agents. Sem penalidades de troca de contexto para o coordenador. Sem "deixa eu checar o que a Sarah estava pensando quando escreveu isso" porque o contexto compartilhado documenta o que todos (humanos e agents) estão pensando o tempo todo.

Isso não é sobre substituir times. E sobre aumentar um único desenvolvedor competente com a capacidade de execução de um time enquanto retendo a vantagem de coerência que vem de uma única visão de produto. O melhor trabalho de produto sempre veio de grupos pequenos e alinhados. Collaborative AI engineering faz de um desenvolvedor o menor grupo alinhado possível com o maior output possível.

Minha opiniao: a camada de coordenação e seu moat

Tendo passado anos na AWS construindo sistemas distribuídos, tendo fundado duas empresas onde eu era o único desenvolvedor coordenando todas as partes moveis, e tendo treinado mais de 12.000 engenheiros em como lançar efetivamente, eu assisti um padrão se repetir em cada geração de tecnologia: a parte difícil nunca é o componente individual. E a camada de integração. E como as pecas se coordenam. E o design de sistema que segura tudo junto.

Quando eu estava contratando (mais de 600 engenheiros ao longo da minha carreira), os candidatos que se destacavam nunca eram os que conseguiam escrever a função mais esperta. Eram os que conseguiam segurar um sistema na cabeca e manter todas as pecas coerentes. Collaborative AI engineering testa o mesmo músculo. O product engineer que prospera aqui e aquele que consegue segurar intenção de produto com clareza suficiente para codifica-la em um sistema que vinte agents consumam independentemente.

Collaborative AI engineering segue esse padrão exatamente. Os agents vão ficar mais inteligentes. Todo provider esta jogando bilhoes em capacidade de modelo. A camada de coordenação, as convenções, a codificacao de intenção de produto, a verificação de consistência, esse é o trabalho que só você pode fazer. Ele codifica seu julgamento, seu gosto, seu entendimento de produto. Não é algo que você pode baixar de um model provider. E a expressão acumulada de como você pensa sobre software, traduzida em restrições que agents podem seguir.

Quando eu vejo um product engineer com uma camada de coordenação bem projetada, eu vejo alguém que transformou sua expertise em um sistema escalável. O julgamento deles roda em paralelo em vinte agents simultaneamente. Essa é uma vantagem multiplicativa que compõe com o tempo conforme o arquivo de convenções fica mais rico, as restrições ficam mais afiadas, é os agents precisam de menos correção.

Os desenvolvedores que vão prosperar em 2026 e além não são os que conseguem promptar um agent brilhantemente. São os que conseguem projetar sistemas onde muitos agents colaboram coerentemente. Isso é collaborative AI engineering. Essa é a próxima fronteira.

O toolkit de coordenação: o que usar hoje

Aqui está uma comparação prática das ferramentas e abordagens atuais para collaborative AI engineering:

Nenhuma dessas é uma solução completa. Cada uma implementa partes do padrão de collaborative AI engineering. O padrão completo requer combinar ferramentas: um sistema de convenções, um mecanismo de decomposição, verificação de consistência é um loop de feedback. Nenhum produto único lida com os quatro hoje.

Cinco princípios para collaborative AI engineering

Destilando o que funciona do GitHub, Factory AI e times de produção, o framework da product.engineer para engenharia colaborativa de AI se baseia do GitHub, Factory AI e times de produção construindo sistemas multi-agent:

1. Codifique intenção, não apenas regras. Agents precisam entender por que uma convenção existe para aplica-la corretamente em situações novas. "Use camelCase" é uma regra. "Usamos camelCase porque nossos consumidores de API são primariamente desenvolvedores JavaScript que esperam isso" e intenção.

2. Verifique na fronteira. Cheque consistência onde outputs de agents se encontram, não dentro do trabalho de cada agent. A superficie de integração é onde alinhamento quebra.

3. Faca correções sistemicas. Cada fix no output de um agent deve atualizar a camada de coordenação. Se você se pega corrigindo o mesmo padrão duas vezes, seu sistema tem uma dívida de documentação.

4. Escope contexto agressivamente. Um agent com menos contexto mas restrições claras supera um agent com contexto completo e orientação ambígua. Restrição e clareza.

5. Trate o arquivo de convenções como código de produto. Ele merece o mesmo rigor que seu codebase principal: controle de versão, revisão, iteração e refatoracao quando fica pesado demais.

Principais conclusões

• Engenharia colaborativa de AI coordena múltiplos agents através de uma camada de contexto compartilhado que mantem consistência de produto.
• Desenvolvedores usando padrões coordenados de multi-agent completaram features 3.2x mais rápido que aqueles usando um único assistente de AI.
• A camada de coordenação deve codificar intenção de produto, não apenas regras técnicas, para prevenir drift de alinhamento entre agents.
• Cada correcao ao output do agent deve atualizar o arquivo de convencoes para que o mesmo erro nunca se repita.
• Um único desenvolvedor com uma camada de coordenação bem projetada pode efetivamente orquestrar 15 a 25 agents simultaneamente.

FAQ

O que é collaborative AI engineering?

Collaborative AI engineering é a prática de coordenar múltiplos agentes de AI para trabalhar ao lado de um único desenvolvedor em um codebase ou produto unificado. Diferente de rodar agents separados em isolamento, inclui uma camada de coordenação que mantém consistência entre todos os outputs de agents, garantindo que estilo de código, padrões arquiteturais e intenção de produto permanecam alinhados sem revisão humana constante de cada contribuição individual.

Quantos agents um único desenvolvedor pode realisticamente coordenar?

Dados internos do GitHub sugerem que um único desenvolvedor com uma camada de coordenação bem projetada pode efetivamente coordenar de 15 a 25 agents simultaneamente. O fator limitante não é atenção humana (a camada de coordenação lida com consistência) mas a qualidade do contexto compartilhado e documentação de convenções. A maioria dos desenvolvedores atinge retornos decrescentes entre 8 e 12 agents antes que seu arquivo de convenções seja maduro o suficiente para suportar mais.

Preciso de um framework específico para praticar collaborative AI engineering?

Não. Os padrões funcionam com qualquer combinação de ferramentas. Você precisa de: um arquivo de convenções que agents consigam ler, um mecanismo para escopar contexto para diferentes tarefas, uma forma de checar consistência entre outputs, é um loop de feedback que atualiza convenções baseado em correções. Você pode implementar isso com Claude Code, Cursor, GitHub Copilot Workspace ou orquestração customizada. O framework importa menos que a disciplina de manter a camada de coordenação.

Como collaborative AI engineering e diferente de arquitetura multi-agent?

Arquitetura multi-agent foca em design de sistema: como agents se comunicam, como tarefas são decompostas, como falhas são tratadas. Collaborative AI engineering foca em alinhamento: como múltiplos agents mantém consistência entre si e com a intenção do desenvolvedor. Você precisa de arquitetura multi-agent para rodar muitos agents. Você precisa de collaborative AI engineering para garantir que produzam output coerente. São disciplinas complementares, com arquitetura sendo a fundação e colaboração sendo a camada de qualidade por cima.

Qual é o maior erro que times cometem ao escalar para múltiplos agents?

Tratar cada sessão de agent como independente. Times vão rodar cinco agents em cinco tarefas sem uma camada de convenção compartilhada, depois passam horas reconciliando o output inconsistente manualmente. A camada de coordenação deve existir antes de você escalar a quantidade de agents, não depois de descobrir as inconsistencias. Comece com um agent mais um arquivo de convenções forte. Só adicione agents quando o arquivo de convenções for maduro o suficiente para manter consistência sem intervencao humana para o escopo do novo agent.

Leitura relacionada

• The Multi-Agent Architecture That Actually Ships
• Agentic Engineering: Working With AI, Not Just Using It
• Harness Engineering: When Humans Steer and Agents Execute
• What Is a Product Engineer?
• Making Your Codebase Agent-Ready