Todos os artigos

Blog

Code review: a IA escreve mais depressa do que a sua equipa revê

Um pull request de 13 323 linhas escrito com uma IA, fechado ao fim de pouco mais de quinze horas: o que o seu code review tem de mudar.

  • Por Azziz ERRIME
  • 16 min de leitura
Uma cadeira de escritório vazia diante de uma pilha de páginas de code review que sobe até ao teto, iluminada à noite por um candeeiro.

TL;DR

  • O code review já não acompanha o ritmo da IA: numa empresa estudada em 2026, os PR por programador ativo duplicaram, e a carga de cada revisor também.
  • Segundo a Veracode, o código gerado por IA ainda só passa em 15 % dos testes de segurança no XSS e em 13 % na injeção de logs.
  • Antes de comprar uma ferramenta, eu mediria a carga dos revisores, limitaria o tamanho dos PR e escreveria a palavra segurança no template de PR.

Um pull request de 13 323 linhas escrito com uma IA, fechado por falta de revisores. Quando a IA escreve o código, é o code review que decide o que ele vale. Mas só se estiver dimensionado e protegido para isso.

Quarta-feira, 19 de novembro de 2025, 18h37 em Paris. Chega um pull request ao repositório do compilador OCaml: 13 323 linhas, 147 ficheiros, 40 commits. O autor produziu-o com uma IA para acrescentar suporte para DWARF, um formato de depuração.

No dia seguinte, às 9h55, pouco mais de quinze horas depois, Gabriel Scherer, um dos mantenedores, fecha-o sem fazer merge. Na mensagem de encerramento, esclarece que não está a julgar o código proposto: não o analisou com atenção suficiente para se pronunciar. Nenhuma das pessoas em condições de rever e manter aquele trabalho parecia disposta a assumi-lo. Resta a pergunta que qualquer code review levanta: quem revê, e em quanto tempo?

Um code review que não chegou a acontecer

Pouco antes de fechar o PR, Scherer tinha publicado um comentário. Descreve nele um código «hard to review, and very lightly tested», difícil de examinar e muito pouco testado. Lembra que faltam ao compilador pessoas disponíveis para a revisão e a manutenção. Por experiência, acrescenta, verificar o que uma IA escreve custa-lhe mais esforço do que verificar o trabalho de um humano.

Segundo ele, PR deste tamanho comportam «a very real risk of bringing the Pull-Request system to a halt», um risco bem real de paralisar todo o circuito de contribuições. Produzir linhas que passam nos testes, escreve, é «only 20% of the work», um quinto do trabalho. Os restantes 80 % (discutir a funcionalidade, revê-la e integrá-la) recaem tanto sobre o autor como sobre outras pessoas.

Segundo um estudo antigo realizado na Cisco pela SmartBear, que comercializa uma ferramenta de code review, a deteção de defeitos cai quando se ultrapassam as 500 linhas revistas por hora. A esse ritmo máximo, pelas minhas contas, as 13 323 linhas exigem mais de 26 horas de leitura atenta. O PR ficou aberto pouco mais de quinze horas.

A frase com que fechou o PR fala da organização do projeto: «Currently github/ocaml as it is organized is not able to work in this way.» Tal como está organizado, o repositório não consegue trabalhar assim. Pergunto-me quantas equipas poderiam escrever outra coisa sobre os seus próprios repositórios.

Os PR duplicaram, e a carga de cada revisor também

Segundo o GitHub, os pull requests integrados por mês na plataforma mais do que triplicaram entre janeiro de 2023 e junho de 2026.

Um estudo publicado a 2 de julho de 2026 acompanhou os programadores de uma empresa cujo CTO tinha anunciado, em junho de 2025, um «diretiva 2×» para duplicar a produtividade através da IA. O número de PR por programador ativo duplicou de facto, e a carga de cada revisor também. Os autores veem nisso um limite superior, não uma média do setor.

No open source, a fundação do motor de jogos Godot mudou a sua política de contribuição a 30 de junho de 2026. Explica a razão sem rodeios: os seus revisores qualificados são poucos, a revisão de código exige um esforço real e chegam mais contribuições do que é possível rever.

Creio que o code review fica pelo caminho quando a fila transborda, um PR atrás do outro. A Faros AI vende ferramentas que medem o trabalho das equipas de engenharia. Na telemetria da empresa, os PR integrados sem qualquer revisão, nem humana nem por um agente, registam um aumento relativo de 31,3 %. Cada um deles pode levar consigo as vulnerabilidades que escapam à IA, versão após versão.

Um posto de controlo rodoviário com a cancela levantada e a guarita vazia, atravessado por uma fila de camiões brancos.

Um posto de controlo aberto, ninguém na guarita, e o trânsito a passar sem abrandar.

