Postgres 19 Atrasou Porque A Revisão Com LLM Achou Defeitos Demais: O Custo De Triar O Que A IA Encontra

Quase todo time que adotou revisão automática de pull request conhece uma cena. Abre-se o PR, o bot deixa onze comentários em dois minutos, e alguém precisa decidir quais são reais, quais são ruído e quais são reais mas não valem esta semana. O comentário em si custou segundos de máquina. A decisão sobre ele custa atenção humana, e atenção humana não escala com a mesma curva. Eu já tinha essa intuição, mas ela ficou mais nítida quando li a notícia do atraso do PostgreSQL 19 e pensei no backlog de comentários de revisão que qualquer time acumula.

A matéria é da The Register, de 16 de outubro. O que ela relata, em resumo: o lançamento previsto para o fim de setembro ou início de outubro foi empurrado para cerca de 19 de novembro, e entre 8 e 10 features significativas foram revertidas. Um dos principais committers do projeto atribui o atraso, pelo menos em parte, à revisão de código assistida por LLM. O título da própria matéria resume o argumento: os revisores de IA acharam mais bugs do que humanos conseguem consertar.

Preciso ser claro sobre o que este post é. Minha fonte é uma única matéria. Ela cita um texto de Peter Eisentraut sobre o assunto, e eu não li esse texto; tudo o que atribuo a ele vem do que a matéria relata. Também não participo do desenvolvimento do Postgres e não vi o processo por dentro. O que escrevo é uma leitura, com raciocínio meu quando estiver marcado como tal.

Vou passar pelo que a matéria diz e pelo que ela deixa de dizer, por que achar defeito é barato e triar é caro, pelo mecanismo da régua que sobe no meio do ciclo, pela diferença entre defeito de projeto e caso de borda e a decisão de reverter, pelo contraste com o caso que discuti na terça, e por algumas práticas hipotéticas para incorporar esse tipo de revisão sem estourar a capacidade de triagem do time.

---

O Que A Matéria Relata E O Que Ela Não Diz

Os fatos, como a The Register os apresenta. O PostgreSQL 19 estava previsto para o fim de setembro ou início de outubro e hoje a expectativa é por volta de 19 de novembro. Os desenvolvedores reverteram de 8 a 10 features significativas, que agora devem ir para o PostgreSQL 20. Entre as revertidas está o SQL/PGQ, que traz consultas de grafo de propriedades para dentro do SQL, retirado por problemas não resolvidos. A matéria conta que Tom Lane previu que enviá-lo na 19 geraria bugs pós-lançamento que só poderiam ser corrigidos na 20. Já o REPACK CONCURRENTLY, que evita o bloqueio de tabela do VACUUM FULL ao recuperar espaço em disco, ficou na 19.

Peter Eisentraut, vice-presidente da EDB e um dos principais committers do projeto, diz que a revisão assistida por LLM é pelo menos em parte responsável pelo atraso. Segundo a matéria, algumas das features revertidas tinham falhas sérias de projeto, difíceis de consertar rápido durante o beta. A revisão também trouxe uma quantidade grande de problemas menores, de caso de borda, que revisões anteriores provavelmente só deixariam aparecer depois do lançamento. Ele descreveu a situação como estar diante de uma lista de quarenta relatórios de defeito, cada um com um "custo fixo". A própria matéria usa quarenta como número ilustrativo, e eu o trato assim: não é a contagem total de relatórios.

Um detalhe que a matéria faz questão de registrar é o que Eisentraut diz que o caso não é: vibe coding. As features foram escritas antes de a técnica de revisão existir. Isso importa para a leitura, porque desloca a discussão do código gerado por IA para o código escrito por humanos e examinado, tarde, por uma ferramenta nova. E há um efeito de segunda ordem: o PostgreSQL 20, que devia conter só correções de bugs, agora deve incluir as features revertidas.

Agora o que a matéria não diz, porque isso limita o que posso concluir. Ela não informa quais ferramentas de revisão por LLM foram usadas, não dá o total de relatórios de defeito e não descreve como a triagem foi organizada. Não sei quantos relatórios eram falsos positivos, nem quanto tempo cada um consumiu. Qualquer número ou processo que eu preenchesse aí seria invenção. O que sobra é um relato de uma pessoa bem posicionada para opinar, filtrado por um veículo, sobre um mecanismo que me parece generalizável. É sobre esse mecanismo que o restante do texto trabalha.

