O real objetivo do code review: identificar códigos difíceis de manter

O debate reacendido por Mark Jason Dominus em Mathstodon, e que viralizou no Hacker News em 2 de julho de 2026, não é só teórico: ele coloca em xeque uma prática arraigada nas equipes de engenharia. Dominus afirma, com base em experiência prática e análise matemática da inspecionabilidade, que code review nunca foi ferramenta confiável para caçar bugs. O que funciona, na prática, é usar a revisão como um mecanismo de controle de complexidade cognitiva: se o revisor precisa ler três vezes para entender um bloco, esse trecho já falhou seu principal teste, o de ser mantido por outra pessoa.

Isso conecta-se diretamente às métricas humanas de manutenibilidade discutidas em abril: complexidade ciclomática não é só sobre loops e condicionais, mas sobre quantos caminhos mentais o desenvolvedor precisa percorrer para alterar algo com segurança. A abordagem vertical de código (também de abril) ganha ainda mais peso aqui: agrupar por funcionalidade reduz o salto cognitivo entre arquivos, alinhando-se ao objetivo central do review, diminuir esforço mental, não apenas contar linhas ou encontrar erros sintáticos.

A evolução real está na mudança de prioridade operacional: até junho de 2026, o CEVIU já havia mapeado a ascensão dos agentes de IA como coautores, mas o foco ainda era na 'confiança no código gerado'. Agora, com a nova orientação de julho, o critério de confiança deixou de ser abstrato, virou uma heurística concreta: legibilidade imediata. Isso significa que revisores não precisam mais justificar cada sugestão com 'isso pode dar erro'; basta dizer 'isso leva 12 segundos para eu entender, vamos simplificar enquanto o contexto ainda está fresco no autor'.

Porque reduzir a fadiga cognitiva do time é o primeiro passo para frear débitos técnicos que só aparecem em produção meses depois. Quando o code review vira um exercício de comunicação humana, e não de auditoria lógica, as equipes param de reescrever código por impulso (como mostrado em 3 de julho) e começam a preservar intenções de design (como alertado em 1º de abril). Isso também alinha a DX com a segurança: código legível é código auditável, testável e, consequentemente, menos vulnerável a explorações silenciosas.