Muchos lectores sabrán que se ha revertido un número inusualmente alto de funciones de la rama de PostgreSQL 19 tras el inicio del período beta. Que haya algunas reversiones no es raro, y cabría esperar quizá una por ciclo. Pero esta vez, según cómo se cuente, se han revertido unas 8 a 10 funciones significativas, algunas de ellas bastante tarde en el período beta. El autor, desarrollador o committer de algunas de las funciones afectadas, reflexiona sobre lo ocurrido y ofrece opiniones que aún son preliminares.
Las causas probablemente sean una combinación de factores que difieren para cada función. El autor admite que el código quizá no fuera lo bastante bueno y que el equipo pudo no haber hecho un trabajo suficientemente bueno. También puede haber sido una coincidencia: el proyecto venía en una buena racha e intentó varias funciones que resultaron demasiado difíciles de terminar a tiempo. Algunas funciones tenían defectos arquitectónicos significativos que habrían sido difíciles de corregir rápidamente durante la beta. Otras sufrieron una larga cola de problemas de casos límite relativamente inofensivos que, en ciclos anteriores, habrían aparecido más tarde y se habrían corregido gradualmente en los años siguientes.
La revisión de código asistida por LLM ha cambiado ese calendario. Estos problemas ahora se encuentran mucho más rápido, dejando a los desarrolladores con una lista de unos cuarenta informes de defectos. Aunque cada uno requiera solo una pequeña corrección, el coste fijo de gestionar cada uno se acumula y el tiempo se agota. La mayoría de las funciones afectadas se escribieron mucho antes de que estas herramientas de revisión fueran útiles, así que el nivel de calidad exigido efectivamente ha subido desde que se confirmaron. El autor sostiene que esto no se debe al "vibe coding", ya que el código es anterior a esa posibilidad.
La situación también empeoró por la crisis de seguridad apodada "Vulnpocalypse", que llevó a muchos desarrolladores senior a trabajar en correcciones de seguridad de abril a agosto. Como resultado, la revisión y las pruebas adicionales habituales durante la beta se redujeron y solo se reanudaron más tarde, lo que explica por qué muchos problemas aparecieron tan tarde. El autor cree que con unos dos meses más se habrían podido abordar muchos de los problemas menores, pero la comunidad optó por mantener el calendario de lanzamiento en lugar de retrasarlo.
Fuente: Hacker News · Resumido por HeadlinesBriefing