segunda-feira de manhã. abri o github e tinha nove PRs me esperando. todos do mesmo autor.
somei os diffs: quase nove mil linhas. três PRs passavam de duas mil linhas cada.
reclamei no slack. educadamente, mas reclamei.
a resposta não veio sobre o tamanho. veio sobre o processo de validação. segundo o autor, cada PR passava por TDD com testes escritos antes do código, revisão automática pelo claude code, uma segunda revisão por outro modelo, uma terceira pelo copilot, e mais uma revisão manual dele antes de abrir.
múltiplos ciclos. tudo robusto. tudo legítimo.
e tem mais. ele lembrou que os nove PRs não são um monolito — estavam divididos em três batches por prioridade, cada PR com escopo próprio. nessa ele tinha razão também. dividir em PRs menores é exatamente o que a gente pede em qualquer discussão de processo. e ele fez. respeito.
só que ele tava respondendo a uma pergunta diferente da que eu tava fazendo.
review não é pra conferir se funciona
a defesa dele parte de uma premissa: que code review existe pra conferir se o código funciona. se já passou por cinco camadas de validação antes de abrir o PR, a sexta camada — eu lendo o diff — seria redundância. LGTM e segue.
essa leitura parece óbvia. mas erra o ponto.
review nunca foi sobre conferir se o código funciona. teste faz isso. CI faz isso. agente faz isso. review feito por outra pessoa serve pra dividir conhecimento. o que existe no sistema, por que existe, e como mexer sem quebrar.
isso é o que acontece quando duas pessoas leem o mesmo diff. quem revisa dificilmente vai pegar mais bugs do que a CI já pegou. mas sai da leitura sabendo o que mudou e por que mudou. e esse conhecimento, dividido pelo time, é a única coisa que evita que cada parte do sistema ganhe dono único.
já escrevi sobre isso antes na newsletter — defendi que review é mentoria disfarçada de processo, passagem de conhecimento entre senior e junior. aquela formulação ficou curta. review não é só um jeito de fazer mentoria. é o jeito que um time deixa de ser uma coleção de pessoas escrevendo pedaços disjuntos do mesmo repositório.
e é exatamente aí que a aritmética do meu colega quebra.
o silo não nasce do tamanho do PR. nasce da fila.
dividir em nove PRs em vez de um monolito é melhor. ninguém discute isso. mas se três daqueles PRs têm mais de dois mil linhas cada, e todos caem na mesma semana na mesma pessoa, o efeito prático é parecido com o do monolito: quem revisa lê os três grandes superficialmente, aprova os pequenos no automático, e ninguém — exceto o autor — sai dali entendendo o que tá no código.
quando nove mil linhas só foram lidas com atenção por uma pessoa — por mais cuidadosa que ela seja, por mais ciclos de validação que ela tenha rodado — o sistema tem um dono só. e isso não é eficiência. é fragilidade.
amanhã essa pessoa tira férias. ou troca de squad. ou (sei lá) ganha na megasena e some. quem entende aquele código? a resposta sincera é: ninguém. e quando a próxima feature precisar tocar nessa parte do sistema, alguém vai ter que reconstruir do zero o entendimento que existia na cabeça de uma única pessoa que não tá mais ali.
esse custo não aparece no CI, não aparece em multi-model review, não aparece em métrica nenhuma de produtividade. ele aparece três meses depois, quando alguém abre uma função e pergunta “por que isso tá assim?” e a thread do slack mostra que só uma pessoa leu aquilo com atenção — e essa pessoa não tá mais no time.
multi-model review acelera o review feito por gente. não substitui. confundir as duas coisas é o erro que custa caro depois.
o gargalo sempre esteve ali
eu gosto da metáfora da rodovia. toda estrada tem um ponto onde o tráfego afunila — uma ponte mais estreita, uma curva, uma obra. enquanto passam poucos carros, ninguém percebe. quando o fluxo aumenta, é ali que o trânsito para. e a gente descobre que aquele ponto sempre foi o limite — só não dava pra ver.
por décadas o gargalo da engenharia foi escrever código. quem escrevia mais código mais rápido era o “produtivo”. as ferramentas que ganharam o coração de todo mundo — IDE com autocomplete, copilot, cursor, agentes — sempre foram, no fundo, ferramentas pra escrever mais código mais rápido.
review existia como cerimônia. carimbo no fim do processo. e funcionava — porque, enquanto escrever era a parte cara, a divisão de conhecimento acontecia naturalmente. você lia o PR porque o autor tinha demorado uma semana pra escrevê-lo, e revisar parecia justo. ninguém ia te entregar quatro mil linhas numa tarde — então ninguém ia te entregar quatro mil linhas pra você fingir que tinha lido.
agora o agente entrega. e a cerimônia ficou escancarada.
o que ficou exposto é uma pergunta que sempre existiu, só escondida pela cadência humana da escrita: alguém além do autor entende o que tá sendo construído?
quando a resposta é “não”, o time não tá sendo eficiente. tá acumulando uma dívida que ninguém anotou em lugar nenhum.
o trabalho mudou de cômodo
essa é a parte que importa.
engenharia nunca foi só sobre escrever código. sempre foi sobre julgamento, contexto e conhecimento compartilhado. o problema é que escrever consumia tanto tempo que parecia ser o trabalho principal.
se gerar código ficou barato, o trabalho deslocou. saiu da escrita e foi pro entendimento. e o entendimento, pra valer pra alguma coisa, precisa estar em mais de uma cabeça. isso não é detalhe de processo — é o que define se um repositório é de um time ou de uma pessoa que por acaso trabalha num time.
review é caro. é mais caro agora do que antes, porque os PRs ficaram maiores e mais frequentes. e é mais necessário agora do que antes — exatamente porque a escrita ficou barata, e a única forma de impedir que cada feature vire propriedade privada do autor é forçar uma segunda cabeça humana a passar pelo diff.
quem ainda trata review como camada redundante depois das outras não tá errado sobre validação. tá errado sobre o que review é.
a frase “eu já valido cinco vezes antes de abrir” é honesta, é técnica, é respeitável. e também é, sem querer, a definição perfeita do problema. cinco camadas de validação continuam sendo uma cabeça só.
essa é a versão filosófica. na testando em produção eu já escrevi sobre o lado tático: quais são os limites de tamanho de PR que time grande pratica, o que anthropic, google e openai fazem internamente pra resolver isso, e que ações dá pra começar amanhã sem trocar nenhuma ferramenta.