Muitos leitores sabem que um número incomumente alto de recursos foi revertido da branch do PostgreSQL 19 após o início do período beta. Algumas reversões não são incomuns, e talvez fosse esperado um por ciclo. Mas desta vez, dependendo de como se conta, cerca de 8 a 10 recursos significativos foram revertidos, alguns deles bastante tarde no período beta. O autor, desenvolvedor ou committer de alguns dos recursos afetados, reflete sobre o que aconteceu, oferecendo opiniões que ainda são preliminares.
As causas provavelmente são uma combinação de fatores que diferem para cada recurso. O autor admite que o código pode não ter sido bom o suficiente e que a equipe pode não ter feito um trabalho bom o bastante. Também pode ter sido coincidência: o projeto vinha em uma boa fase e tentou vários recursos que se mostraram difíceis demais para concluir a tempo. Alguns recursos tinham defeitos arquiteturais significativos que seriam difíceis de corrigir rapidamente durante o beta. Outros sofreram com uma longa cauda de problemas de casos extremos relativamente inofensivos que, em ciclos anteriores, teriam surgido mais tarde e sido corrigidos gradualmente nos anos seguintes.
A revisão de código assistida por LLM mudou essa linha do tempo. Esses problemas agora são encontrados muito mais rapidamente, deixando os desenvolvedores com uma lista de cerca de quarenta relatórios de defeitos. Mesmo que cada um precise apenas de uma pequena correção, o custo fixo de lidar com cada um se acumula e o tempo se esgota. A maioria dos recursos afetados foi escrita muito antes de essas ferramentas de revisão serem úteis, então o padrão de qualidade efetivo subiu desde que foram incorporados. O autor argumenta que isso não se deve ao "vibe coding", já que o código é anterior a essa possibilidade.
A situação também foi agravada pela crise de segurança apelidada de "Vulnpocalypse", que deslocou muitos desenvolvedores seniores para correções de segurança de abril a agosto. Como resultado, a revisão e os testes extras habituais durante o beta foram reduzidos e só foram retomados mais tarde, o que explica por que muitos problemas surgiram tão tarde. O autor acredita que, com cerca de dois meses a mais, muitos dos problemas menores poderiam ter sido resolvidos, mas a comunidade optou por manter o cronograma de lançamento em vez de adiá-lo.
Fonte: Hacker News · Resumido por HeadlinesBriefing