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
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.

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.
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.

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.
Não dá para responder isso no abstrato, então vão as perguntas que eu faria antes de aprovar o desenho:
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.
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.
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.
7 min de leitura
Conteúdos do Artigo: