#desenvolvimento-de-software
#fundadores
Opinião

Revisão de código com IA: até onde dá para tirar o humano do pull request

Revisão de código com IA aprova bem o que uma regra verifica. O que muda comportamento de negócio segue com gente. Onde cortar, o que vai pro contrato e a conta do mês 14.

Por Victhor Araújo

Fundador da Revin. Engenheiro de formação, especialista em desenvolvimento de software e produtos digitais.

A revisão automática aprova a forma do código, não a intenção por trás dele

A revisão automática aprova a forma do código, não a intenção por trás dele

Revisão de código com IA já faz bem a parte chata: padrão de projeto quebrado, função duplicada, chamada sem tratamento de erro, dependência nova que entrou de carona, teste que roda e não verifica nada. Nesse pedaço o agente ganha do humano cansado na décima quarta aprovação do dia, e ainda revisa às duas da manhã sem reclamar. O que ele não faz é dizer por que aquele arquivo existe, qual cliente pediu a exceção que mora na linha 212 e o que quebra na operação de segunda se a regra mudar.

Se você está desenhando esse fluxo agora, o corte prático é esse: o agente aprova o que uma regra consegue verificar, e uma pessoa aprova o que muda comportamento de negócio, acesso a dado de cliente ou obrigação com terceiro. Dá para tirar o humano dos dois lados. Só que a conta dessa decisão não chega no primeiro mês, chega lá pelo décimo quarto, quando alguém precisa explicar uma regra que ninguém escreveu e ninguém lembra.

A notícia é boa. A leitura que estão fazendo dela é que me preocupa

Quando a pergunta é por que a regra existe, alguém precisa ter estado na reunião

Quando a pergunta é por que a regra existe, alguém precisa ter estado na reunião

A Pragmatic Engineer publicou nesta semana que o 37signals, casa do criador do Ruby on Rails, passou a gerar quase todo o código por agentes, e que a aposta seguinte por lá é acabar com o code review. É um movimento sério, feito por gente séria, e eu acredito no resultado que eles relatam. No mesmo período, o Simon Willison escreveu que agentes deixam a engenharia mais difícil, não mais fácil, e o Will Larson publicou o experimento dele com o padrão de fábrica de software tocada por agentes. As três coisas são verdadeiras ao mesmo tempo, e só a primeira virou manchete.

O que raramente entra na leitura é a condição de contorno. O 37signals tem um time pequeno, sênior, que mantém os mesmos produtos há quase duas décadas, com rotatividade baixíssima e um fundador que ainda lê código. Quando o revisor humano sai de lá, o conhecimento dele continua no prédio. Quando o revisor humano sai da sua empresa, ele costuma sair da sua empresa.

Quem é o 37signals dentro do seu contrato

Faça a conta antes de copiar o modelo. Quantas pessoas no time atual estavam lá quando o módulo de cobrança foi escrito? Se a resposta for nenhuma, você não tem o contexto que sustenta a decisão deles, tem o oposto: um sistema onde o código é a única fonte de verdade e ninguém consegue explicar a intenção por trás dele.

É o cenário que mais aparece nos resgates que chegam aqui. Sistema na casa dos milhares de linhas, três donos anteriores, e o arquivo mais mexido do repositório com um histórico que só diz "ajustes". A IA vai escrever em cima disso com uma velocidade que o time anterior nunca teve. Também vai herdar os mesmos pontos cegos, porque ela lê o que está escrito e não sabe o que foi combinado em reunião.

Esse é o mecanismo pelo qual a dívida técnica de software feita por agente de IA sai barata agora e cara depois. Não é a IA que cria a dívida. É a ausência de alguém que responda pela decisão que ela tomou.

"Mas o agente acha bug que o humano deixa passar"

Em obra, a assinatura da responsabilidade técnica continua sendo de uma pessoa física

Em obra, a assinatura da responsabilidade técnica continua sendo de uma pessoa física

Acha mesmo. E eu uso. O agente pega condição de corrida que passa batido, tratamento de erro que engole exceção, consulta dentro de laço, importação que ninguém usa mais. Isso é ganho real, e quem não está usando está pagando caro por uma revisão pior.

O problema aparece quando quem gerou e quem revisa são a mesma classe de ferramenta. Dois modelos com o mesmo treino tendem a concordar exatamente onde erram juntos. Já vi o padrão em auditoria: cobertura de testes bonita, sem um único expect que valide comportamento, e um endpoint de saúde devolvendo 200 fixo enquanto o banco estava fora. Os dois passam em qualquer revisão automática, porque a forma está impecável. É casca podre com selo de qualidade.

