Si hay un proyecto de software libre en el que se puede confiar para planificar, es PostgreSQL. Desde hace una década, cada versión mayor sale entre mediados de septiembre y mediados de octubre, con una regularidad que ya quisieran muchos productos comerciales. Este año no va a ser así: Robert Haas, committer de PostgreSQL desde hace muchos años, explica en Postgres 19 is late, and it’s AI’s fault que la versión 19 no saldrá, como pronto, hasta noviembre, y que no descartan retrasarla más.
El titular parece una provocación, pero el argumento no va de que la IA escriba mal código. Va justo de lo contrario: la IA encuentra bugs mucho más deprisa de lo que los humanos pueden arreglarlos.
Tres funcionalidades retiradas a última hora
Lo primero que llama la atención es lo que se ha quedado fuera. Entre el 27 de agosto y el 15 de septiembre se retiraron tres funcionalidades grandes que ya estaban en la beta:
UPDATE/DELETE FOR PORTION OF, para modificar sólo un tramo temporal de una fila en tablas con periodos.- SQL/PGQ (SQL Property Graph Queries), las consultas de grafos del estándar SQL.
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION, para fusionar y dividir particiones.
Que se retire alguna funcionalidad justo después del feature freeze (que cada año es el 8 de abril) es normal. Que se retiren tres de este tamaño en plena beta, casi en septiembre, no lo es. Yo tenía ganas de ver SQL/PGQ en Postgres, así que tocará esperar a la 20.
Los números
Haas compara el mismo periodo, del 8 de abril al 25 de septiembre, en 2025 y en 2026:
| Rama | 2025 | 2026 | Variación |
|---|---|---|---|
master | 1.037 | 1.443 | +39% |
Rama estable de la versión en curso (REL_18_STABLE / REL_19_STABLE) | 724 | 1.169 | +61% |
Rama estable anterior (REL_17_STABLE / REL_18_STABLE) | 248 | 433 | +74% |
El matiz está en qué crece. Los commits que van sólo a master (los totales menos los que se llevan también a la rama estable) incluso han bajado un poco: de unos 313 a unos 274. Lo que se ha disparado son los backports, las correcciones que se aplican a la versión que está a punto de salir y también a las anteriores. Y un 74% más de commits en la rama de la versión anterior quiere decir que no se están arreglando sólo errores recién introducidos, sino bugs que llevan años ahí.
Haas lo dice sin rodeos: nadie en el proyecto cree que los committers se hayan vuelto más descuidados de un año para otro. Lo que ha cambiado es que muchísima gente está reportando bugs que ha encontrado con LLMs.
Encontrar es fácil, arreglar no tanto
La explicación del retraso tiene dos partes.
La primera es pura capacidad. Un LLM puede encontrar un bug en minutos y hasta proponer un parche, pero esos parches no siempre son correctos ni cumplen los estándares del proyecto. Alguien tiene que revisarlos y hacer el commit, y en palabras de Haas, esos humanos no se han vuelto más listos entre 2025 y 2026.
La segunda es de prioridades. El tiempo que en otros años se dedicaba a revisar lo que iba a entrar en la nueva versión se ha ido a corregir problemas de seguridad y otros bugs en las ramas antiguas. Por eso se tardó más en decidir qué había que retirar, y por eso las retiradas llegaron tan tarde.
Es exactamente lo que comentaba hace unas semanas en Los agentes de IA escriben más código, pero las empresas no sacan más software: el cuello de botella no está en producir, está en revisar. Aquí lo vemos desde el otro lado. No es más código nuevo lo que satura a los revisores, sino más informes de bugs, y el efecto es el mismo.
Cuarenta años de bugs
Haas no considera preocupante el retraso en sí. Unas semanas no son nada, y el retraso viene de que el proyecto se toma en serio la calidad. Lo que sí le inquieta es el panorama a largo plazo. El código de PostgreSQL empezó a escribirse hace unos cuarenta años, y el historial de git, convertido desde CVS, ya pasa de los treinta. Si hay cuarenta años de bugs que los humanos no fueron capaces de encontrar y que los LLMs sí encuentran, ¿cómo se pone uno al día? ¿Y cómo sigue innovando el proyecto mientras tanto? Él mismo reconoce que todavía no lo sabe.
Lo interesante es que no lo plantea como una crítica al código. Al contrario: dice que el de PostgreSQL es uno de los códigos más limpios y de más calidad con los que ha trabajado, y que si tuviera más defectos visibles a simple vista, los LLMs encontrarían todavía más. No es que Postgres esté mal hecho. Es que todo el software tiene bugs, y ahora hay una herramienta que los saca a la luz a un ritmo que antes no existía.
Lo que me llevo
Llevamos meses viendo la misma historia desde distintos ángulos: la IA ayudando a demostrar formalmente bibliotecas enteras, encontrando vulnerabilidades, saturando a los mantenedores con informes. El caso de Postgres me parece especialmente claro porque tiene datos, viene de dentro del proyecto y se trata de uno de los proyectos de software libre más cuidadosos que existen.
Hay un comentario en el artículo que lo resume bien: los atacantes también tienen LLMs. Si un bug se puede encontrar en horas con una IA, no basta con que nadie lo haya encontrado antes por casualidad. El listón ha subido para todos, y Haas termina diciendo justo eso: todo lo que escribamos a partir de ahora va a pasar por el escrutinio de una IA, y lo que antes habría pasado desapercibido para siempre se encontrará, quizá en cuestión de horas. Es un reto, pero también una oportunidad: Postgres 19 llega más tarde y con menos novedades, y probablemente sea una de las versiones más sólidas que ha publicado el proyecto.
Fuente: Postgres 19 is late, and it’s AI’s fault, Robert Haas (publicado originalmente en el blog de Neon).
