Talvez não valha revisar tanto código na era da IA

A CTO da Thoughtworks, Rachel Laycock, participou de um painel com Brian Houck, da DX, no Code Remix, organizado pela Moderne, e discordou dele sobre revisão de código na era da IA. Brian defendeu que a revisão de código tem outras funções além de encontrar bugs. Laycock respondeu que talvez o problema não seja a IA ter quebrado a revisão de código, mas o fato de usarmos a revisão para resolver os problemas errados.

O aumento de código e o risco de perder funções

Brian cita números: no Meta, linhas significativas de código por diff enviado por humano teriam crescido 106% em um ano; dados da DX mostrariam aumento de 64% na mediana do tamanho de pull requests. A preocupação dele, compartilhada por Laycock, é que automatizar a revisão de código pode eliminar outras funções: compartilhar conhecimento, ensinar engenheiros juniores, construir propriedade coletiva e disseminar entendimento arquitetural. A pergunta dela é por que esperar até a revisão de código para fazer tudo isso. Ela nunca gostou de pull requests como centro do processo: não por achar que engenheiros não devam olhar o código uns dos outros, mas por questionar a ideia de construir, terminar, empacotar, jogar para outra pessoa e só então ter a conversa importante sobre se a coisa certa foi feita do jeito certo. Merge conflicts também consomem tempo.

Deslocar o julgamento para a esquerda

Um princípio aprendido cedo na Thoughtworks é encurtar ciclos de feedback: se o feedback é valioso, não remova; mova-o para perto da decisão que ele informa. Para explorar soluções alternativas, melhor fazer isso antes de implementar uma delas. Para transferência de conhecimento, pareamento: sentar ao lado, física ou virtualmente, enquanto a pessoa raciocina ensina mais do que ler a solução pronta depois. Para juniores aprenderem como engenheiros experientes pensam, eles devem trabalhar com esses engenheiros enquanto pensam; pareamento e sessões de design coletivas no quadro branco antes de escrever ou instruir o agente a escrever. Para propriedade coletiva, organizar times que construam e operem software coletivamente, com pareamento, programação em grupo ou design em equipe. Para alinhamento arquitetural, desenhar em conjunto e codificar restrições importantes como fitness functions. Formatação, lint, problemas de segurança conhecidos e testes determinísticos devem ser automatizados.

Práticas como programação em par, trunk-based development, testes automatizados, análise estática, fitness functions e varredura de segurança movem o feedback para mais cedo. Agentes podem participar desses ciclos, questionando designs, testando premissas e verificando continuamente o que está sendo construído, mas o pensamento real vem de humanos experientes. Para que essa experiência beneficie o time inteiro, é preciso agir como time muito antes da revisão de código.

Revisão por exceção

Isso não significa que ninguém nunca deva revisar código. Laycock quer outro humano experiente olhando mudanças como alteração arquitetural fundamental, algo que cruza fronteira sensível de segurança, mudança com grande raio de impacto, parte desconhecida de sistema crítico ou algo sobre o qual o time diga não ter confiança. São lugares em que o julgamento humano é valioso. Diferente de exigir inspeção humana de toda mudança porque essa é a cerimônia historicamente usada para criar confiança. Se um agente pode produzir dez vezes mais código, mas cada linha acaba na fila esperando um engenheiro sênior, não se criou uma organização de engenharia dez vezes melhor, e sim um grande backlog e um novo gargalo. A resposta não é um agente de IA fingindo ser o revisor humano para preservar o mesmo processo em maior velocidade; isso seria automatizar a cerimônia em vez de questionar por que ela existe.

Dívida cognitiva e de intenção

Laycock vê como real a preocupação de Brian com dívida cognitiva e de intenção: o software cresce enquanto os humanos responsáveis entendem cada vez menos por que ele funciona daquela forma. Mas não acha que pull requests obrigatórios sejam uma defesa forte contra isso. Se agentes vão produzir substancialmente mais implementação, é preciso ser muito mais deliberado em manter o entendimento humano por meio de design colaborativo, pareamento, boas fronteiras, arquitetura executável, responsabilidade operacional compartilhada e, provavelmente, práticas que ainda não foram inventadas. Engenheiros precisam entender sistemas, não diffs. A IA talvez esteja expondo anos de responsabilidades acumuladas sobre a revisão de código: portão de qualidade, checagem de segurança, revisão arquitetural, mentoria, compartilhamento de conhecimento e modelo de propriedade. Isso funcionou, mais ou menos, enquanto humanos só conseguiam produzir código a certa velocidade. Essa restrição está desaparecendo. Talvez a pergunta não seja como revisar o código mais rápido, mas por que esperamos até a revisão de código para ter todas as conversas importantes.