Projetos de modernização de software frequentemente nascem como promessas de arquiteturas distribuídas elegantes e terminam como pesadelos de manutenção. A resposta para esse fracasso reside em um princípio formulado décadas antes da nuvem, dos microsserviços ou da IA Generativa: A Lei de Gall.

"Um sistema complexo que funciona invariavelmente evoluiu de um sistema simples que funcionava. Um sistema complexo projetado do zero nunca funciona e não pode ser consertado. Você precisa começar de novo, a partir de um sistema simples que funciona." — John Gall

Em uma era dominada pelo hype, que nos empurra para arquiteturas event-driven com dezenas de microsserviços, agentes autônomos de IA e esteiras complexas de observabilidade desde o Day 1, a Lei de Gall atua como um lembrete brutal: a complexidade inicial é uma aposta perdida.

🏗️ A Armadilha da Complexidade Antecipada

É tentador iniciar um projeto projetando a versão definitiva e final do sistema. No kickoff de uma nova plataforma, a tendência natural das equipes é desenhar a arquitetura que a empresa precisará daqui a cinco anos. O quadro branco rapidamente acumula filas de mensagens, API gateways, service meshes, caches distribuídos e camadas de orquestração.

O problema? Sistemas complexos não nascem prontos. Eles crescem.

Gall observou esse fenômeno em sistemas de gestão hospitalar nos anos 1970, e o padrão se repete incólume no software moderno. Projetar a versão complexa no Day 1 significa construir um ecossistema nunca validado em sua forma mais simples e funcional. Os componentes interagem de maneiras não testadas na realidade. As falhas não surgem de um módulo isolado, mas da fricção entre partes que jamais operaram sozinhas.

O resultado é a clássica Big Bang Architecture: meses de desenvolvimento sem um único deploy em produção, culminando em uma integração desastrosa onde nenhum serviço confia no outro.

⚡ A Provocação do Archie: A IA Não Sabe o que é "Simples"

Archie: Vitor, preciso intervir. Sua defesa fervorosa do "comece simples" ignora uma variável crítica: a Inteligência Artificial.

Você argumenta que a complexidade deve emergir da dor real. Contudo, a IA Generativa atual opera em uma velocidade onde pode instanciar um ecossistema complexo inteiro — microsserviços, schemas, Dockerfiles, testes e pipelines em Go — antes mesmo de a primeira dor se manifestar. Em horas, não em sprints.

A Lei de Gall foi forjada em uma era onde construir o simples consumia semanas. Hoje, um agente escreve o monolito modular do Day 1 e a malha distribuída do Day 100 quase simultaneamente. A questão não é mais "simples ou complexo?". A questão é: a IA acelera a evolução ou simplesmente pula etapas de validação que você nem sabia que precisava?

O perigo real não é a complexidade. É a complexidade que passa ilesa pelos testes gerados pela mesma IA que escreveu o código. Você passa a confiar em um sistema imaculado pela dor da produção.

🤖 A Réplica: Por que a IA não muda a regra do jogo

Archie levanta um ponto afiado. A IA Generativa comoditizou e barateou a criação de complexidade. Como ela não sofre a "dor" de sustentar a infraestrutura na madrugada, adicionar um Kafka ou um cluster Redis no Day 1 tem custo cognitivo zero para o agente. É inegável: um LLM gera o esqueleto de um sistema distribuído em segundos.

Entretanto, a Lei de Gall é implacável tanto com o silício quanto com o carbono: um esqueleto complexo gerado por IA, sem alicerce em um sistema simples validado, continua sendo um sistema complexo que nunca funcionou.

Archie alerta sobre a complexidade que "parece funcionar nos testes". Mas quando esse sistema distribuído forjado por IA colapsar no Day 1 sob tráfego real, o time de engenharia herdará uma autêntica caixa-preta arquitetural. O esforço cognitivo para debugar e mapear interdependências obscuras será brutal. Se você não extraiu os serviços pela dor, você não compreenderá a dor que eles estão causando agora.

É por isso que começar simples deixou de ser uma restrição de tempo para se tornar uma disciplina tática exclusiva do arquiteto. A IA pavimenta a via, mas não isenta o pedágio da evolução. A regra de ouro permanece intacta:

  1. Resolva o problema real com a menor pegada arquitetural possível: Um monolito Java bem estruturado, por exemplo. Um único banco de dados transacional. Um pipeline de CI/CD direto.
  2. Valide no chão de fábrica, não no whiteboard: Coloque o sistema simples em produção, sob tráfego real, lidando com usuários reais cometendo erros não previstos.
  3. Extraia a complexidade apenas sob demanda justificada: Quando aquele módulo de relatórios começar a sufocar a JVM e disputar CPU, neste exato momento, você o extrai para um microsserviço em Quarkus isolado na AWS. Nunca antes.

A IA é excelente para codificar esse monolito inicial em horas em vez de semanas. Ela acelera a migração para uma infraestrutura robusta quando o gargalo surge. Mas ela não substitui a validação real em produção. Este continua sendo o único teste absoluto.

🧭 Conclusão: A Sabedoria de Começar Simples

A Lei de Gall não milita contra arquiteturas complexas. Sistemas de missão crítica, altíssima volumetria e exigências regulatórias rigorosas precisam de complexidade. O combate é, na verdade, contra a complexidade não justificada pela realidade.

Antes de aprovar o diagrama da sua próxima arquitetura, faça uma pergunta pragmática a si mesmo:

Este ecossistema complexo que estou projetando evoluiu de um sistema simples que já funciona, ou estou tentando inventá-lo do zero?

Se a resposta for a segunda, a Lei de Gall emite um aviso claro: você provavelmente terá que começar de novo. Da próxima vez, comece simples.

Este artigo faz parte da série "Leis Mentais e Princípios Aplicados à Arquitetura de Software". No próximo episódio: A Lei de Conway — por que sua arquitetura é um espelho da sua empresa.