En corto: la IA no está dañando el software; está haciendo que sus errores se encuentren mucho más rápido, también por quien quiere aprovecharlos. Por eso tu software necesita a alguien con nombre que lo revise y lo mantenga con un presupuesto fijo, no solo cuando sobra plata.
Robert Haas, desarrollador de PostgreSQL, publicó el 30 de octubre de 2026 un artículo con un título que no deja dudas: «Postgres 19 is late, and it’s AI’s fault», es decir, «Postgres 19 llega tarde, y es culpa de la IA». PostgreSQL es una base de datos de código abierto: el sistema donde muchas aplicaciones, tiendas en línea y sistemas empresariales guardan su información.
Si tu empresa tiene un sitio, una tienda o un sistema propio, este caso te sirve aunque no sepas qué base de datos usa. Lo que cuenta Haas no es solo un problema de PostgreSQL: él mismo dice que, en cierta medida, toca a cualquier desarrollador de software. Es un cambio en la forma en que se encuentran los errores, y eso afecta directamente cómo presupuestas el mantenimiento del tuyo.
Según Haas, durante la última década las versiones grandes de PostgreSQL salieron de forma muy predecible: no antes de mediados de septiembre ni después de mediados de octubre. Este año será distinto. Lo más probable es que PostgreSQL 19 salga en noviembre, y no se descarta que el proyecto decida aplazarlo más.
La explicación corta, en sus palabras, es que «pasaron los LLM», los modelos de lenguaje que están detrás de las herramientas de IA. Todo software tiene errores, y el de PostgreSQL es grande, complejo y tiene décadas de historia. Lo que cambió es que ahora es mucho más fácil encontrar esos errores. Arreglarlos también se volvió más fácil, pero no en la misma medida.
Haas lo muestra con el número de cambios registrados en el código entre el 8 de abril y el 25 de septiembre de cada año:
¿La razón? Según Haas, muchísima gente en internet está reportando errores en PostgreSQL que encontró usando IA, y el equipo ha estado muy ocupado corrigiéndolos. El tiempo que se habría dedicado a revisar lo que entraba en la nueva versión se fue en atender problemas de seguridad y otros errores en versiones anteriores.
Hay un detalle que a cualquier dueño le debería sonar: la IA puede proponer arreglos, pero esos arreglos no siempre son correctos ni cumplen los estándares del proyecto. Por eso, igual tienen que revisarlos y aplicarlos personas. El propio Haas aclara que el retraso no le preocupa demasiado, porque nace del cuidado del proyecto por la calidad.
Es tentador leer esta noticia como «la IA está dañando el software». No es eso. Los errores ya estaban ahí; algunos llevaban años escondidos. Lo que cambió es la velocidad con la que se encuentran.
Haas lo plantea así: todo lo que los desarrolladores de PostgreSQL escriban de ahora en adelante será examinado por la IA, y cosas que antes habrían pasado inadvertidas para siempre ahora se encontrarán, quizá en cuestión de horas. También dice que eso obliga a cada desarrollador de PostgreSQL, y en cierta medida a cualquier desarrollador de software, a subir su nivel. Haas no habla de ataques; esta parte es lectura nuestra: esa velocidad no es solo para los voluntarios que reportan fallas de buena fe. La misma facilidad para encontrar un error le sirve a quien quiere aprovecharlo para entrar a un sistema.
Para una empresa, eso cambia la cuenta. Un error que antes podía quedarse dormido durante años hoy puede aparecer en un reporte, o en un ataque, mucho antes. Lo que está en juego no es la tecnología: un error así puede traducirse en pedidos que no entran, clientes que no pueden ingresar y una conversación difícil sobre la confianza en tu marca.
En muchas empresas el mantenimiento funciona así: se hace cuando algo se rompe o cuando queda presupuesto al final del año. Mientras los errores se encontraban despacio, ese modelo aguantaba. Ahora la distancia entre que alguien encuentra una falla y que tú la corriges es justo donde está el riesgo.
Tu software, además, no es solo el código que te hicieron. Depende de piezas de terceros: la base de datos, el lenguaje en el que está escrito, las librerías, los plugins y los servicios que conecta. Cuando cualquiera de ellos publica un parche, alguien tiene que enterarse, probarlo y aplicarlo. Lo vimos hace poco con el parche crítico de PHP: el aviso salió y la pregunta de fondo fue quién lo aplicaba ese mismo día.
Lo que hemos aprendido manteniendo sitios y software de nuestros clientes es que el riesgo más grande pocas veces es técnico. Es que el tema no tiene dueño: todos suponen que alguien más está pendiente de las actualizaciones, y al final nadie lo está.
Si hoy cualquiera puede usar IA para buscar fallas en un sistema, la pregunta no es si alguien va a revisar el tuyo, sino quién llega primero. Necesitas un nombre, de tu equipo o de tu proveedor, que revise de forma periódica tu software y las piezas de terceros de las que depende, y que te cuente qué encontró en palabras que puedas entender.
Un parche es una corrección que publica el fabricante de una pieza de software. Que exista no sirve de mucho si nadie lo aplica. Pregunta quién se entera del aviso, quién lo prueba antes de instalarlo, en cuánto tiempo y cómo te confirma que quedó hecho. Si la respuesta es «supongo que el proveedor», ahí tienes tu primer hallazgo.
La salida no es comprar una herramienta y esperar que lo resuelva sola. Es tratar el mantenimiento como un gasto fijo del negocio, igual que la contabilidad o los seguros, y tener a alguien que lo acompañe mes a mes. En la práctica, eso incluye:
Un presupuesto fijo también cambia la forma de trabajar. Una actualización planeada se prueba con calma; una de urgencia se hace con prisa, muchas veces con el negocio detenido. Y si tu sistema es un desarrollo propio, conviene que quien lo mantiene conozca bien cómo se construyó, como pasa con el desarrollo web a medida.
Según Robert Haas, porque mucha gente está encontrando y reportando errores con herramientas de IA, y el equipo dedicó más tiempo a corregirlos. Las versiones grandes de PostgreSQL solían salir entre mediados de septiembre y mediados de octubre; esta vez, lo más probable es que PostgreSQL 19 salga en noviembre o después.
No por sí misma. Los errores ya existían; lo que cambia es que ahora se encuentran más rápido, también por quien quiere aprovecharlos. Por eso importa quién los encuentra y los corrige primero.
La IA puede proponer arreglos, pero no siempre son correctos. Una persona tiene que revisarlos y probarlos antes de que lleguen a producción, que es lo que hace el propio equipo de PostgreSQL.
Como mínimo: actualizaciones con calendario, revisión de dependencias y servicios de terceros, pruebas antes de publicar cada cambio y una persona con nombre que responda cuando sale un parche o algo falla.
En Somos Gente Digital escuchamos, construimos y acompañamos hasta que el negocio crece. En mantenimiento eso significa revisar tu software antes de que lo revise otro, mantener al día las piezas de las que depende, probar cada cambio antes de publicarlo y contarte qué quedó hecho. No te vamos a prometer un software sin errores, porque ninguno lo es, ni siquiera PostgreSQL. Sí te ofrecemos gente cercana, un método claro y alguien que responde cuando sale un parche.
Si hoy no tienes claro quién revisa tu software, mira cómo trabajamos el mantenimiento de software y conversemos.
MANTENIMIENTO CON DUEÑO
El 21 de octubre de 2026 PHP publicó un parche para dos fallas críticas que permiten entrar a un servidor sin contraseña. No es un tema técnico: es saber quién en tu empresa o en tu proveedor lo actualiza ese mismo día y te lo confirma por escrito.
Si te proponen cambiar todas las URLs o comprar un dominio con palabras clave para subir en Google, eso no es una mejora: es una mudanza. Google recordó en octubre de 2026 que esas palabras pesan casi nada. Cuándo sí vale tocar URLs y cómo hacerlo bien.