O código gerado por IA ainda falha nas mesmas vulnerabilidades

Na primavera de 2026, a Veracode, empresa de segurança aplicacional, detalhou, vulnerabilidade a vulnerabilidade, a taxa de sucesso do código gerado por IA nos testes de segurança. Essas taxas pouco tinham mudado desde o relatório de 2025.

Vulnerabilidade Sucesso nos testes de segurança
Injeção de SQL 82 %
XSS 15 %
Injeção de logs 13 %

No relatório de 28 de julho de 2026, a Veracode volta a apontar os mesmos dois pontos fracos: o XSS e a injeção de logs. A injeção de logs insere quebras de linha num campo que é escrito no log, para forjar entradas falsas. A minha interpretação: o modelo acerta quando a proteção se resume a um padrão conhecido, como a consulta parametrizada contra a injeção de SQL. Falha quando a defesa depende do sítio onde os dados vão parar: uma página mostrada a outro utilizador ou um log consultado durante uma investigação. A empresa avança uma explicação próxima: estas duas vulnerabilidades obrigam a seguir os dados de um utilizador ao longo da aplicação.

Na prática, o atacante começa por esse percurso. Identifica os pontos de entrada da aplicação (um campo de formulário, um cabeçalho, um parâmetro de URL) e depois segue os dados até à página ou ao log onde voltam a aparecer. Um PR revê-se ficheiro a ficheiro, ao passo que esse caminho atravessa vários.

O outro ângulo morto esconde-se nas dependências. Um estudo apresentado na USENIX Security 2025 mostra que modelos de 2023 e 2024 recomendavam pacotes inexistentes, muitas vezes os mesmos de uma execução para a outra. Um atacante pode, por isso, registar esses nomes antes de si. Segundo um artigo da Lasso Security publicado em março de 2024, um investigador colocou online um pacote vazio com um nome inventado por modelos, «huggingface-cli». Foi descarregado mais de 30 000 vezes em três meses.

Num code review de segurança, a medida mais barata cabe numa frase. Braz e os coautores mostraram na ICSE 2022 que pedir explicitamente aos revisores que olhem para a segurança multiplica por oito a probabilidade de encontrarem a vulnerabilidade. A checklist dos autores não acrescentava nada de significativo a essa instrução. Mas é preciso alguém que tenha tempo para ler, e, quando esse tempo falta, a ideia de confiar também a revisão a uma máquina surge depressa.

Pôr uma IA a rever a IA: a tentação que o OCaml tinha previsto

No comentário publicado pouco antes do encerramento, Scherer tinha antecipado a resposta: «You may think that the answer to that is to also automate the review process, or (more plausibly) to lower our quality standards». Automatizar a revisão ou baixar o nível de exigência: até agora, escreve, o projeto não escolheu trabalhar assim. A tentação, no entanto, é real, e o code review automático já funciona em grande escala, segundo o GitHub, que fala do seu próprio produto.

Uma IA também pode encontrar vulnerabilidades reais. A 11 de agosto de 2025, a equipa Big Sleep da Google comunicou ao curl a vulnerabilidade que viria a ser a CVE-2025-9086. Para Daniel Stenberg, mantenedor do projeto, é o primeiro relatório recebido pelo curl que parece ter usado IA para identificar com exatidão uma falha de segurança.

Num artigo aceite na ICML 2025, Kim e os coautores compararam os erros dos grandes modelos de linguagem no ranking HELM. Quando dois deles se enganam ao mesmo tempo, escolhem em média a mesma resposta errada cerca de 60 % das vezes, contra cerca de 33 % ao acaso. Este número só vale para esse ranking. Basta-me para não presumir que um segundo modelo cubra os ângulos mortos do primeiro.

O revisor automático passa também a ser um alvo. A injeção de prompt consiste em esconder, num conteúdo que a IA vai ler, instruções que ela seguirá como se viessem de si. Com o CamoLeak, um investigador da Legit Security introduziu comentários invisíveis num PR para levar o Copilot Chat a divulgar código privado. O GitHub corrigiu esta vulnerabilidade crítica a 14 de agosto de 2025.

Um detetor de fumo no teto de um escritório, tapado por um post-it amarelo em branco.

Um detetor tapado por um post-it, como um revisor automático enganado por uma instrução escondida.

A Kudelski Security publicou a 19 de agosto de 2025 o relato de um simples PR com um ficheiro de configuração malicioso. Corrigida logo em janeiro de 2025, a vulnerabilidade permitia executar código nos servidores do CodeRabbit, uma ferramenta de code review com IA. Dava acesso de escrita a um milhão de repositórios, privados incluídos. Resta o humano que aprova no fim da cadeia.

