A Lei de Conway não morreu — ela só ficou mais rápida (e mais honesta)

Outro dia, em uma conversa com um grupo de líderes de tecnologia, alguém jogou uma pergunta no ar que ficou ecoando na minha cabeça por dias: “Com times autônomos e IA assumindo boa parte da execução, a Lei de Conway ainda faz sentido?”

A resposta curta é: faz. A resposta comprida é o que você vai ler agora.

Enunciada por Melvin Conway em 1967, a lei diz que “as organizações que projetam sistemas são restritas a produzir projetos que são cópias das estruturas de comunicação dessas organizações”. Em outras palavras: o software espelha quem fala com quem. Sempre foi assim.

O que mudou — e de forma bastante acelerada — é o que conta como “comunicação”.

O novo espelho: dados, prompts e orquestração

Em times tradicionais, organizados em silos rígidos, a Lei de Conway se manifestava como monolitos: sistemas onde o código de marketing não sabia nada sobre o código financeiro, e vice-versa, porque os times simplesmente não se falavam.

Depois vieram as squads multifuncionais — o famoso modelo two-pizza team popularizado pelo Bezos, onde um time não pode ser maior do que a quantidade que duas pizzas conseguem alimentar. Com UX, Dev e QA dentro de uma mesma célula autônoma, o software começou a refletir esse desacoplamento: nasceram os microsserviços, as APIs bem definidas, os bounded contexts do Domain-Driven Design.

Interessante notar que nenhuma dessas mudanças “quebrou” a Lei de Conway. Elas simplesmente a atualizaram.

E agora chegamos aos chamados Zero-Pizza Teams — fluxos onde agentes de IA realizam tarefas que antes exigiriam coordenação humana intensa. Prompts, APIs e orquestração de agentes substituem a reunião de alinhamento. A “conversa” acontece entre modelos, contextos e bases de conhecimento.

O ponto é que a Lei de Conway continua valendo. O sistema ainda espelha a estrutura de comunicação. Mas a estrutura de comunicação agora inclui — e às vezes é dominada por — como a IA foi treinada e com quais dados.

O novo perigo: o Silo de Contexto da IA

Pense em uma cozinha profissional. Cada estação — grelha, fritura, confeitaria — opera com autonomia. O chef-executivo define o cardápio, e cada estação entrega sua parte. Se a comunicação entre as estações funciona bem, o prato que chega à mesa é coerente. Mas se a confeitaria nunca conversa com a cozinha fria, você vai servir uma sobremesa que ninguém pediu e esquecer a entrada que estava prevista.

Nos times de tecnologia com IA, o risco é análogo. Se cada squad usa uma ferramenta de IA diferente, com bases de conhecimento isoladas e vocabulários distintos, o sistema resultante pode ser tecnicamente funcional, mas conceitualmente fragmentado.

O código gerado por uma IA treinada apenas nos dados do time de Marketing vai refletir as premissas e os vieses daquele silo. A Lei de Conway não desapareceu — ela apenas mudou de sujeito. Agora ela se aplica ao conjunto de dados que alimentou o modelo.

Na prática, isso significa que a Linguagem Ubíqua — aquele vocabulário compartilhado que o DDD tanto defende — deixa de ser apenas uma boa prática de design. Ela se torna o cimento que evita que a autonomia das squads se transforme em caos arquitetural.

A inversão que ninguém esperava

Há um paradoxo interessante no modelo de squads altamente autônomas. Quanto mais independente uma squad, mais limpa tende a ser a interface que ela expõe para o resto da organização — afinal, ela precisa declarar claramente o que produz e o que consome. É a Lei de Conway trabalhando a favor do design.

Mas existe um ponto de ruptura.

Se as squads forem autônomas demais, sem uma “camada de plataforma” que conecte as decisões, o sistema vira uma colcha de retalhos de tecnologias que não se conversam. É o isolamento social das squads refletido na arquitetura.

A IA, curiosamente, pode ajudar aqui. Quando bem implementada como infraestrutura compartilhada — e não como ferramenta individual de cada squad — ela atua como redutor de ruído cognitivo, facilitando a comunicação entre times A e B e, consequentemente, tornando a interface entre os sistemas A e B mais fluida.

É como se a IA fosse o chef-executivo que circula por todas as estações da cozinha, garantindo que o cardápio faça sentido como um todo.

O que muda (e o que não muda) no jogo

Olhando para a evolução dos modelos organizacionais:

• Era tradicional: hierarquia rígida e silos → aplicações emmonolitos, onde o código reflete a burocracia
• Era das squads: times multifuncionais → microsserviços e APIs, onde o código reflete a autonomia coordenada
• Era AI-driven: orquestração de agentes e prompts → arquitetura serverless e modularidade extrema, onde o código reflete os dados e o contexto com que a IA foi alimentada

O que não muda: a estrutura de comunicação sempre encontra um jeito de aparecer no software. Sempre.

O que muda: a nossa responsabilidade de projetar intencionalmente essa estrutura de comunicação — incluindo como treinamos, contextualizamos e conectamos os agentes de IA que agora fazem parte do time.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin Conway, 1967

Cinquenta e oito anos depois, a frase continua mais atual do que nunca. Só precisamos expandir o que entendemos por “estrutura de comunicação”.

A pergunta que fica: a introdução de IA no dia a dia do seu time está aproximando as áreas — criando uma linguagem e um contexto compartilhados — ou está construindo novos muros, desta vez invisíveis, escondidos dentro dos dados de treinamento e dos prompts isolados de cada squad?