Existe um tipo de arquitetura que raramente quebra de forma espetacular, mas desgasta o time todos os dias.
Ela funciona. Entrega. Passa nos testes. Sobrevive a alguns incidentes. Em diagramas, pode até parecer elegante. O problema aparece em outro lugar: no tempo que uma pessoa leva para entender uma mudança simples, na quantidade de contexto que precisa manter na cabeça para fazer um ajuste aparentemente banal, no medo de tocar em certas partes do sistema e na dependência crônica de quem “já sabe como funciona”.
Foi por isso que eu passei a olhar para carga cognitiva não como um tema de produtividade individual, mas como um tema de arquitetura.
Toda arquitetura distribui complexidade. A pergunta nunca foi se o sistema será complexo ou não. A pergunta real é onde essa complexidade vai morar. Em sistemas bem desenhados, uma parte relevante dela é absorvida por contratos claros, boas abstrações, automação, caminhos pavimentados e padrões consistentes. Em sistemas mal desenhados, ela é empurrada para a cabeça das pessoas. E, quando isso acontece, a arquitetura continua “funcionando”, mas o fluxo de mudança começa a degradar.
O erro é tratar carga cognitiva como problema de treinamento
Quando um time começa a sentir dificuldade para avançar, a explicação mais comum costuma ser humana demais. Falta documentação. Falta senioridade. Falta organização. Falta alguém “mais dono” daquele pedaço. Às vezes isso tudo é verdade. Mas, em muitos casos, o problema é mais estrutural do que parece.
O sistema exige que as pessoas saibam coisas demais ao mesmo tempo.
Essa é uma diferença importante. Há uma distância enorme entre um ambiente em que a pessoa precisa entender o domínio para tomar boas decisões e outro em que, além do domínio, ela precisa manter na cabeça detalhes de pipeline, política de rede, convenção de observabilidade, formato de segredo, regras de rollout, exceções históricas e integrações implícitas só para fazer uma mudança comum com segurança.
Nesse segundo caso, não é o time que está “mal treinado”. É o sistema que está cobrando contexto demais.
Eu gosto de pensar nisso como um imposto arquitetural silencioso. Ninguém abre um incidente dizendo “a carga cognitiva ficou alta demais”. O que aparece são sintomas: onboarding lento, PRs que ficam dias em revisão, decisões excessivamente concentradas em algumas pessoas, receio de mexer em áreas específicas e aquela sensação recorrente de que qualquer ajuste simples exige uma expedição arqueológica.
Um exemplo arquitetural bem comum
Imagine uma empresa em que cada squad é responsável por colocar seus próprios serviços em produção do começo ao fim.
No papel, isso parece autonomia. Na prática, depende de como a arquitetura operacional foi montada.
Em um cenário, criar um novo serviço significa basicamente pegar um template, preencher alguns parâmetros de negócio, conectar observabilidade padrão, publicar em um pipeline já conhecido e seguir um fluxo previsível. O time ainda precisa pensar, claro, mas a maior parte da complexidade repetitiva foi encapsulada pela plataforma.
Em outro cenário, criar esse mesmo serviço exige que a squad decida ou redescubra detalhes de infraestrutura, autorização, instrumentação, política de retries, segredos, naming, dashboard, alertas, forma de deploy, esteira de compliance e rotas de integração com outros sistemas. O código da aplicação nem é o problema principal. O problema é tudo o que a pessoa precisa saber ao mesmo tempo para conseguir fazer o básico sem errar.
Os dois ambientes podem dizer que têm “times autônomos”. Mas apenas um deles tomou a decisão arquitetural de reduzir carga cognitiva.
Essa distinção fica ainda mais clara quando o sistema cresce. Em times pequenos, muita coisa se resolve na informalidade. Em organizações maiores, cada detalhe não encapsulado vira dependência humana. E dependência humana, quando se multiplica, vira lentidão.
Outro exemplo: o microserviço que era para isolar e acabou espalhando contexto
Eu já vi equipes dividirem um domínio em vários serviços com o objetivo legítimo de ganhar autonomia e escalabilidade. Só que o resultado, na prática, foi o oposto.
O problema não era a ideia de separação em si. O problema era que a fronteira entre os serviços exigia que qualquer pessoa envolvida entendesse demais do sistema como um todo. Para corrigir um comportamento em um ponto do fluxo, era preciso saber como a mudança afetava três modelos de dados diferentes, dois contratos assíncronos, um enriquecimento downstream e uma convenção operacional que nunca tinha sido realmente documentada.
Nessa hora, a arquitetura distribuída deixou de ser solução e passou a ser mecanismo de espalhamento de contexto.
Esse é um ponto que eu acho subestimado. Não basta perguntar se um serviço está bem isolado tecnicamente. Eu também quero saber se ele está bem isolado cognitivamente. Se uma mudança local exige entendimento profundo de cinco contextos adjacentes, esse serviço pode até estar separado no repositório, mas ainda não está bem separado na cabeça do time.
É por isso que eu gosto tanto de ligar esse tema ao que já escrevi em Design Modular: O Alicerce das Arquiteturas Evolutivas. Modularidade de verdade não é só quebrar em peças menores. É reduzir a quantidade de contexto simultâneo necessário para trabalhar em cada peça.
O reflexo na gestão aparece rápido
Esse assunto parece arquitetural, mas os sintomas aparecem muito cedo na gestão do time.
Uma das formas mais fáceis de perceber isso é observar como as cerimônias começam a se deformar. Refinamentos ficam mais longos porque cada tarefa puxa um fio de dependência invisível. Dailies deixam de ser sincronização curta e passam a virar fórum de esclarecimento estrutural. Reviews começam a depender sempre das mesmas pessoas. Um ou dois engenheiros viram “ponto de passagem obrigatório” para quase tudo. E o PM passa a perceber que estimativa está muito menos ligada ao tamanho funcional do pedido e muito mais ao grau de incerteza técnica que aquele pedido ativa.
Quando isso acontece, a arquitetura já está influenciando diretamente a forma como o time trabalha, mesmo que ninguém ainda tenha dado esse nome ao problema.
Eu já vi squads em que mudar uma regra de negócio simples levava dias não porque a regra fosse complexa, mas porque ninguém conseguia dizer com segurança quais eram todos os lugares afetados. O tempo não estava sendo gasto na implementação. Estava sendo gasto na reconstrução do contexto necessário para implementar.
Esse tipo de equipe costuma desenvolver alguns comportamentos muito reconhecíveis. O primeiro é a dependência de especialistas recorrentes. O segundo é o aumento de “vamos alinhar com fulano antes”. O terceiro é a dificuldade crescente de onboarding. O quarto é a sensação de que o sistema só é seguro nas mãos de quem já está cansado de conhecê-lo.
É difícil chamar isso de outra coisa que não uma falha arquitetural.
Um cenário de produto também ajuda a enxergar o problema
Vamos sair um pouco da engenharia pura.
Imagine um time de produto que quer testar uma mudança na jornada de onboarding de clientes PJ. A hipótese é simples: mover uma etapa de validação para mais cedo no fluxo pode reduzir abandono.
O time não está mexendo em um algoritmo sofisticado. Está mexendo em jornada, regra de negócio, eventos e integração entre sistemas internos.
Em uma arquitetura saudável, essa mudança deveria mobilizar as pessoas certas, mas sem exigir uma reconstrução total do ecossistema. O PM entende o impacto principal, o designer sabe onde a experiência muda, os engenheiros conseguem mapear os serviços e eventos envolvidos com clareza razoável, e o time consegue discutir rollout, métricas e fallback sem transformar a reunião em cartografia de território desconhecido.
Agora imagine a mesma hipótese num ambiente em que o fluxo está espalhado em vários serviços, com ownership difuso, contratos mal definidos e regras de negócio parcialmente implícitas em lugares diferentes. De repente, uma mudança de experiência aparentemente simples exige que o time entenda dependências técnicas demais só para formular o experimento direito.
Nesse momento, a carga cognitiva deixou de ser problema “do desenvolvedor”. Ela virou problema de produto, de planejamento e de capacidade de aprendizagem do time.
Isso me interessa muito porque mostra que arquitetura não afeta apenas velocidade de implementação. Ela afeta também a velocidade de descoberta.
O que a plataforma pode fazer — e o que ela piora quando é mal desenhada
Eu gosto de usar plataforma como exemplo porque ela mostra os dois lados da discussão.
Uma boa plataforma reduz carga cognitiva quando absorve complexidade repetitiva sem esconder o que é essencial. Ela oferece um caminho padrão para as coisas que acontecem o tempo todo. Não porque os desenvolvedores “não dariam conta”, mas porque repetir a mesma decisão 200 vezes não aumenta autonomia; só desperdiça energia.
Mas plataforma mal desenhada também consegue piorar muito o problema.
Isso acontece quando ela adiciona abstrações demais, documentação opaca, contratos confusos e camadas que ninguém entende completamente. Nesse caso, a promessa de simplificação vira outro sistema que o time precisa aprender para conseguir operar o primeiro. O resultado é perverso: em vez de reduzir carga cognitiva, a plataforma se torna mais um componente que precisa ser explicado, debugado e contornado.
É por isso que eu prefiro pensar em plataforma não como “camada obrigatória”, mas como mecanismo de compressão de contexto. Se ela não estiver comprimindo contexto relevante para o usuário, provavelmente está apenas deslocando complexidade de lugar.
IA torna esse problema mais urgente, não menos
Eu não colocaria IA no centro do artigo, mas acho impossível ignorar que ela intensifica essa discussão.
Se ferramentas de IA reduzem o custo de produzir código, testes, documentação e primeiras versões de solução, o gargalo se desloca ainda mais para entendimento, revisão, integração e operação. Em outras palavras, exatamente para as partes do sistema em que carga cognitiva mais importa.
Isso cria uma situação curiosa. Quanto mais fácil fica gerar mudança, mais importante se torna uma arquitetura que limite a quantidade de contexto simultâneo exigido para validar essa mudança com segurança.
Sem isso, o time até pode produzir mais rápido, mas vai acumular outra forma de caos: mais mudanças entrando num sistema que ninguém consegue compreender no mesmo ritmo em que ele é alterado.
A IA não cria esse problema. Ela só ilumina um ponto que sempre esteve ali: quando a arquitetura joga complexidade demais para as pessoas, qualquer aumento de velocidade em uma ponta do fluxo vira sobrecarga nas outras.
Onde a liderança técnica entra de forma muito prática
Se eu estivesse liderando um grupo de engenharia com esse critério em mente, eu começaria a observar menos “quão sofisticada é a solução” e mais “quanto contexto ela exige para operações comuns”.
Eu prestaria atenção em perguntas como:
quando uma mudança simples aparece, quantas pessoas o time sente que precisa consultar;
quanto tempo o PR passa em review não por detalhe de implementação, mas por falta de clareza de impacto;
quanto do onboarding é gasto aprendendo caminhos especiais;
e quantas exceções históricas precisam ser lembradas de cabeça para evitar erro.
Esses sinais costumam contar mais sobre a saúde da arquitetura do que muitos diagramas bonitos.
Eu também tentaria identificar áreas do sistema em que o custo cognitivo é maior do que o valor arquitetural da flexibilidade que elas oferecem. Nem toda abstração se paga. Nem toda separação em mais componentes reduz complexidade. Às vezes o sistema está elegantemente dividido no desenho e dolorosamente acoplado na prática.
A arquitetura que eu respeito mais hoje
Cada vez mais, eu respeito arquiteturas que conseguem fazer duas coisas ao mesmo tempo: manter espaço para evolução e limitar o contexto necessário para mudanças comuns.
Não me impressiona tanto uma arquitetura que só parece sofisticada. Me impressiona uma arquitetura em que uma pessoa nova consegue entender o caminho mais comum sem pedir socorro o tempo todo. Me impressiona um sistema em que ownership é legível, contratos são claros e a plataforma absorve o peso do que é repetitivo. Me impressiona uma organização em que a mudança não depende de heroísmo para continuar segura.
Talvez essa seja a forma mais contemporânea de olhar para qualidade arquitetural. Não apenas “isso escala?” ou “isso aguenta carga?”, mas também: isso preserva energia cognitiva suficiente para o time continuar mudando o sistema sem se afogar nele?
E, quanto mais eu penso nisso, menos me parece uma consequência secundária de boa arquitetura. Me parece uma das decisões arquiteturais mais importantes que podemos tomar.
