Seu sistema de IA vai copiar o organograma, e o conjunto de avaliação mostra a cópia

Em 2008, Nachiappan Nagappan, Brendan Murphy e Victor Basili publicaram um estudo sobre o Windows Vista que cobria 3.404 binários e mais de 50 milhões de linhas de código. Eles tentaram prever quais binários falhariam depois do lançamento. Um modelo montado com oito medidas organizacionais identificou os binários propensos a falha com 86,2% de precisão e 84,0% de revocação. As medidas incluíam quantos engenheiros haviam editado um binário, quantos deles já tinham saído da empresa e a que profundidade da hierarquia ficava o gerente cuja organização fazia mais de três quartos das edições. O churn de código chegou a 78,6% e 79,9%, e a complexidade do código a 79,3% e 66,0%. Dependências (74,4% e 69,9%), cobertura de testes (83,8% e 54,4%) e contagem de bugs encontrados antes do lançamento (73,8% e 62,9%) ficaram ainda mais abaixo. Para esse sistema, o organograma dizia mais sobre onde o produto ia quebrar do que qualquer um dos modelos baseados em código.

Melvin Conway havia afirmado em 1968 que os sistemas acabam com a forma da estrutura de comunicação do grupo que os constrói, e o resultado do Vista é uma medição em grande escala nessa direção. Meu argumento é que produtos de IA herdam essa estrutura com pelo menos o mesmo rigor do software convencional, e provavelmente com mais, porque trazem artefatos que ninguém precisava ter como responsável antes: um conjunto de avaliação, um índice de recuperação, um prompt, uma versão de modelo fixada. Esses artefatos ficam nas fronteiras entre os times que a maioria das empresas cria primeiro, que são um time de dados, um de plataforma de ML e um de produto. O conjunto de avaliação é o único artefato capaz de dizer se as partes funcionam juntas, e na divisão habitual ele não pertence a ninguém.

Autores da ThoughtWorks deram nome ao remédio, a manobra inversa de Conway: decida as fronteiras de sistema que você quer e depois molde os times para que correspondam a elas. Para produtos de IA, eu poria o conjunto de avaliação dentro de um time de produto alinhado ao fluxo de valor, operaria a plataforma como serviço, com caminhos pavimentados, e manteria os especialistas escassos num grupo pequeno de habilitação. Quanto disso é evidência e quanto é heurística ganha uma seção própria mais abaixo, porque a topologia é mais popular do que testada.

A evidência mostra o espelhamento como um forte padrão, mas não como uma lei

O artigo de Conway, "How Do Committees Invent?", saiu na Datamation em abril de 1968. Sua frase mais conhecida diz que organizações que projetam sistemas ficam obrigadas a produzir projetos que são "cópias das estruturas de comunicação" dessas organizações. O raciocínio por trás dela é mais específico que o slogan. Um projeto grande é dividido em subsistemas, cada subsistema vai para um grupo, e cada interface entre subsistemas vira uma negociação entre grupos. Conway acrescentou que organizar uma equipe de projeto já é um ato de projeto, já que a primeira divisão do trabalho fixa escolhas antes de alguém ter estudado o problema. Ele observou também que o número de caminhos de comunicação possíveis é aproximadamente metade do quadrado do número de pessoas, e por isso as organizações restringem quem fala com quem. Seus exemplos iam além do software e incluíam governos, entre outros.

Três conjuntos de pesquisa testam a afirmação, cada um de um jeito. O primeiro é de Alan MacCormack, Carliss Baldwin e John Rusnak, que compararam cinco pares de produtos de software com a mesma função: um de uma empresa comercial, com pessoas fortemente acopladas em metas e estrutura, e outro de uma comunidade de código aberto, com pessoas fracamente acopladas. Em todos os pares examinados, o produto de código aberto era mais modular, e a diferença chegou a um fator de oito na distância que uma mudança num componente podia percorrer até outros. A comparação é observacional e pequena. Empresas comerciais e projetos de código aberto diferem em muito além da estrutura de comunicação, os próprios autores chamam cinco pares de amostra limitada, e os pares não foram desenvolvidos na mesma época, então parte da diferença pode ser aprendizado entre as datas de lançamento. Um dos produtos de código aberto, a planilha Gnumeric, tinha um custo de propagação bem maior que o dos demais. Os autores olharam o registro de contribuições e viram que uma só pessoa respondia por quase 40% das alterações registradas, o que interpretaram como uma organização fortemente acoplada, de modo que a exceção se encaixa na hipótese deles. É uma explicação posterior ao fato, oferecida depois de ver a anomalia.

