--- title: "Quando o líder técnico para de ler código, a arquitetura vira ficção" author: "Pedro Dalben" date: "2026-09-16T11:01:30Z" category: "Arquitetura & CTO" reading_time: "7 min" canonical: "https://pedrodalben.com.br/blog/quando-o-lider-tecnico-para-de-ler-codigo-a-arquitetura-vira-ficcao" --- # Quando o líder técnico para de ler código, a arquitetura vira ficção > Confiar apenas em resumos e diagramas tira do CTO a capacidade de enxergar onde o sistema realmente vai quebrar em produção. **Autor:** Pedro Dalben (CTO no Integrar Plus) **Publicado em:** 16 de September de 2026 **URL Canônica Oficial:** [https://pedrodalben.com.br/blog/quando-o-lider-tecnico-para-de-ler-codigo-a-arquitetura-vira-ficcao](https://pedrodalben.com.br/blog/quando-o-lider-tecnico-para-de-ler-codigo-a-arquitetura-vira-ficcao) --- O debate recente sobre continuar lendo código-fonte expôs uma fratura que já vinha crescendo nos bastidores da liderança técnica. De um lado, há quem defenda abertamente que programar virou uma etapa descartável, quase uma camada burocrática entre a ideia e o software em execução, argumentando que insistir em ler cada linha é apego nostálgico de quem ainda quer se provar esperto. Do outro lado, engenheiros mais céticos rebatem que parar de ler código equivale a terceirizar o pensamento para modelos estatísticos que cortam caminho na manutenibilidade assim que o contexto cresce. Eu discordo do primeiro grupo com veemência, mas acho o diagnóstico do segundo incompleto. A questão não é se os agentes geradores cometem atrocidades na sintaxe. A questão é o que acontece com a cabeça de quem decide a arquitetura quando essa pessoa deixa de inspecionar o código real que roda nos servidores. Quando um CTO ou arquiteto se afasta do código e passa a gerenciar sistemas apenas por resumos de pull requests, diagramas no Miro e dashboards de métricas de alto nível, ele perde a sensibilidade para o atrito da infraestrutura. A arquitetura deixa de ser a estrutura de sustentação de um sistema vivo e se torna uma ficção confortável. ### A ilusão do resumo perfeito Existe uma fantasia muito sedutora de que liderança técnica sênior opera exclusivamente no plano das grandes ideias. Nessa visão, o líder desenha o fluxo, define os contratos de API e deixa a implementação para o time ou para ferramentas automáticas. O problema dessa abordagem é que código nunca foi apenas detalhe de implementação. Código é onde as premissas de negócio colidem com as leis da física da máquina: conexões de banco, latência de rede, alocação de memória e concorrência. Se eu avaliar uma mudança arquitetural apenas pela descrição do diff ou pelo sumário gerado por um modelo, tudo parece razoável. No papel, orquestrar três serviços diferentes para salvar um registro parece modular e limpo. No código, isso costuma se traduzir em chamadas HTTP síncronas dentro de um loop, sem retentativas idempotentes e abrindo transações longas no PostgreSQL. Quem não abre o arquivo não vê isso. Quem não inspeciona a implementação não percebe que uma biblioteca recém-adicionada puxou dezenas de dependências transitórias para resolver algo que três linhas de Ruby nativo resolveriam. O resumo esconde a sujeira que derruba o processo na VPS às três da manhã. ### Vibecoding e a quebra de contrato dentro do time Uma das maiores fricções nos times de engenharia surge ao juntar quem trata código como artefato descartável e quem o trata como passivo de manutenção. O sujeito que gera dezenas de linhas sem ler considera que o objetivo é apenas fazer o teste passar. Se alguém pede para ele explicar por que escolheu determinada estrutura de dados, ele se ressente, porque gastou o tempo ajustando prompts para ignorar justamente esse nível de detalhe. Isso destrói o alinhamento técnico. Quando lidero um time, o meu papel não é apenas aprovar features, mas garantir que o sistema continue legível e operável daqui a três anos com o menor custo operacional possível. Se o time começa a entregar blocos de código que ninguém leu de ponta a ponta, a base vira uma colcha de retalhos. Não adianta fingir que compiladores e frameworks já faziam isso no passado. O compilador C ou o parser do Ruby seguem regras determinísticas e previsíveis. Quando uma biblioteca do ecossistema Rails adota uma convenção, existe documentação, histórico e padrões testados pela comunidade. A geração cega de código introduz pequenos desvios de padrão em cada arquivo, fragmentando a base sem que ninguém assuma a autoria da decisão. ### O impacto direto na infraestrutura Operar sistemas com infraestrutura enxuta exige clareza sobre onde cada recurso é gasto. Quando rodo aplicações em servidores próprios, a margem para desperdício estrutural é baixa. Não existe a opção de simplesmente dobrar o tamanho da instância na nuvem para mascarar código ineficiente sem pagar a conta da complexidade. Se eu parar de ler o código das consultas que entram na aplicação, eu perco a capacidade de antecipar o esgotamento do pool de conexões do PostgreSQL. Se eu não olhar como os jobs em segundo plano estão sendo enfileirados, não consigo prever contenção de locks na tabela de filas. Essas falhas raramente aparecem em diagramas conceituais. Elas moram na ordem das operações dentro de um bloco, no uso indevido de callbacks e no esquecimento de índices compostos. ```ruby ## No resumo do PR: sincronizacao de status dos clientes ## No codigo real: N+1 queries disparadas silenciosamente pelo callback class Account < ApplicationRecord after_commit :notify_remote_service, on: :update private def notify_remote_service # Chamada de rede externa retendo a transacao no banco ExternalClient.sync(self.organization.external_id, self.status) end end ``` Nenhum sumário executivo vai apontar que o método acima segura uma transação aberta enquanto espera a resposta de uma API externa lenta. O resumo vai dizer apenas que a integração foi implementada conforme o requisito. O líder que perdeu o hábito de abrir o arquivo aprova a mudança achando que tomou uma decisão de integração segura, enquanto acabou de plantar um gargalo que vai travar as threads do servidor de aplicação. ### Ler código é um exercício de discernimento Ler código não é sinal de desconfiança com os desenvolvedores, nem apego vaidoso ao passado. É a única ferramenta que mantém o julgamento do engenheiro afiado contra o excesso de complexidade. Quando você lê código alheio com frequência, desenvolve um filtro quase intuitivo para identificar soluções que tentam resolver problemas que nem deveriam existir. Quem para de ler perde esse filtro rapidamente. Passa a aceitar padrões convolutos porque a justificativa teórica parece moderna. Passa a concordar com a introdução de camadas intermediárias de abstração que servem unicamente para isolar um código que já nasceu mal escrito. Em vez de simplificar a base, o arquiteto que não lê código tenta resolver complexidade ruim adicionando mais arquitetura por cima. Eu não leio todas as linhas de cada pull request que entra no repositório, e seria ingenuidade dizer que isso é viável em qualquer escala. Mas mantenho o hábito deliberado de abrir amostras reais do que está sendo escrito, investigar os gargalos na camada de persistência e examinar os pontos críticos de mutação de estado. Se você ocupa uma posição de liderança técnica e faz meses que não abre o editor para ler uma classe inteira de ponta a ponta, você já não está tomando decisões técnicas sobre a sua aplicação. Você está apenas palpitando sobre relatórios que escondem o estado real do seu produto. A decisão arquitetural legítima exige contato direto com a matéria-prima do sistema. ## Fontes - [https://zanlib.dev/blog/do-you-still-read-the-code/](https://zanlib.dev/blog/do-you-still-read-the-code/)