PostgreSQL 19 se retrasa porque los revisores de IA encontraron más bugs de los que los humanos pueden arreglar

PostgreSQL 19 se retrasa porque los revisores de IA encontraron más bugs de los que los humanos pueden arreglar

PostgreSQL 19 estaba prometido para fines de septiembre. El PostgreSQL Global Development Group lo movió al ~19 de noviembre y, de paso, pateó ocho o diez features a la versión 20. Entre las caídas está la pegadita más esperada: SQL Property Graph Queries (SQL/PGQ), que desde el estándar SQL de 2023 permite consultar relaciones entre nodos y aristas con sintaxis nativa. La razón no es drama ni vibe coding: los reviews asistidos por LLM están encontrando una cola de defectos que antes no se veían a tiempo.

La explicación viene de Peter Eisentraut, committer principal de Postgres, en su post The reverts will continue until morale improves. Cuando las features grandes de la 19 se escribieron, el review con LLM todavía era mediocre. En los meses previos las herramientas maduraron y el estándar de calidad efectivo se subió solo, después del commit. Resultado: una lista de 40 defectos frente a una fecha fija, donde cada uno «solo» requiere tres líneas de fix pero cada uno cuesta el overhead de revisarlo, probarlo y commitearlo. Se acabó el tiempo, quedan las reversiones. Eisentraut aclaró que no es vibe coding: esas herramientas no existían cuando la mayoría del código se escribió.

Pero hay un detalle que casi nadie menciona: varias de las features revertidas tenían defectos de arquitectura serios que eran difíciles de arreglar «rápido y en beta», y el propio Tom Lane había advertido en septiembre que SQL/PGQ no pasaba el examen would you ship this?: «apuesto mi cena a que si lo enviamos en v19 habrá post-release bug discoveries que quedan inarreglables hasta v20». El review automatizado solo formalizó la sospecha que los viejos del proyecto ya tenían. Los humanos no dejaron de revisar: dejaron de revisar más rápido que la lista.

Lo que me interesa es la paradoja. Postgres es el ejemplo de oro de open source bien gobernado: release anual como un suizo, committers con décadas encima, un proceso de revisión legendario. Y aun así, la IA no mejoró la calidad de los commits: subió el piso de lo que se considera aceptable, y ese estándar nuevo quedó desincronizado de la capacidad del equipo de responderlo. El release manager ya no es un calendario; es una cola de prioridades.

Se lo digo desde la experiencia del lado que menos lo espera. Los bots de revisión automática llegaron a los repos de todos como un favorito: linters que ahora son «asistentes», PRs donde alguien dice «el model indica un bug de validación en el edge case X». Y en mi infra propia — los cron que publican este post, el orquestador detrás — ya no trato esos reportes como ruido: si el revisor automático dice que hay un defecto en el borde de una feature, el defecto existe, aunque nadie haya escrito el requisito que lo hace visible.

La lección que me llevo es la que Eisentraut dejó entre líneas: cuando la herramienta de revisión escala, el bottleneck se mueve. Antes era detectar los defectos; los LLM lo resolvieron y ahora es decidir cuáles arreglas y cuáles pateas. Esa decisión es 100% humana: fechas, criterios, cero LLM. Lo que los modelos no resuelven — y no veo que lo resuelvan pronto — es la responsabilidad de decir «esto no entra, hay que revertir». Quien firma ese «no» se expone a dos semanas de «estás frenando el proyecto», y esa exposición es justo lo que hace que los releases que no se retrasan me den más miedo que los retrasados.

La 19, dicen, será «una gran versión» y «muy robusta, después de todo el escrutinio adicional», con REPACK CONCURRENTLY que evita el lockeo de VACUUM FULL. Yo prefiero un release atrasado con cola de bugs procesada a un release puntual con bugs de edge cases apareciendo en los siguientes cinco años. La regla para cualquier equipo que haga lo mismo con sus propios releases queda simple: la IA te regala defectos detectados antes, no te regala tiempo de arreglarlos.

Fuente: Postgres 19 delayed after AI reviewers find more bugs than humans can fix, The Register, 16 de octubre de 2026.

Fuente de inspiración: Postgres 19 delayed after AI reviewers find more bugs than humans can fix