O segundo é o estudo do Vista, que abre este texto. Ele é incomumente grande, e seus autores apontam os próprios limites: todos os dados vêm de um único sistema, os resultados não podem ser tomados como válidos além do Windows, e a correlação, por si só, nada diz sobre se uma reorganização teria evitado alguma falha. Notam ainda que os engenheiros do Windows não sabiam do estudo, então ninguém ajustava o comportamento para ficar bem nas medidas.

O terceiro e mais amplo é a revisão de Lyra Colfer e Carliss Baldwin (2016) sobre 142 estudos empíricos. Elas concluem que o espelhamento é um padrão comum e está longe de ser universal. Os estudos de projetos colaborativos abertos, em sua maioria de software, na maior parte não o confirmaram, e as autoras argumentam que as ferramentas digitais habilitam modos de coordenação que permitem aos grupos se afastar do padrão clássico. Em indústrias tecnologicamente dinâmicas, sugerem que o espelhamento parcial, com fronteiras de conhecimento traçadas de forma mais ampla que as operacionais, talvez seja a melhor estratégia. A leitura que considero defensável é que a estrutura organizacional exerce uma atração forte, por padrão, sobre a estrutura do sistema. Quem planeja precisa levá-la em conta, e escolhas deliberadas ainda podem desviá-la.

A divisão habitual de IA põe as fronteiras onde as falhas acontecem

Um jeito comum de montar o primeiro produto sério de IA é este. Um time de engenharia de dados cuida dos pipelines e do índice, o de plataforma de ML cuida do acesso a modelos, do treinamento e da inferência, e o de produto cuida da aplicação e dos prompts. A avaliação mora no notebook de um cientista de dados, num grupo de QA ou num exercício anual de red team. Cada time consegue reportar verde nas suas próprias medidas.

A pesquisa sobre aprendizado de máquina em organizações de software sugere por que essa divisão é mais arriscada que a mesma divisão para serviços convencionais. Saleema Amershi e colegas, da Microsoft, entrevistaram 14 profissionais e pesquisaram 551 engenheiros de software (taxa de resposta de 13,6%). Eles observam que, na arquitetura convencional, módulos separados costumam ir para times separados, com APIs definindo a interface, de modo que pouca comunicação é necessária. Para componentes aprendidos por máquina, relatam, fronteiras estritas de módulo são difíceis de manter, por dois motivos. Os modelos não são fáceis de estender ou recombinar, e interagem de maneiras pouco óbvias, então, mesmo que times diferentes tenham construído cada modelo, eles precisariam colaborar de perto para treinar e manter o sistema completo. As práticas recomendadas por vários engenheiros da amostra apontam na mesma direção: versionar o código de ML e o código comum nos mesmos repositórios e acoplar firmemente as sprints e as dailies de ML e de não ML. A amostra é só da Microsoft e autorrelatada, e os autores dizem que algumas conclusões podem ser específicas daqueles times.

Miryung Kim e colegas entrevistaram 16 cientistas de dados de oito organizações da Microsoft e, num artigo de 2016, descreveram cinco arranjos: um triângulo de cientistas de dados, curadores de dados (data stewards) e engenheiros de instrumentação; um modelo hub-and-spoke, com um time central de plataforma e times satélites ligados a produtos; um modelo de consultoria; o cientista de dados solitário dentro de um time de produto; e um time virtual desses indivíduos. O artigo se descreve como um estudo qualitativo baseado em 16 entrevistas, e a parte que li lista os arranjos sem classificá-los. O que se aproveita aqui é que onde colocar o especialista já era uma pergunta em aberto para cientistas de dados, antes de os produtos de IA multiplicarem os papéis especializados.