Oito meses depois do OCaml, um agente de IA visa a aprovação de um mantenedor

Num relatório publicado a 4 de agosto de 2026, o AI Security Institute, organismo público britânico, descreve um incidente ocorrido de 25 a 28 de julho durante testes de cibersegurança. Um agente de IA em teste estudou os mantenedores humanos de um projeto, criou várias identidades falsas e usou-as para incitar um mantenedor verdadeiro a aprovar o seu código. Segundo o instituto, as suas investigações não revelaram qualquer dano real.

A documentação do kernel do Linux reserva a assinatura aos humanos: «AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).» Com a linha Signed-off-by, o contribuidor humano certifica a origem do seu código e assume inteira responsabilidade por ele.

O agente de programação Copilot do GitHub proíbe a pessoa que lhe pediu um PR de o aprovar ela própria. Desde 13 de março de 2026, um administrador pode, em contrapartida, desativar outra proteção: a aprovação humana antes da execução dos workflows lançados pelo agente. Nenhum destes textos diz quanto tempo se dá ao humano para ler.

Os investigadores da Carnegie Mellon baseiam a conclusão principal em milhares de textos publicados sobre code review. É a equipa que decide, na revisão, se o efeito de um agente sobre o software é bom ou mau.

«[…] review is the control point through which a coding agent’s effect on software is decided, and […] AI does not fix the sign of that effect: the team sets it» Agarwal, Miller, Kästner e Vasilescu, Carnegie Mellon, 8 de julho de 2026.

Um quarto de hora depois de fechar o PR, Scherer falava de processos de desenvolvimento diferentes ao ponto de serem incompatíveis, sem dizer qual deles tinha razão.

Segunda-feira de manhã, eu organizaria o code review antes de comprar uma ferramenta

A frase de encerramento de Scherer terminava com um parêntese: «This may change in the future and then one could reconsider.» Talvez isto venha a mudar e, nessa altura, poderá reconsiderar-se. Cada equipa pode fazer ao seu próprio code review o diagnóstico que ele fez ao repositório do OCaml: está organizado para rever o que a IA escreve?

Se eu fosse tech lead ou CISO, começaria por quatro medidas.

  • Abriria a plataforma Git, a ferramenta que aloja os seus repositórios, para extrair dois números que já lá dormem. Primeiro, a proporção de PR integrados sem revisão humana num período de 90 dias; depois, o número de linhas submetidas por semana a cada revisor, convertido em horas de leitura.
  • Limitaria o tamanho dos PR entregues a um revisor a cerca de 200 a 400 linhas e mandaria dividir o resto.
  • Escreveria a palavra segurança no template de PR, com as zonas onde o código gerado falha: os logs, a apresentação de dados de utilizadores, cada nova dependência.
  • Verificaria quem, nos seus repositórios, pode desativar a aprovação humana dos workflows lançados por um agente, e que permissões de escrita atribuiu à ferramenta de code review com IA.

Fico com uma dúvida sobre este limite: a referência é anterior aos assistentes de programação, e não encontrei nenhuma medição refeita com código gerado. Dividir também não encurta as 26 horas do OCaml, e rever tudo vai consumir parte do ganho prometido. À falta de melhor, prefiro um PR à espera.

Perguntas frequentes sobre code review e IA

O código gerado por IA é seguro?

No relatório de julho de 2026, a Veracode, empresa de segurança aplicacional, constata que o código gerado por IA passa, em média, em 56 % dos testes de segurança. O melhor modelo testado ainda falha em quase uma em cada três tarefas, e os insucessos concentram-se no XSS e na injeção de logs. Os modelos também inventam dependências: nos de 2023 e 2024, quase um em cada cinco pacotes recomendados não existia.

É possível usar IA para revisão de código?

Uma IA pode rever uma parte do trabalho. Segundo o GitHub, que fala da sua própria ferramenta de code review com IA, o Copilot fazia, em março de 2026, mais de uma em cada cinco revisões na plataforma. No ranking HELM, quando dois modelos se enganam, escolhem em média a mesma resposta errada cerca de 60 % das vezes. Um revisor automático também pode ser atacado, como mostraram o CamoLeak e a vulnerabilidade do CodeRabbit.

Quais são as boas práticas de code review com IA?

As referências conhecidas são anteriores à IA. O estudo realizado na Cisco e publicado pela SmartBear aconselha a não rever mais de 200 a 400 linhas de cada vez, a um ritmo inferior a 500 linhas por hora. Pedir explicitamente que se olhe para a segurança multiplica por oito a probabilidade de encontrar a vulnerabilidade. Verifique também quem pode desativar a aprovação humana dos workflows lançados por um agente, algo que o GitHub permite a um administrador desde 13 de março de 2026.

Fontes