Existe uma fé silenciosa na indústria de software de que mais camada é sempre melhor. Hexagonal, Clean Architecture, DDD tático, DDD estratégico, Saga, Event Sourcing, CQRS, o catálogo da arquitetura ritualística é vendido como prova de senioridade. Discordar é confessar imaturidade. Mas três números recentes, 76%, 58% e 7-13, começam a colocar preço nessa fé. E o preço não é abstrato. É medido em acurácia perdida, contexto desperdiçado e tempo humano queimado para fazer um agente entender o que deveria ser trivial.
Este post mergulha no que esses números significam, por que eles não são acidente, e por que o viés do LLM em direção a abstrações pesadas é estrutural, herdado direto do corpus de treinamento. Não é receita anti-arquitetura. É um chamado para parar de confundir cerimônia com engenharia, especialmente agora que parte do seu time é um agente de IA que paga, literalmente, em tokens e accuracy points, cada camada que você adicionou "para o caso de".
76%, A acurácia que evapora quando a dependência se esconde em DI/DIP
O primeiro número vem de benchmarks de agentes de código tentando rastrear dependências em projetos que aplicam Dependency Injection com Dependency Inversion Principle em todas as fronteiras. Quando o agente precisa responder "o que PaymentService realmente chama em produção?", a resposta correta exige seguir uma interface, um binding em container, uma factory, e finalmente uma implementação que pode estar em outro módulo. O agente acerta isso em 76% das vezes. Comparado com 95%+ em código direto, é uma queda brutal, e é uma queda silenciosa, porque o agente continua produzindo código que parece correto, mas que se ancora na implementação errada.
O problema não é DI. É DI ritualística: aplicada como default, sem que exista um segundo implementador real, sem que o teste se beneficie, sem que a fronteira justifique a indireção. A regra prática é direta: se existe exatamente uma implementação, e ela vai continuar sendo uma só, a interface é decoração. Para o humano lendo o código pela primeira vez, é uma camada de tradução. Para o agente, é um buraco onde a verdade some.
O que fazer na prática
- Inverta a presunção: a classe vai concreta até que apareça um segundo caso de uso real. Refatorar para interface depois custa minutos.
- Mantenha o wiring visível: container mágico que faz binding por convenção é veneno para qualquer leitor que não tenha o framework na cabeça.
- Anote o "porquê" da interface: se ela existe, deixe escrito qual é o segundo implementador (teste? adapter externo? feature flag?). Sem essa anotação, a interface é dívida disfarçada de princípio.
58%, Quando o agente prefere glob+read à ferramenta de navegação
Segundo número: em 58% das tarefas, agentes modernos ignoram as ferramentas de navegação de código fornecidas (LSP, símbolos indexados, MCP de codebase) e voltam para a heurística primitiva de glob + read. A explicação não é preguiça do modelo. É que arquitetura ritualística fragmenta o contexto a ponto de a indexação semântica entregar pior sinal que a varredura por nome. Quando uma feature está espalhada em domain/, application/, infrastructure/, interfaces/ e shared-kernel/, o resultado de um find symbol é uma lista de wrappers em volta de wrappers. glob "**/Payment*" + ler os 4 arquivos que aparecem é, empiricamente, mais rápido e mais correto.
Isso tem uma implicação dura para quem desenha codebase: a melhor ferramenta de navegação é uma estrutura de arquivos que torna a navegação desnecessária. Co-localização vence indexação. Um diretório por feature, com tudo da feature lá dentro, faz com que cd feature/ && ls seja mais informativo que qualquer árvore de símbolos. Não é primitivismo, é o reconhecimento de que o sistema de arquivos é uma estrutura de dados que LLMs já dominam profundamente, enquanto plugins de navegação dependem de tooling externo que pode falhar, estar desatualizado, ou simplesmente não existir no ambiente do agente.
7-13, O orçamento de contexto que sua arquitetura está queimando
Terceiro número: em codebases com separação rígida em domain/app/infra, o agente precisa abrir entre 7 e 13 arquivos para entender uma única feature ponta a ponta. Compare com a alternativa pragmática, controller, service, repository no mesmo arquivo, ou no máximo três arquivos co-localizados em features/payments/. A diferença é uma ordem de grandeza no consumo de context window, e tudo que entra no contexto desloca alguma coisa que poderia estar lá: a regra de negócio real, o teste relevante, o histórico do bug.
Cada arquivo extra cobra três pedágios. (1) Tokens lidos: pagos em latência e em custo. (2) Raciocínio para reconciliar nomenclatura entre camadas, porque PaymentDTO, PaymentEntity, PaymentModel e PaymentDomainObject tipicamente representam a mesma coisa com nomes diferentes, e o agente queima ciclos só para descobrir que são, sim, a mesma entidade. (3) Risco de o agente importar a abstração errada e produzir código que compila mas viola a regra que mora em outra camada. Os três pedágios são pagos em toda interação. A multiplicação se acumula até virar a maior parte da fatura mensal de tokens da sua empresa.
Abstraction Bloat: por que o LLM tem viés estrutural a favor de arquitetura pesada
Aqui está o ponto que poucos enxergam. O LLM não escolhe arquitetura hexagonal porque concluiu que é a melhor. Ele escolhe porque foi treinado em um corpus onde a esmagadora maioria do material técnico publicado fala sobre Event Sourcing, CQRS, Saga, DDD e Hexagonal. Ninguém publica um Medium chamado "Como mantenho há 5 anos um CRUD de 3 arquivos que serve 8 mil requests por minuto sem dor". Esse post não existe porque não dá engajamento, mas o sistema correspondente existe em produção em milhares de empresas que pagam suas contas todo mês.
O resultado é um viés estatístico que vira viés normativo: o modelo sugere a estrutura cerimoniosa porque é a estrutura visível no corpus. Engenheiros menos experientes confundem essa sugestão com best practice e aceitam sem questionar. Engenheiros experientes pisam no freio, mas o atrito é constante, recorrente, e cobra energia em toda sessão. O custo desse viés é cumulativo: cada decisão tomada na sombra do default cerimonioso adiciona mais uma camada que vai cobrar pedágio para sempre.
O reframe necessário
- Cerimônia ≠ engenharia. Engenharia é resolver o problema dentro do orçamento (de tempo, contexto, atenção, dinheiro). Cerimônia é executar o ritual independente de orçamento.
- Arquitetura é local, não universal. Hexagonal pode ser certo para o núcleo crítico do produto e absurdo para o serviço de notificação de email, e os dois podem coexistir no mesmo repositório sem hipocrisia.
- O agente é parte do time agora. Decisões de arquitetura têm que considerar o custo cognitivo para humanos e o custo de contexto/acurácia para agentes. Ambos pagam.
- Co-locação derrota indexação. Um diretório por feature, com tudo dentro, vence qualquer mapa mental de camadas espalhadas. Apagar a feature deveria ser apagar um diretório, não uma caça ao tesouro em cinco pastas.
O teste de senioridade invertido
Por anos a indústria mediu senioridade pela capacidade de adicionar abstração. Quem propunha Hexagonal era sênior. Quem propunha "service + db" era júnior. O novo teste é o oposto. Sênior é quem consegue olhar para uma feature de baixo risco que muda devagar e responder, sem culpa, "três arquivos resolvem". Sênior é quem percebe que a camada que está prestes a adicionar vai cobrar pedágio por dez anos para resolver um problema que pode nunca acontecer. Sênior é quem aceita que o sistema mais maduro é tipicamente o mais chato.
Os números do slide, 76%, 58%, 7-13, não estão dizendo que arquitetura é ruim. Estão dizendo que arquitetura ritualística cobra um preço que agora dá para medir. Ignorar o preço já era caro. Continuar ignorando, em um time onde metade das interações com o código passa por um agente, é decisão consciente de pagar imposto recorrente para parecer sênior em vez de ser sênior.
