Quando a IA escreve o código: por que o code review vira a disciplina central // nh labs

A habilidade que importou por décadas

Pergunte a uma engenheira experiente no que ela é boa, e a resposta quase sempre gira em torno de escrever: construir uma função complicada com elegância, traduzir um problema em código limpo, escolher o padrão certo na hora certa. Produzir código era a habilidade escassa, bem paga, admirada. Ler código – passar pelos pull requests dos outros, conferir se aquilo se sustenta – era a obrigação que você encaixava entre o trabalho de verdade. Quase ninguém jamais se gabou de ser um bom revisor.

Essa proporção está virando agora. Quando um modelo escreve a maior parte do código novo – e em muitos times ele já escreve –, a produção deixa de ser o gargalo. O código chega mais rápido, mais barato e em volumes maiores do que um humano jamais escreveria à mão. O gargalo se desloca para o único ponto que nenhum modelo tira das suas mãos: entender se o código está certo e assumir as consequências quando ele vai para produção.

A habilidade de engenharia decisiva dos próximos anos, portanto, não é escrever código. É ler o código alheio – com rapidez, ceticismo e rigor.

A inversão

Por décadas vigorou uma suposição silenciosa: escrever é difícil, ler é fácil. Projetar uma função que resolve um problema era a parte exigente e criativa. Lê-la e aprová-la era rotina – uma rede de segurança, não o ato principal. É justamente por isso que o review era o enteado mal-amado na maioria dos times: com orçamento curto, feito às pressas, raramente levado a sério.

A IA inverte essa proporção com precisão. Escrever – traduzir uma intenção clara em código que funciona – é exatamente o tipo de trabalho em que os modelos brilham. É ofício bem delimitado, presente um milhão de vezes nos dados de treinamento. O que um modelo não fornece é discernimento: a capacidade de julgar se aquele código faz a coisa certa naquele sistema, com aqueles dados, sob aquela carga – e se alguém consegue responder pelas consequências quando ele entra no ar.

A escassez mudou de lugar. A geração ficou barata; a compreensão continuou cara. E compreensão não se delega: é justamente a atividade que o humano precisa assumir, porque é o ponto em que "o código roda" vira "a gente entende o que ele faz e responde por isso". O review costumava ser o fim da pipeline. Agora é o fundo do funil por onde tudo precisa passar.

Por que o código de IA é especialmente traiçoeiro de revisar

Os humanos sempre revisaram código com uma única heurística altamente eficiente: parece razoável → provavelmente está ok. Esse atalho funciona porque código humano ruim costuma também parecer ruim. Lógica embolada, nomes de variável toscos, um comentário do tipo "TODO: isso é uma gambiarra" – a superfície entrega a fraqueza. Você lê as primeiras linhas, sente o cheiro e olha com mais atenção.

O código de IA destrói essa heurística. Ele é plausível. Compila. Lê-se com limpeza. Os nomes de variável são sensatos, a estrutura é convencional, os comentários são educados. Parece o trabalho de um colega competente e descansado – e, ainda assim, está confiantemente errado de formas sutis:

um edge case que nunca é tratado – a lista vazia, o valor negativo, o fuso horário bem na virada do dia
uma chamada de API inventada: um método que soa tão plausível que você toma por real, até ele não existir em tempo de execução
uma falha de segurança silenciosa – entrada do usuário jogada sem sanitização numa query, um segredo no log, uma verificação de autorização que esquece exatamente um caminho
uma premissa que não se sustenta: que a resposta vem ordenada, que o campo nunca é nulo, que a operação é idempotente

No código humano, aparência e correção andam mais ou menos juntas. No código de IA elas estão desacopladas. O modelo otimiza para plausibilidade – para código que parece correto –, e isso não é a mesma coisa que correção. É exatamente por isso que o código de IA é mais perigoso de revisar do que o de um júnior inseguro: com o júnior, a superfície tosca te avisa. Com o modelo, a superfície lisa te embala no sono.

O novo modo de falha se chama carimbar sem ler

Existe um modo de falha que quase ninguém vê chegar, porque ele não parece falha. Parece produtividade.

A mecânica é simples e brutal. O volume sobe: onde antes dois pull requests por dia passavam pelo review, agora são dez. O tempo por review fica igual ou encolhe, porque a pressão para entregar aumentou. Então a atenção por linha cai. "Eu entendo o que esse código faz" vira, sem alarde, "parece plausível, passa nos testes, aprovado". Isso é rubber-stamping – o carimbo automático em que o sinal verde perdeu o significado que um dia teve.

O traiçoeiro é que, de fora, isso parece idêntico a um review que funciona. Os mesmos pull requests, as mesmas aprovações, o mesmo CI verde. Só que ninguém mais está realmente olhando. O time entrega mais e entende menos. Cada PR carimbado sem leitura acrescenta ao sistema um pouco de código que nenhum humano jamais teve por inteiro na cabeça – e essa é a forma mais cara de dívida técnica que existe: não código que parece ruim, mas código que ninguém entendeu e que, por isso, ninguém consegue alterar com segurança.

Essa dívida rende juros. O primeiro bug carimbado é barato. O décimo está sobre um alicerce de outras nove premissas nunca examinadas, e ninguém sabe quais ainda valem. Quando um time acorda nesse estágio, a pergunta honesta raramente é "onde está o bug?", e sim "será que a gente ainda entende o próprio sistema?".

Como é um bom review hoje

Quando escrever fica barato, ler precisa ficar mais exigente. Um bom review na era da IA não confere mais sintaxe e estilo em primeiro lugar – disso cuidam os linters e o próprio modelo. Ele confere as coisas que um modelo tem mais chance estrutural de errar e que um humano apressado tem mais chance de não ver:

Intenção antes da implementação. A primeira pergunta não é "esse código está correto?", e sim "ele resolve o problema certo?". O código pode estar impecável e ainda assim fazer a coisa errada, porque o modelo entendeu a tarefa de forma plausível, mas equivocada.
Arquitetura, não a linha. Essa mudança se encaixa na estrutura do sistema, ou contrabandeia um segundo padrão concorrente? Modelos constroem o que é localmente sensato e globalmente inconsistente.
As bordas. A entrada vazia, o valor de fronteira, o acesso concorrente, o timeout. Justamente os casos que nunca aparecem no caminho feliz – e os que o modelo tem mais chance de ter pulado.
Os caminhos de erro. O que acontece quando a chamada falha, o banco cai, a resposta chega pela metade? Código gerado descreve o sucesso com eloquência e a falha com buracos.
A superfície de segurança. Todo ponto em que entram dados do usuário, permissões, segredos ou dados externos. O modelo não tem noção de ameaça; isso tem de vir do humano.

E acima de tudo isso há uma regra cultural que não pode ser negociável: quem submete código de IA é dono de cada linha dele. Não "foi a IA que escreveu assim" – e sim: você submeteu, então você consegue explicar por que está desse jeito e não de outro, o que ele faz com a entrada vazia e por que você confia naquela chamada de API. Se quem submete não consegue, o pull request não está pronto, por mais verde que brilhem os testes. O modelo digitou o código; a responsabilidade não se digita junto.

"A IA não pode revisar a IA?"

A objeção óbvia: se ler é o novo gargalo, por que não deixar um modelo revisar o código de outro modelo e encerrar o assunto?

Como primeira camada, isso até faz sentido. Um revisor de IA pega o óbvio: casos de erro não tratados, testes faltando, padrões de segurança conhecidos, quebras de estilo. Como linting automatizado turbinado, ele tem valor, e tira o trabalho bruto das mãos do humano para que ele guarde a atenção para a parte difícil.

Mas isso não resolve o problema de verdade, por dois motivos. Primeiro, ele compartilha os pontos cegos. Os mesmos vieses de treinamento, a mesma inclinação a respostas plausíveis em vez de corretas, a mesma falta de noção do que pode quebrar neste negócio e do que não pode. Um modelo que não percebe uma premissa sutilmente errada também não a percebe no código de outro modelo – ele a aprova com a mesma serenidade. Segundo, e isso pesa mais: um review de IA fabrica falsa segurança. Um segundo sinal verde dá a sensação de mais certeza, mas é só a mesma aposta feita duas vezes. E, sobretudo, ele não transfere responsabilidade. Quando o sistema cai às três da manhã, ninguém pode se esconder atrás de "mas a IA revisora concordou". No fim da linha há um humano que responde pelo merge – e é exatamente essa parte que nenhuma automação consegue tirar.

Calibre o rigor pelo raio de explosão

Agora o outro lado honesto, antes que a lição seja esticada demais. Nem todo código merece o mesmo rigor – e revisar tudo com paranoia máxima é a sua própria forma de desperdício. Um script descartável que reformata um CSV uma vez não precisa de um review de segurança em três camadas. Um dashboard interno que cinco pessoas veem não é o fluxo de pagamento.

A variável certa não é "quanto código", e sim raio de explosão: o que acontece, no pior caso, se esse código estiver errado? É isso que determina o quão de perto você olha.

Qual o tamanho do estrago se quebrar? Lógica de pagamento, autenticação, migrações de dados, qualquer coisa que toque em dados de cliente ou dinheiro – rigor máximo, linha por linha. Uma ferramenta interna de apoio – review mais leve.
Quão reversível é? Um recurso atrás de uma flag que você desliga em segundos tolera mais velocidade do que uma migração que reescreve dados de forma irreversível.
Quão longe alcança? Uma função isolada, sem dependências, é inofensiva. Uma mudança num componente central, usado em vinte lugares, não é.
Vive muito tempo? Código que fica e cresce merece o cuidado que se poupa ao código descartável.

Raio de explosão alto significa: ler devagar, duvidar de cada premissa, fazer quem submeteu explicar cada linha. Raio de explosão baixo significa: carimbar e seguir está ok. A arte não é revisar tudo até o talo – é direcionar a atenção para onde um erro realmente dói. E para que isso continue possível, vale uma regra simples de higiene: mantenha os pull requests pequenos. Um humano lê 200 linhas com ceticismo de verdade. Em 2.000, ele entra no modo carimbo – que, como vimos, já não é review nenhum.

Conclusão

Por décadas, escrever código foi a habilidade que um engenheiro conquistava e pela qual era pago. Essa habilidade não ficou sem valor, mas deixou de ser escassa. O que é escasso agora é aquilo que por muito tempo foi tratado como mera formalidade: ler o código alheio com rapidez, ceticismo e rigor – e responder por ele.

Para os times, isso significa reconstruir uma disciplina que muitos negligenciaram por anos. O review precisa virar uma atividade de primeira classe, visivelmente valorizada, e não trabalho extra não remunerado espremido entre as tarefas de verdade. Daqui para frente, contrata-se e desenvolve-se não só gente que escreve com brilho, mas gente que lê com agudeza. A alavanca da engenheira experiente já não é a velocidade com que ela digita, e sim quão bem o seu julgamento e o seu bom gosto filtram uma enxurrada de código gerado.

É exatamente aqui que colocamos a régua na NH Labs. Usamos IA na engenharia porque ela é rápida e boa – mas não tratamos o review como um último passo opcional. Tratamos como a disciplina central por onde cada linha precisa passar. Um humano entende cada linha submetida, sabe explicá-la e responde pelo merge. É por isso que nossos clientes podem confiar no resultado: não porque uma IA o escreveu, mas porque um humano o leu.