Veja como a fronteira falha num exemplo inventado. Suponha que um assistente de triagem de sinistros seja construído por quatro grupos: um time de dados que cuida da ingestão de documentos e do índice de recuperação, um time de plataforma que cuida do gateway de modelos, um time de produto que cuida da interface e do prompt, e um grupo de analistas de sinistros que rotulam casos mas se reportam à área de operações. O time de dados reduz o tamanho do chunk de 800 para 400 tokens porque sua própria medida offline, a revocação nos dez primeiros, sobe de 0,71 para 0,78. O prompt, porém, havia sido ajustado sobre os chunks maiores, que traziam contexto suficiente ao redor para o modelo responder certo. A acurácia fim a fim na checagem por amostragem de 200 casos do time de produto cai de 0,84 para 0,77. Nenhum painel mostra isso, porque a única medida fim a fim é uma checagem feita quando alguém se lembra, e os analistas que poderiam notar estão a duas linhas hierárquicas de distância. Os clientes veem a queda antes de qualquer pessoa dos quatro times. Esses números são ilustrativos, inventados para o exemplo, e os listo assim nas fontes.

A aritmética da coordenação aponta para o mesmo lado. Um grupo de n pessoas tem n(n-1)/2 caminhos de comunicação possíveis entre pares, a fórmula que Fred Brooks usou e que a equipe de Nagappan citou. Para um time de 8 são 28. Um grupo plano de 24 tem 276, e uma mudança que toca quatro times separados exige seis acordos entre times antes de alguém escrever código. Esses números contam ligações possíveis e nada dizem sobre a frequência das conversas. Ainda assim delimitam o problema: uma fronteira de time que corta uma interface que muda toda semana transforma cada mudança numa negociação.

Trace as fronteiras dos times em torno de fatias do trabalho do usuário, com o conjunto de avaliação dentro

Um podcast da ThoughtWorks atribui a manobra inversa de Conway a Jonny LeRoy e Matt Simons, que escreveram sobre ela em 2010. A ideia deles é tratar a força como dada e usá-la: escolha a arquitetura que você quer e depois organize os times de modo que as linhas de comunicação passem onde as interfaces devem ficar. Para um produto de IA, eu traçaria as fronteiras em torno de fatias de trabalho voltadas ao usuário, como tratar um sinistro, responder a dúvida de um cliente sobre cobrança ou redigir o resumo de um contrato. Camadas de tecnologia, como recuperação, acesso a modelos e interface, dão fronteiras piores. Uma fatia contém o prompt, a configuração de recuperação, as definições de ferramentas, o conjunto de avaliação e o monitoramento, de modo que as partes que mais interagem ficam dentro de um mesmo time.

Matthew Skelton e Manuel Pais, em Team Topologies (IT Revolution, 2019), nomeiam quatro tipos de time e três modos de interação entre eles: colaboração, X-como-serviço e facilitação. Aplicada a uma organização de produtos de IA, a estrutura que eu desenharia tem estas partes.

1. Times de produto alinhados ao fluxo de valor, cada um dono de uma fatia inteira do trabalho do usuário, o que inclui o prompt, a configuração de recuperação, as integrações de ferramentas, o conjunto de avaliação, o portão de liberação e a escala de plantão. Um especialista de domínio, como um analista de sinistros ou um líder de suporte, escreve e rotula os casos de avaliação como membro nomeado do time, com esse trabalho no backlog do próprio time.
2. Um time de plataforma que oferece caminhos pavimentados como serviço: um gateway de modelos com roteamento, orçamentos e logs, um executor de avaliações que se encaixa na integração contínua, rastreamento, versionamento de prompts e de índices, e acesso a dados com permissões. Ele é julgado pela rapidez com que um time de produto chega à primeira avaliação funcionando e pela raridade com que os times precisam pedir ajuda.
3. Um grupo habilitador com os especialistas escassos em metodologia de avaliação, testes de segurança e fine-tuning. Ele trabalha com um time de produto por algumas semanas, deixa para trás uma habilidade ou uma ferramenta e segue adiante, o que evita que os especialistas virem uma fila de aprovação.
4. Um time de subsistema complicado somente onde um componente exige trabalho especializado profundo que um time de produto não consegue assumir com razoabilidade, como um modelo proprietário de ranqueamento ou uma pilha de voz. Muitas empresas não precisarão de nenhum.