Um humano experiente também deixaria passar? Talvez. A diferença é que existe alguém a quem perguntar, e essa pessoa responde. Ferramenta não responde por nada, e no dia da auditoria ela não senta na sala. Vale a mesma lógica de quando o código passa no pitch e reprova na due diligence: o que quebra o negócio quase nunca é o defeito que a régua automática mede.

Três perguntas antes de tirar a pessoa do fluxo

Não dá para responder isso no abstrato, então vão as perguntas que eu faria antes de aprovar o desenho:

  1. Se esse pull request causar uma multa de proteção de dados daqui a oito meses, quem da sua empresa senta na reunião com o jurídico e explica por que a regra ficou assim? Se o nome que vier à cabeça for o de uma ferramenta, o desenho está errado.
  2. Quando a regra de negócio mudar, alguém consegue achar em menos de meia hora onde ela está implementada e por quê? A resposta honesta depende de haver rastro de decisão, não só de haver código.
  3. O que acontece com o fluxo no dia em que o fornecedor do agente muda o preço, o modelo ou a política de uso? Empresa que terceirizou geração e revisão para a mesma plataforma tem um ponto único de falha que não está em nenhum diagrama de arquitetura.

Eu passei anos como responsável técnico de montagem de estrutura metálica, e ali a lógica é seca: a máquina corta, a máquina solda, o ensaio mede, e ainda assim tem um nome de pessoa física na anotação de responsabilidade técnica. Ninguém nunca me deixou assinar com "o equipamento aprovou". Software vai chegar nesse ponto também, por caminho jurídico e não por caminho técnico.

O que muda no contrato, na prática

Quando a geração e a revisão viram automáticas, o que você está comprando de um fornecedor muda de natureza. Antes você comprava horas de gente que entende. Agora corre o risco de comprar throughput de máquina mais uma capa de processo. E throughput é fácil de demonstrar em demonstração de duas semanas.

Dois sinais que eu olharia em qualquer proposta que promete velocidade de agente. O primeiro é quem revisa o que a IA escreve e com que critério, escrito no contrato, com nome e senioridade. O segundo é o que acontece na saída: se o fornecedor sumir daqui a um ano, o que fica com você além do repositório. Escrevi mais sobre esse tipo de checagem nas perguntas que valem antes de assinar com quem vai desenvolver seu app, e elas não exigem que você leia uma linha de código.

O que a gente faz aqui é o contrário do combo geração automática mais aprovação automática: o agente entra como ferramenta do time, o pull request continua tendo dono com nome, e a decisão de arquitetura passa por quem vai manter aquilo no ano seguinte. Rende menos linha por dia. Rende mais sistema de pé no mês 14.

O sintoma que aparece antes da conta

Tem um indicador barato que eu recomendo medir desde já, e ele não tem nada a ver com qualidade de código. Meça quanto tempo o time leva para responder a uma pergunta de negócio sobre o próprio sistema. Do tipo: por que clientes do plano antigo não entram nessa promoção? Se há um ano a resposta vinha em dez minutos e hoje vem em dois dias, alguma coisa importante saiu do processo, mesmo que o painel de entrega esteja verde.

Esse atraso é primo do problema de o time entregar mais código e o produto não andar. A diferença é que aqui o que degradou foi a capacidade de explicar, e ela degrada em silêncio. Ninguém abre chamado para reclamar de conhecimento perdido.

Eu não sei dizer se isso vale igual para um time de três pessoas que escreveu tudo do zero nos últimos seis meses. Nesse cenário a cabeça de quem escreveu ainda é o backup, e talvez a revisão automática baste por um tempo. Já num sistema com cinco anos, várias mãos e uma modernização de legado pela frente, tirar o revisor humano é apagar a última pessoa que sabia por que aquilo estava daquele jeito.

Então a pergunta que eu levaria para a próxima reunião de tecnologia não é se a IA revisa bem. É esta: hoje, se o pull request de ontem derrubar o faturamento de amanhã, quem na sua empresa consegue explicar a decisão em uma frase? Escreva o nome. Se não houver nome, você ainda não automatizou revisão, só adiou a conversa.

Pronto para elevar o seu negócio?

Agendar uma reunião
Compartilhe
Link de compartilhamento LinkedinLink de compartilhamento XLink de compartilhamento WhatsappLink de compartilhamento Facebook

A cada quinze dias. As decisões técnicas que tomamos, e o que aprendemos.