Relatórios de bug gerados por IA estão sobrecarregando a triagem do PostgreSQL

O que Christophe Pettus denunciou

Christophe Pettus, consultor de PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → na PGX Inc., escreveu no blog The Build (republicado na Planet PostgreSQL) que a lista de bug reports do projeto passou a receber "flurries" de 10 a 15 bugs de uma só vez, todos vindos do mesmo endereço de e-mail e claramente gerados por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. Ele mesmo pegou um desses lotes para triar e levou cerca de 90 minutos no trabalho, o que, segundo ele, é "umas 10 vezes mais tempo do que levou para a pessoa rodar a IA e colar o resultado no e-mail".

O resultado da triagem é o retrato do problema. Entre os itens analisados por Pettus estavam: um "bug" que era na verdade comportamento esperado (corrupção manual de dado gerando erro, que é exatamente o que deveria acontecer); pelo menos dois casos já em discussão na lista -hackers; uma duplicata de relato anterior da mesma pessoa; ao menos três problemas já corrigidos na versão 19; alguns diagnósticos equivocados mesmo havendo algum bug real; e um caso em que o diagnóstico estava correto, mas o patch sugerido pioraria o problema.

Nenhum desses relatos, segundo ele, passou por qualquer verificação humana antes de ser enviado. A pessoa rodou a IA, recebeu uma resposta confiante dizendo que havia um bug e já tinha o patch pronto, e simplesmente encaminhou tudo.

Por que isso importa para quem desenvolve com Postgres

O ponto central de Pettus não é contra IA como ferramenta. É sobre capacidade de triagem: o número de pessoas qualificadas para analisar bug reports do PostgreSQL é pequeno, e o tempo delas é escasso. Transferir para esse grupo reduzido o trabalho de descobrir se a IA acertou ou errou é, nas palavras dele, "no mínimo rude".

Há um efeito colateral pior ainda. Quem manda relatos de baixa qualidade de forma repetida ganha reputação de ruído, e seus próximos relatos tendem a ser ignorados, inclusive os eventualmente graves. Isso é especialmente sensível num projeto como o PostgreSQL, onde uma correção de segurança mal avaliada tem custo real para quem roda banco de dados em produção.

Relatórios de bugs gerados por IA injetados no pipeline sem intervenção humana são piores do que inúteis.

Christophe Pettus, consultor de PostgreSQL na PGX Inc.AI bug reports injected into the pipeline without human intervention are worse than useless.

Para quem desenvolve e depende do PostgreSQL, a consequência prática é dupla: o tempo dos mantenedores que poderia ir para revisar patches reais é consumido descartando ruído, e a confiança no canal de bug report (recurso que qualquer dev usa quando encontra comportamento estranho em produção) fica mais frágil para todo mundo.

O contra-argumento que merece resposta

A leitura mais generosa é perguntar se essa crítica não é só gatekeeping contra quem está começando a contribuir e usa IA como muleta legítima. Pettus antecipa essa objeção: ele não é contra IA, usa como assistente de código e escrita, e diz explicitamente que é bem-vindo usar IA para achar bugs. O problema que ele descreve não é a ferramenta, é a ausência completa de verificação humana antes do envio.

Esse padrão de contribuição de baixo esforço em busca de reconhecimento (aparecer no release notes de um projeto de alto perfil) já existia antes da IA generativa. O que mudou é a velocidade: uma pessoa sem conhecimento profundo de Postgres agora consegue produzir, em minutos, um relato tecnicamente formatado, com stack trace e patch sugerido, numa escala que nenhum processo de triagem manual foi desenhado para absorver.

Discordo, porém, de um ponto que fica implícito: tratar isso como problema passageiro de etiqueta. Na prática, projetos de código aberto↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → vão precisar de um filtro estrutural, seja um rótulo obrigatório de "relato assistido por IA", seja uma fila de triagem separada, porque confiar na boa vontade de quem contribui não escala quando o custo de gerar um relato caiu a praticamente zero.

Como eu usaria IA para reportar um bug do PostgreSQL

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

A diferença entre usar IA como ferramenta de descoberta e virar fonte de ruído está em quem assina o relato e no trabalho que vem antes do envio. Um roteiro razoável, para quem trabalha com banco de dados no dia a dia:

1. Reproduza o problema isoladamente: um script mínimo com psql, sem dependência da aplicação inteira, que qualquer mantenedor consiga rodar e confirmar.
2. Confira o plano de execução com EXPLAIN ANALYZE antes de supor que o comportamento é um bug e não uma característica do otimizador.
3. Verifique se o problema já foi corrigido, olhando o arquivo CHANGES da versão em desenvolvimento e os commits recentes no repositório.
4. Pesquise nas listas -hackers e -bugs se alguém já discutiu o mesmo sintoma antes de abrir um relato novo.
5. Use a IA para rascunhar a explicação técnica se isso ajudar, mas leia e valide cada afirmação como se fosse sua, porque é sua: é você quem vai precisar justificar e defender o relato se alguém perguntar.

Em resumo: a IA pode acelerar a parte de investigação, mas não substitui o julgamento de quem entende o motor de execução e o modelo de concorrência do banco. Enviar sem esse filtro é terceirizar para o mantenedor o trabalho que era seu.

O que fica em aberto

Pettus não propõe um mecanismo formal de filtro, e isso é o vazio real do post.

O que não dá para ignorar é o incentivo perverso: contribuir para um projeto de alto perfil virou moeda social, e a IA barateou demais o custo de tentar a sorte. Resolver isso vai exigir dos projetos de código aberto algo que o PostgreSQL ainda não tem publicamente definido: uma política explícita sobre o que é um relato aceitável quando a IA entra na produção dele.

Fonte: Planet PostgreSQL