O open source acelerou o código. O critério de revisão ficou parado.

Em 21 de outubro, o The Register publicou os resultados de uma pesquisa da Linux Foundation sobre o uso de inteligência artificial generativa em projetos de código aberto. Segundo os mantenedores ouvidos, a IA reduziu em média 52% o tempo de escrever código. Mas 25% dos pull requests recebidos são classificados como “AI slop”, lixo gerado por IA sem revisão prévia, proporção que sobe a 31% nos projetos grandes. Hilary Carter, vice-presidente de pesquisa da Linux Foundation, e Daniel Stenberg, mantenedor do projeto curl, comentaram os números ao veículo. Na mesma semana, o curl anunciou que vai tornar públicas falhas de segurança de severidade baixa e média, para aliviar uma equipe sobrecarregada por relatórios de vulnerabilidade assistidos por IA, cheios de falso positivo e duplicata.

A leitura mais fácil é que o open source atravessa uma dor de crescimento passageira. Novato mal orientado usa IA para gerar contribuição malfeita, falta documentação, falta um selo de “revisado por humano” para separar contribuição séria de spam. Sob essa leitura, o problema se resolve educando quem contribui: a próxima geração aprende a usar a ferramenta com mais cuidado, e a fila volta ao tamanho de sempre.

O que a pesquisa mediu, e o que ela não mediu

Os próprios números desmontam essa leitura. A IA não deixou o contribuidor mais cuidadoso: deixou mais rápido. Cortar à metade o tempo de escrever código é ganho puro de ferramenta, a mesma coisa de sempre, só que mais veloz. Nada nesse ganho decide o que vale a pena submeter, e é essa distância que esta publicação aplica a todo anúncio de produtividade: velocidade sem critério não aumenta qualidade, aumenta volume. Setenta e um por cento dos mantenedores confirmam que a barreira de entrada caiu; nenhum número equivalente mostra uma queda no que precisa ser revisado antes de entrar. O resultado é aritmético, não moral: quando cai o custo de produzir e nada muda no custo de decidir se aquilo merece atenção, a fila cresce mais rápido do que a capacidade de esvaziá-la.

A fila cresce na velocidade que a ferramenta permite, não na velocidade que alguém decide o que fazer com ela.

Esta publicação já mostrou como a vigilância que quebra pelo volume, não pela gravidade do pedido se repete aqui sob outra fachada: a queda de qualidade não está concentrada num contribuidor malicioso isolado, está distribuída pelo volume. Stenberg descreve o efeito em primeira mão: toda a equipe principal do curl diz sentir-se sobrecarregada, no limite do que consegue sustentar.

O gargalo não é quem contribui mal. É que ninguém decidiu, antes do pull request chegar, o que merece passar pelos olhos de um mantenedor.

A leitura óbvia	O que a pesquisa mostra
Falta orientar quem contribui	A barreira caiu para 71% dos mantenedores; o critério de revisão não mudou
É dor de crescimento passageira	32% dos projetos não têm política de uso de IA nem planejam criar uma
O problema é o volume de gente nova	O curl decidiu parar de revisar vulnerabilidade de baixa severidade, não contratar mais revisor

O critério que falta é o que decide antes de chegar

Para quem dirige uma empresa que também recebe cada vez mais entrada gerada por IA (proposta de fornecedor, currículo pré-triado, relatório interno, pull request do próprio time), o paralelo é direto. A saída que o curl escolheu aponta o caminho: em vez de pedir a mais gente para revisar mais rápido, o projeto decidiu, publicamente, que relatório de vulnerabilidade de severidade baixa e média deixa de consumir o tempo da equipe de segurança. Vira informação pública, sem triagem individual. É uma decisão de critério, tomada antes do relatório chegar, não um ajuste na velocidade de quem revisa depois que ele já chegou. Qualquer operação que sinta a caixa de entrada de IA crescer mais rápido do que a equipe consegue decidir enfrenta a mesma escolha: definir, por escrito, o que não precisa de olho humano antes de contratar mais um revisor.

Devolver a responsabilidade a quem gerou

Carter aponta o outro lado da mesma moeda: atribuir ao contribuidor, e não a quem recebe, a responsabilidade por testar o que a IA gerou e declarar que usou IA para gerar. Transplantada para dentro de uma empresa, a mesma régua vale: quem usa IA para produzir um relatório, uma proposta ou um trecho de código carrega a obrigação de evidenciar que revisou antes de submeter. O ganho de velocidade fica onde foi gerado, e o custo da falta de critério deixa de cair, por padrão, sobre quem recebe.

A publicação já tratou do mesmo vazio em outro contexto: o mesmo vazio, ali em forma de orçamento sem dono. Aqui ele reaparece sob outro nome. Trinta e dois por cento dos projetos pesquisados não têm política de uso de IA nem planejam criar uma. Sem alguém nomeado para decidir e atualizar esse critério, a fila de entrada cresce exatamente na velocidade que a ferramenta permite, e nenhum reforço de equipe alcança.

Quantos dos pedidos gerados por IA que chegam à sua operação, pull request, proposta, relatório, já passaram por algum critério antes de consumir o tempo de alguém, e quantos chegam direto para que uma pessoa decida, um a um, se aquilo merece atenção?