Revisão obrigatória de código não escala na era da IA

O desacordo

Rachel Laycock, CTO da Thoughtworks, responde a Brian Houck, do DX, após um painel no Code Remix, hospedado pela Moderne, em que os dois discordaram. Houck publicou depois o texto "What are code reviews even for?", e Laycock escreve esta réplica. Ela afirma que ambos querem, na prática, as mesmas coisas; a divergência está no meio: ela não acredita que a revisão de código seja a melhor forma de alcançá-los.

Os números que motivam o debate: segundo Houck, na Meta as linhas de código significativas por diff integrado por humano teriam crescido 106% em um ano, e dados do próprio DX mostram aumento mediano de 64% no tamanho dos pull requests. Laycock compartilha a preocupação de que automatizar a revisão eliminaria benefícios colaterais importantes: compartilhamento de conhecimento, formação de juniores, propriedade coletiva e alinhamento arquitetural.

Mover o julgamento para antes

A tese de Laycock: por que esperar até a revisão para ter essas conversas? Aproveitando o princípio de encurtar ciclos de feedback que ela aprendeu na Thoughtworks, ela propõe mover cada benefício para mais perto da decisão:

• Explorar alternativas: discutir antes de implementar, não depois.
• Transferência de conhecimento e formação de juniores: pairing, trabalhando junto enquanto o problema é resolvido, ou sessões coletivas de design antes de escrever (ou instruir o agente a escrever) qualquer código.
• Propriedade coletiva: times que constroem e operam software coletivamente, via pairing, mob programming ou sessões de design, em vez de depender do pull request para saber o que o outro já fez.
• Alinhamento arquitetural: desenhar junto e codificar as restrições importantes como fitness functions.
• Formatação, linting, problemas de segurança conhecidos e verificações determinísticas: automatizar.

Práticas como programação em par, trunk-based development, testes automatizados, análise estática e varredura de segurança movem o feedback para antes. Agentes podem participar desses ciclos, desafiando designs e testando premissas, mas o pensamento essencial vem de humanos experientes.

Revisão por exceção

Isso não elimina a revisão humana: mudanças arquiteturais fundamentais, alterações cruzando fronteiras sensíveis de segurança, grande raio de impacto, áreas críticas desconhecidas ou situações em que o time não está confiante justificam outro par de olhos experiente. O que ela rejeita é a exigência de inspecionar cada mudança como cerimônia histórica de geração de confiança. Se um agente produz dez vezes mais código e tudo fica na fila por um sênior, o resultado não é uma organização dez vezes maior, e sim um gargalo novo. E a resposta não é um agente de IA fingindo ser o revisor humano para preservar o processo mais rápido: isso automatiza a cerimônia sem questionar sua existência.

Dívida cognitiva e conclusão

Laycock reconhece como real a preocupação de Houck com a dívida cognitiva e de intenção: o software cresce enquanto as pessoas entendem cada vez menos por que ele funciona daquela forma. Mas ela não vê pull requests obrigatórios como defesa forte contra isso. Se agentes produzirão boa parte da implementação, é preciso manter deliberadamente o entendimento humano por design colaborativo, pairing, boas fronteiras, arquitetura executável e responsabilidade operacional compartilhada - "precisamos de engenheiros que entendam sistemas, não diffs".

A conclusão: a IA está expondo que anos de responsabilidades (gate de qualidade, checagem de segurança, revisão de arquitetura, mentoria, compartilhamento de conhecimento, modelo de propriedade) foram acumulados sobre a revisão de código. Isso funcionou, de forma imperfeita, enquanto humanos produziam código devagar. Com essa restrição desaparecendo, a pergunta talvez não seja como revisar mais rápido, e sim por que se espera até a revisão para ter as conversas importantes.