---

Por Que Achar Defeito É Barato E Triar É Caro

A expressão "custo fixo" é a parte mais útil do relato, porque nomeia algo que a discussão sobre revisão com IA costuma ignorar. Um modelo pode apontar um problema em segundos, e a taxa de achados cresce com a quantidade de código lida e com o número de execuções. O custo de gerar o relatório é marginal. O custo de processá-lo, não. Para cada relatório alguém precisa ler, entender o contexto, reproduzir ou raciocinar até se convencer, decidir a severidade, decidir se corrige agora, depois ou nunca, e registrar a decisão. Esse trabalho tem um piso que não depende de o defeito ser grande.

Aqui entra um raciocínio meu, não um dado da matéria: um relatório gerado por modelo tende a exigir verificação humana antes de virar trabalho. Isso não significa que o modelo erre muito; significa que o revisor humano não pode assumir de antemão que o achado é verdadeiro, relevante e bem enquadrado. Em outro post sobre agentes que erram com confiança discuti o outro lado dessa moeda, o modelo que afirma sucesso sem base. O revisor de IA tem o espelho do problema: aponta defeito com a mesma segurança com que o agente declara a tarefa concluída. Em ambos os casos o sinal de confiança do texto não informa nada sobre a correção.

Esse deslocamento do gargalo não é exclusivo do Postgres. Um resumo de 4 de julho das notas de Dan Luu sobre desenvolvimento agêntico, publicado pelo Developers Digest, aponta na mesma direção: o gargalo sai de gerar e vai para verificar. É uma fonte secundária e a uso só para essa ideia geral, sem atribuir a ela nenhum detalhe. O ponto é que gerar código, gerar testes e gerar achados ficou barato, e tudo o que exige julgamento humano continuou com o preço de antes.

---

A Régua Que Sobe No Meio Do Ciclo

O segundo elemento do relato é temporal. A matéria diz que a régua de qualidade subiu: as revisões melhoraram nos meses anteriores ao lançamento, depois que muitas features já estavam escritas e commitadas. Esse é o ponto que mais me interessa, porque não depende de LLM. Qualquer mudança de critério no meio de um ciclo produz o mesmo efeito.

O mecanismo é este. Um ciclo de release tem uma sequência: desenvolvimento, revisão, estabilização, beta, lançamento. Cada fase pressupõe que a anterior fechou em certo nível de qualidade. Se o critério de revisão sobe depois que o código entrou, o código antigo é medido por uma régua nova, e tudo o que passou sob a régua antiga vira candidato a achado. Nada no código mudou; mudou o que se consegue ver. A dívida estava lá, invisível, e a nova técnica a tornou legível de uma vez, no momento em que a equipe tinha menos margem para pagá-la.

Isso muda o que "atraso" significa. Seria tentador ler o caso como "a IA atrapalhou o release". Pelo relato, a leitura mais fiel é outra: a revisão antecipou, para antes do lançamento, defeitos que de outro modo apareceriam depois dele, na forma de bug em produção. A matéria diz exatamente isso sobre os casos de borda, que revisões anteriores provavelmente só deixariam aparecer depois do lançamento. O custo não foi criado pela ferramenta. Foi movido para um momento mais caro de absorver, o fim do ciclo, em vez de um momento mais caro de sofrer, o pós-lançamento.

Para quem toca uma base de código própria, o paralelo é direto, e vale lembrar o que já discuti sobre dívida técnica de código gerado em escala: dívida invisível não deixa de existir por não ser medida. A diferença é que no caso do Postgres a dívida não vinha de geração por IA, segundo Eisentraut. Vinha de código normal, escrito num mundo em que não havia como examiná-lo com essa profundidade. A régua nova apenas cobrou o que a régua velha não cobrava.

---

Defeito De Projeto, Caso De Borda E A Decisão De Reverter

A matéria faz uma distinção que organiza todo o resto: havia features com falhas sérias de projeto e havia uma massa de problemas menores de caso de borda. Os dois tipos de achado não custam o mesmo, não se resolvem da mesma forma e, principalmente, não têm o mesmo destino. Misturá-los na mesma fila de triagem é, a meu ver, o erro mais caro que um time pode cometer ao incorporar revisão com LLM.