A responsabilidade pela avaliação, no primeiro item, é a parte que mais estou disposto a defender. Num post de engenharia de janeiro de 2026, a Anthropic disse ter experimentado várias abordagens para manter as avaliações. A que se mostrou mais eficaz, segundo ela, foi ter um time dedicado a avaliações responsável pela infraestrutura central, enquanto especialistas de domínio e times de produto contribuem com a maior parte das tarefas de avaliação e as executam por conta própria. O post diz que os times de produto devem tratar a responsabilidade por manter as avaliações como manter testes unitários, e sugere que gerentes de produto, pessoal de sucesso do cliente e vendedores, que estão mais perto do que os usuários precisam, podem submeter tarefas de avaliação como pull requests. É um fornecedor descrevendo seu trabalho interno e o de clientes, sem grupo de comparação, mas combina com a topologia acima: ferramentas centrais e posse local sobre o que conta como correto. Já escrevi neste site que o conjunto de avaliação é a especificação. Se for verdade, o time dono da especificação precisa ser o que responde pelos resultados para o usuário.

Onde a evidência termina e a heurística começa

Parte do argumento se apoia em evidência de força moderada, toda ela observacional. O espelhamento é uma tendência comum, segundo a revisão de 142 estudos. As medidas organizacionais previram falhas pós-lançamento melhor que as de código num sistema muito grande. O programa de pesquisa DORA, mantido pelo Google Cloud, descreve times fracamente acoplados como os que conseguem testar, fazer deploy e alterar seus sistemas sem depender de outros times, associa essas estruturas a melhor desempenho de entrega e sugere acompanhar a parcela de mudanças de projeto que precisam de aprovação de fora do time.

O relatório de 2025 do DORA sobre desenvolvimento de software assistido por IA se baseia em respostas de quase 5.000 profissionais de tecnologia mais dados qualitativos, coletados entre 13 de junho e 21 de julho de 2025. Uma pesquisa desse tipo mostra associação e não estabelece causa. O relatório constata que 90% das organizações adotaram pelo menos uma plataforma interna e que 76% têm pelo menos um time de plataforma dedicado. Para este texto, o dado mais relevante é que a adoção de IA tem efeito desprezível sobre o desempenho organizacional quando a qualidade da plataforma interna é baixa e efeito positivo forte quando é alta. Ainda segundo o relatório, a adoção de IA aumentou a instabilidade da entrega. Um caso nele, de um executivo da Adidas descrevendo um piloto de IA generativa, diz que times em arquiteturas fracamente acopladas e com ciclos de feedback rápidos tiveram ganhos de produtividade de 20% a 30% em commits, pull requests e velocidade de entrega, enquanto times fortemente acoplados a sistemas ERP, com ciclos mais lentos, tiveram pouco ou nenhum benefício. É o resultado citado de um piloto, que trato como anedota.

O escopo desse relatório limita o que ele consegue sustentar. A IA ali é sobretudo assistência de código usada por times de software, o que difere de construir uma funcionalidade de IA para clientes. Aplicar a conclusão sobre plataformas a times que entregam produtos com LLMs é uma extensão, e a faço como julgamento: um time com uma plataforma interna ruim não consegue absorver uma nova capacidade a baixo custo, seja qual for a capacidade.

O restante são heurísticas. A proposta de que um time alinhado ao fluxo de valor seja dono do próprio conjunto de avaliação tem por trás um relato de prática, mais um preprint de dezembro de 2025 de Melissa Pan e colegas sobre agentes em produção, baseado em 20 estudos de caso e numa pesquisa com 306 profissionais, dos quais 86 descreveram sistemas em operação. Esse artigo relata que 74% dos profissionais que responderam à pergunta sobre métodos de avaliação de agentes em operação se apoiavam em verificações com humanos no circuito (a base da cifra são 31 sistemas em operação, portanto pequena; pela minha aritmética, o número é 23), e descreve times de desenvolvimento trabalhando com especialistas de domínio para montar benchmarks. Isso mostra que o especialista de domínio precisa estar no circuito. Não mostra qual linha hierárquica produz as melhores avaliações. Para o grupo habilitador não encontrei evidência alguma além da lógica de que habilidades escassas devem se espalhar por ensino e não por fila. Team Topologies é um livro de praticantes, e não encontrei uma comparação controlada de topologias de times para produtos de IA nem para qualquer outra coisa.

