AI-Generated Code Is Already Competing With Human Code
PRs escritos por agentes de IA já ficam na mesma faixa de qualidade dos humanos; o que muda é o tipo de erro e a forma de validar.
Em 3 frases
A Greptile analisou mais de um milhão de pull requests por mês e estima que cerca de um quarto tem sinais de autoria quase total de IA, contra menos de 1% um ano antes.
Em reversões, severidade dos problemas (P0, P1, P2) e rodadas de revisão, o código de agentes ficou na mesma faixa do humano, mas cada agente erra de um jeito, como mais SQL injection no Claude e mais N+1 queries no Cursor.
Com quem escreve centenas de PRs por mês, revisão manual não escala, e a empresa propõe validar com três perguntas sobre contrato com o usuário e intenção do autor, usando agentes que rodam o código em sandbox.
Antes de ler
- N+1 query consulta repetida ao banco em laço analogia abaixo
- Pull request pedido de integração de código
- Agente de código autônomo IA que recebe uma tarefa e abre o PR sozinha
- Revert reversão de um PR já mergeado
- Severidade P0/P1/P2 níveis de gravidade de um bug
- Rodada de revisão ciclo de comentar, corrigir e reenviar o PR
Como detectar código feito por agente
Marcar PR como feito por IA é difícil. O campo de autor do GitHub acusou menos de 1%, número que o palestrante achou baixo demais. Ele somou dois outros sinais, o rodapé de coautoria na descrição (co-authored by Claude ou Cursor) e o prefixo do nome da branch, como o Codex usa. Com isso chegou a cerca de 25% dos PRs do mês (min 3:48 a 4:19). É uma estimativa por indícios, sem certeza de autoria.
Taxa de reversão parecida entre humanos e agentes
O primeiro teste de qualidade foi a taxa de revert (PR desfeito depois de mergeado). O Codex teve cerca de 1 revert a cada 1.000 PRs, o Devin 3,5 e os humanos 2,5 (min 5:52). Para checar se os agentes só pegavam tarefas fáceis, ele cruzou com o tamanho do PR e achou pouca correlação (min 6:23). O talk conclui que falta evidência forte de que o humano seja melhor.
Severidade e rodadas de revisão sem grande diferença
O segundo teste contou os problemas que o próprio Greptile aponta, classificados em P0, P1 e P2 (do mais grave ao menos grave). Três dos quatro agentes testados geraram menos P0 que humanos (min 6:53). O terceiro teste contou rodadas de revisão até o merge, com Devin em 2,1 e Codex em 2,45 (min 7:56), e os humanos ficaram no meio dessa faixa.
Mais 2 ideias deste talk
Cada agente falha de um jeito
Ao buscar termos nos comentários do Greptile, o palestrante montou um gráfico de padrões de falha com 1x igual à taxa humana. O Claude aparece com 1,5x mais SQL injection que humanos e o Devin com metade dos problemas de bypass de autenticação (min 9:16 a 9:29). A descrição do vídeo cita ainda mais N+1 queries no Cursor. Escolher o agente passa a incluir escolher quais erros você aceita revisar.
Validação em escala e as três perguntas
O usuário mediano do Greptile abre 50 PRs por mês, o percentil 90 abre 500 e o percentil 99 chega aos milhares (min 10:01 a 10:32). Nesse ritmo, revisão manual e QA humano não acompanham. A proposta é validar com três perguntas. A mudança viola o contrato com o usuário? Aumenta a chance de violação futura? Cumpre a intenção do autor? (min 11:02).
N+1 query (consulta repetida ao banco em laço). Uma N+1 query é como um garçom que anota a mesa inteira, mas vai à cozinha buscar um prato por vez, fazendo dez viagens quando uma bandeja resolveria.
- Um programa guarda dados num banco de dados (database) e busca esses dados fazendo perguntas chamadas consultas (queries). Cada consulta é uma ida e volta que custa tempo.
- O problema aparece quando o código faz 1 consulta para pegar uma lista e depois faz mais 1 consulta para cada item dessa lista. Com N itens, o total vira N+1 consultas.
- Exemplo: mostrar 100 pedidos e buscar o cliente de cada pedido um por um gera 101 consultas, quando 2 bastariam.
- Com poucos dados de teste o atraso passa despercebido. Em produção, com milhares de linhas, a página fica lenta e o banco fica sobrecarregado.
- A correção junta as buscas num lote só, com um JOIN (junção de tabelas) ou com carregamento antecipado (eager loading) do ORM. O talk usou esse termo para medir padrões de erro por agente.
Ajuda saber antes: Banco de dados, Consulta SQL, Laço de repetição (loop), ORM
O talk é pitch da Greptile, que vende revisão por IA e mede qualidade usando os próprios comentários. Isso é circular, pois o revisor define o que conta como bug. A detecção de PRs de IA depende de rodapés e nomes de branch, e a taxa de revert fica em poucas unidades por mil, sem intervalo de confiança nem controle de tarefa. Não há dados de PRs que o cliente nunca abriu. Os clientes citados são grandes, mas o recorte é de quem já usa a ferramenta.
O que fazer com isso
- Se seu time usa agentes de código, marque PRs com rodapé de coautoria ou prefixo de branch para poder medir revert e retrabalho por origem.
- Ajuste a revisão ao agente usado. Peça atenção extra a SQL injection em código do Claude e a N+1 queries em código do Cursor, conforme os padrões citados.
- Antes de aceitar 'PR de IA é tão bom quanto o humano', compare com a sua própria taxa de revert e de rodadas de revisão, em vez de confiar no número de outra empresa.
- Ao definir sua checagem de merge, escreva as três perguntas (contrato, risco futuro, intenção) e use-as como checklist de revisão.