O caso de borda tende a ser localizado. Tem uma entrada, um estado, uma condição de corrida, e uma correção que cabe num patch com teste. Mesmo com custo fixo por relatório, é trabalho que se paga linearmente: dez casos de borda são dez vezes o trabalho de um, e a ordem pode ser decidida por severidade. O defeito de projeto é de outra natureza. Ele diz que a abstração, o modelo de dados ou o contrato da feature não sustentam o uso previsto, e consertá-lo é redesenhar, não remendar. A matéria relata exatamente isso: falhas sérias de projeto, difíceis de consertar rápido durante o beta.

Por isso a frase atribuída a Tom Lane sobre o SQL/PGQ é a mais reveladora do caso. Segundo a matéria, ele previu que enviar a feature na 19 geraria bugs pós-lançamento que só poderiam ser corrigidos na 20. Traduzindo para a lógica de release: se o conserto exige mexer em algo que, depois de publicado, vira compatibilidade a manter, então publicar é assumir a dívida com juros. Num banco de dados, em que interface e comportamento publicados viram contrato, isso pesa de um jeito particular. Nem todo produto tem esse custo, mas todo produto com usuários que dependem do comportamento tem uma versão dele.

Daí a ideia que gostaria de reter: reverter é uma decisão de release, não de código. O código para reverter uma feature costuma ser trivial, um revert de commit. O difícil é decidir que a feature não entra, assumir o custo político e de calendário, comunicar a quem esperava por ela e reencaminhá-la a um ciclo futuro. A matéria registra que de 8 a 10 features foram para o PostgreSQL 20, o que mostra que essa decisão foi tomada, e em escala. Ela também registra o efeito colateral, o de que a versão que devia ter só correções agora carrega features.

---

O Contraste Com O Caso Scion

Na terça escrevi sobre a revisão por intenção no Scion, da Anthropic, e a escala de 30 mil merges por dia. Lá o humano revisa menos o diff linha a linha e confia mais em teste pós-merge. Aqui o cenário parece o inverso: a revisão por IA acha mais do que o time dá conta de triar, e o resultado é desacelerar. À primeira vista são histórias opostas, uma de confiança na infraestrutura e outra de excesso de achados. Acho que são a mesma história vista de lados diferentes.

A diferença está em quanto a infraestrutura de teste e de rollback absorve. No modelo descrito no post de terça, e no texto da Anthropic Engineering sobre o redesenho do controle de versão listado nas fontes, a premissa é que um merge errado é barato de detectar e barato de desfazer. Se isso é verdade, deixar passar um defeito é um custo aceitável, e o gargalo humano deixa de ser a porta de entrada. No caso do Postgres, relatado pela matéria, a premissa é a oposta: o que sai publicado vira software de banco de dados em uso, com consequências que só podem ser corrigidas na versão seguinte. Aqui deixar passar um defeito é caro, e portanto cada achado precisa ser decidido antes.

Em outras palavras, a revisão humana pesada e a revisão humana mínima não são posições doutrinárias; são respostas ao preço do erro. Quando desfazer é rápido e automático, vale mais confiar em testes e reverter depressa. Quando desfazer é lento, coordenado e visível para terceiros, vale mais filtrar antes. Um mesmo time pode precisar das duas posturas em partes diferentes do sistema: a camada de interface experimental com rollback por feature flag e o motor de armazenamento com contrato estável.

Há leituras sobre tornar o ambiente legível para agentes, como a do Redreamality listada nas fontes, que apontam para o investimento certo: não é só melhorar o modelo, é melhorar o chão onde ele pisa, com testes confiáveis, regras explícitas e feedback rápido. Uso essa fonte só como direção geral, sem atribuir a ela afirmações sobre o Postgres. O que o contraste com o Scion sugere é que a capacidade de absorver revisão por IA é, em boa parte, uma propriedade do ambiente de entrega, não da ferramenta de revisão.

---

Como Incorporar Revisão Com LLM Sem Estourar A Triagem

O que segue é um conjunto de práticas hipotéticas, derivadas do mecanismo que o caso sugere. Nada disso é descrição do que o projeto Postgres fez, porque a matéria não diz como a triagem foi organizada. São ideias para um time na posição do leitor, marcadas como exemplo.