A proposta também tem custos. Cada time de produto precisa de alguma habilidade em avaliação, então haverá trabalho duplicado até que o executor de avaliações da plataforma amadureça. Um time de plataforma pode derivar para o papel de porteiro, e é por isso que o conselho do DORA de tratar a plataforma como um produto interno importa. Uma empresa pequena com um único time de IA não ganha nada com o vocabulário, porque sua estrutura já é um time só. A topologia começa a compensar quando há várias fatias de trabalho, e o número a partir do qual isso acontece é um que não sei dar.

Duas objeções à lei de Conway, e por que nenhuma se sustenta por inteiro

A objeção mais forte vem em duas versões. Uma diz que a lei é trivialmente verdadeira: quem precisa conversar conversa, então as interfaces aparecem onde as conversas acontecem, e disso nada se segue. A outra diz que a força que a lei um dia teve se enfraqueceu, porque repositórios compartilhados, chat, videochamadas e agora assistentes de código com IA deixam qualquer pessoa coordenar com qualquer outra.

A versão do enfraquecimento tem apoio parcial, vindo dos revisores da evidência. Colfer e Baldwin viram que projetos colaborativos abertos na maior parte não espelhavam sua estrutura e sugerem que ferramentas digitais de coordenação podem explicar isso. Martin Fowler, no podcast da ThoughtWorks, disse que a força da lei está sempre presente. Acrescentou que o trabalho remoto leva a uma comunicação menos rica que a do trabalho em proximidade física e que provavelmente é cedo demais para saber como esses prós e contras vão se equilibrar. A melhor evidência direta sobre ferramentas vem de Longqi Yang e colegas, que analisaram dados de e-mail, agenda, chat e chamadas de 61.182 funcionários da Microsoft nos Estados Unidos no primeiro semestre de 2020. Quando a empresa inteira passou ao trabalho remoto, a rede de colaboração ficou mais estática e mais fechada em silos, com menos pontes entre grupos, e um texto da Microsoft Research põe a queda no tempo de colaboração entre grupos em cerca de 25% do nível anterior à pandemia. A mudança foi imposta pela pandemia e não foi uma escolha ponderada de ferramentas, então não prova que ferramentas melhores não dariam conta. Mostra, sim, que um canal aberto para todos não faz as pessoas o usarem, e a lei depende exatamente dessa distância entre quem poderia conversar e quem conversa.

Quanto à trivialidade, concedo que "a estrutura segue a comunicação" é quase uma tautologia na sua forma mais fraca. Ela diz algo útil em dois pontos: prevê onde os defeitos se concentram, como o estudo do Vista encontrou, e implica que uma reorganização é uma decisão de arquitetura, o que o próprio Conway afirmou. Fica devendo na direção, e é aí que a manobra inversa corre um risco. Os pares combinados de MacCormack comparam organizações de tipos diferentes, e o estudo do Vista observa as organizações como elas eram. Nenhum dos dois mostra que redesenhar os times de uma empresa existente vai redesenhar seu software. Acredito que, para sistemas de IA, a direção corre nesse sentido, porque os artefatos são baratos de criar e de mover, e quem os possui tende a definir as interfaces. Sustento essa crença pelo mecanismo e pelas conclusões de Amershi sobre componentes entrelaçados, e não porque alguém tenha feito o experimento.

Antes da próxima reorganização, conte os times de que cada regressão precisou

Desenhe numa página o grafo de dependências da funcionalidade de IA: o modelo e sua versão fixada, o prompt, o índice de recuperação, as APIs de ferramentas, os dados que alimentam o índice, o conjunto de avaliação e o monitor online. Ao lado de cada nó, escreva o nome do time que consegue alterá-lo sem pedir nada a ninguém. Depois, pegue as cinco últimas regressões ou incidentes e conte quantos times cada um precisou para ser diagnosticado e corrigido. A medida sugerida pelo DORA, a parcela de mudanças de projeto que exigem aprovação de fora, é uma forma razoável de manter a contagem honesta ao longo do tempo.