A primeira é tratar a triagem como recurso com orçamento. Imagine um time que define, para cada release, quantas horas de atenção humana reserva para processar achados de revisão automática. Se o orçamento é de vinte horas e cada relatório custa em média meia hora entre ler, verificar e decidir, a conta diz que cabem cerca de quarenta relatórios, e esse número, que aqui é apenas ilustrativo, vira um limite de fluxo e não um alarme depois que a lista já cresceu. Quando o orçamento acaba, o que sobra entra no backlog do ciclo seguinte, de forma deliberada.

A segunda é classificar na entrada, por severidade e por tipo. Um relatório que aponta risco de corrupção de dados não compete na mesma fila com um que sugere um nome de variável melhor. E o tipo importa tanto quanto a severidade: defeito de projeto sobe para quem decide escopo, caso de borda segue o fluxo normal, ruído é descartado com motivo registrado. O motivo registrado tem valor próprio, porque alimenta o ajuste do prompt ou da configuração da ferramenta e reduz o custo fixo dos ciclos futuros.

A terceira é congelar a régua por ciclo. Se a ferramenta, o modelo ou os critérios de revisão mudam no meio do ciclo, qualquer comparação com o que veio antes perde sentido e o código antigo é reavaliado sob regras novas. Uma política razoável seria avaliar uma mudança de régua entre ciclos, rodar a nova revisão sobre o código existente como auditoria separada, com orçamento próprio, e só então promover o critério para o gate oficial do próximo ciclo. Assim a régua sobe de forma planejada em vez de surpreender.

A quarta é definir a política de reversão antes de precisar dela. Quem decide que uma feature sai da release, com que critério e até que data? Se essa conversa acontece só quando a lista de achados já está grande, ela se mistura com pressão de calendário e com o apego de quem escreveu a feature. Uma regra simples, como "feature com defeito de projeto aberto na data de congelamento sai da release", tira a decisão do calor do momento. É um revert de commit, mas a regra é o que torna o revert uma decisão de release, tomada por quem tem autoridade para tomá-la.

Por fim, vale medir o que a revisão custa, e não só o que ela acha: tempo médio de triagem por relatório, proporção de relatórios que viram trabalho e proporção que é descartada. Sem isso o orçamento da primeira prática é chute. Com isso, o time sabe se a ferramenta está pagando o próprio custo de atenção. Para o debate mais amplo sobre o que a revisão de código muda quando boa parte do código vem de IA, esse tipo de métrica de processo me parece mais honesto do que a contagem bruta de achados.

---

Conclusão

O caso do Postgres 19, como a The Register o relata, não prova que revisão com LLM atrasa releases. Prova menos e ensina mais: que uma técnica que acha defeito barato pode revelar, de uma vez e tarde, uma dívida acumulada, e que o gargalo passa a ser a capacidade humana de triar, decidir e corrigir. O achado é bom notícia para a qualidade do produto e má notícia para o calendário, e as duas coisas são verdadeiras ao mesmo tempo.

Dito isso, mantenho as limitações do início. A fonte é uma única matéria. O texto de Peter Eisentraut que ela cita eu não li. Não sei que ferramentas foram usadas, quantos relatórios existiram nem como a triagem foi organizada, e o número de quarenta relatórios é ilustrativo. As práticas que sugeri são inferências do mecanismo, não descrição do que o projeto fez, e podem não se aplicar a um time com outro perfil de risco, como o do caso Scion.

O que me fica é uma pergunta de planejamento, e não de ferramenta: quanta triagem o seu processo comporta por ciclo, e o que acontece quando a régua sobe e a lista cresce além disso? Quem responde antes do beta tem um orçamento e uma regra de reversão. Quem responde depois tem, como o relato descreve para o Postgres, features indo para a próxima versão e uma versão de correções recebendo mais do que devia. Não tenho certeza de que haja um jeito indolor de fazer essa transição, só de que ela fica mais barata quando é decidida cedo.

Fontes:

• The Register — Postgres 19 delayed after AI reviewers find more bugs than humans can fix
• Anthropic Engineering — Redesigning source control at Anthropic
• Redreamality — Making the environment legible to agents
• Developers Digest — Dan Luu's agentic coding notes point to the real bottleneck