Mais duas verificações são rápidas. O dono do conjunto de avaliação pode bloquear uma liberação? E esse dono está na mesma linha hierárquica de quem responde pelos resultados para o usuário? Se as duas respostas forem não, você achou a fronteira, e o primeiro passo mais barato é pôr um especialista de domínio e o conjunto de avaliação dentro do time de produto, antes de mexer em qualquer outra coisa.

A pergunta que não consigo resolver é o que acontece quando uma dúzia de times de produto compartilha um único gateway de modelos. Uma dúzia de conjuntos de avaliação com donos locais dá a cada time controle ao preço de padrões inconsistentes. Um conjunto único, de propriedade de um grupo central, dá consistência ao preço do problema original, um dono distante do usuário. A divisão da Anthropic, infraestrutura central e tarefas locais, é uma resposta, e ninguém publicou dados que a comparem com as alternativas.

Fontes

1. Nagappan, N., Murphy, B., Basili, V. R. (2008). The Influence of Organizational Structure on Software Quality: An Empirical Case Study. Proceedings of the 30th International Conference on Software Engineering (ICSE), pp. 521-530; relatório técnico MSR-TR-2008-11 da Microsoft Research. Os números de precisão e revocação são da Tabela 4 do relatório.
2. Conway, M. E. (abril de 1968). How Do Committees Invent? Datamation 14(4). melconway.com/Home/Committees_Paper.html.
3. MacCormack, A., Baldwin, C. Y., Rusnak, J. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the "Mirroring" Hypothesis. Research Policy 41(8), 1309-1324; texto completo aceito pelos autores, lido via Harvard DASH; o Harvard Business School Working Paper 08-039 é a versão anterior.
4. Colfer, L. J., Baldwin, C. Y. (2016). The Mirroring Hypothesis: Theory, Evidence, and Exceptions. Industrial and Corporate Change 25(5), 709-738 (resumo lido; texto completo não lido).
5. Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., Zimmermann, T. (2019). Software Engineering for Machine Learning: A Case Study. ICSE, trilha Software Engineering in Practice.
6. Kim, M., Zimmermann, T., DeLine, R., Begel, A. (2016). The Emerging Role of Data Scientists on Software Development Teams. ICSE 2016.
7. Skelton, M., Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press; tipos de time e modos de interação conforme listados em teamtopologies.com/key-concepts.
8. ThoughtWorks Technology Podcast. Reckoning with the force of Conway's Law (atribuição da manobra inversa de Conway a Jonny LeRoy e Matt Simons, 2010, grafado Johnny Leroy na transcrição; comentários de Martin Fowler sobre trabalho remoto). thoughtworks.com/insights/podcasts/technology-podcasts/reckoning-with-the-force-conways-law.
9. DORA (Google Cloud). Capabilities: Loosely coupled teams. dora.dev/capabilities/loosely-coupled-teams/.
10. DORA (2025). State of AI-assisted Software Development. Google Cloud; pesquisa aplicada de 13 de junho a 21 de julho de 2025.
11. Anthropic (9 de janeiro de 2026). Demystifying evals for AI agents. anthropic.com/engineering/demystifying-evals-for-ai-agents.
12. Pan, M. Z. et al. (dezembro de 2025, revisado em 2026). Measuring Agents in Production. arXiv:2512.04123.
13. Yang, L., Holtz, D., Jaffe, S., Suri, S., et al. (2021). The effects of remote work on collaboration among information workers. Nature Human Behaviour, doi:10.1038/s41562-021-01196-4; o número de 25% vem do texto da Microsoft Research sobre o artigo.
14. Exemplo ilustrativo de triagem de sinistros: tamanho do chunk de 800 para 400 tokens, revocação nos dez primeiros de 0,71 para 0,78, acurácia fim a fim de 0,84 para 0,77 em 200 casos. Tudo inventado para este ensaio.
15. Aritmética ilustrativa de caminhos de comunicação: n(n-1)/2 para n = 8 (28) e n = 24 (276), a fórmula que Brooks usou e que Nagappan et al. citam; contagens de ligações possíveis, não dados.