Las herramientas de IA están ayudando a los desarrolladores a descubrir problemas de software más rápido que antes. Las experiencias de curl y PostgreSQL 19 muestran por qué el próximo reto es decidir qué hallazgos importan, corregirlos de forma segura y encontrar tiempo suficiente para una revisión de código minuciosa.
Cuando encontrar errores resulta más fácil que gestionarlos
Durante años, curl recompensó a los investigadores de seguridad que descubrían debilidades reales en su software. El programa ayudó a sacar a la luz 87 vulnerabilidades y pagó más de 100 000 dólares en recompensas.
Entonces cambió la calidad de los informes que llegaban.
Antes de 2025, más del 15 % de los envíos se confirmaban como vulnerabilidades de seguridad reales. Durante 2025, esa cifra cayó por debajo del cinco por ciento. Muchos informes parecían convincentes, pero describían problemas que los mantenedores no podían reproducir ni confirmar.
Daniel Stenberg, mantenedor de curl, dijo que el proyecto estaba recibiendo un volumen creciente de envíos de mala calidad, muchos de ellos creados con ayuda de IA. Investigarlos consumía un tiempo que podría haberse dedicado a mejorar el software.
El 26 de enero de 2026, Stenberg anunció que cerraría el programa remunerado de recompensas por errores (bug bounty) de curl. El programa terminó oficialmente el 31 de enero.
La decisión resultó inusual, porque encontrar más problemas de seguridad debería, en principio, ayudar a que el software sea más seguro. Sin embargo, la experiencia mostró que facilitar el descubrimiento también podía dificultar el mantenimiento.
Las herramientas de IA pueden examinar código y señalar dónde podría haber algo mal. No pueden hacer que todas sus sugerencias sean correctas. Un desarrollador sigue teniendo que determinar si el problema notificado puede ocurrir realmente y si pone en riesgo a los usuarios.
Ese trabajo se complica cuando los informes llegan más rápido de lo que un proyecto puede investigarlos.
La experiencia de curl resultó especialmente reveladora porque el problema no terminó cuando mejoró la calidad de los informes.
El problema de curl cambió, pero la carga de trabajo se mantuvo
Para abril de 2026, Stenberg describía una situación muy distinta.
La proporción de envíos confirmados como vulnerabilidades se había recuperado hasta situarse aproximadamente entre el 15 y el 16 %. Más informes identificaban errores reales, aunque esos problemas no llegaran a considerarse vulnerabilidades de seguridad.
La calidad había mejorado, pero el número de informes también había aumentado. Llegaban aproximadamente al doble del ritmo registrado durante 2025.
Para curl, el problema había pasado de investigar demasiadas afirmaciones poco fiables a gestionar un número creciente de descubrimientos útiles.
Una vulnerabilidad confirmada exige algo más que reconocer que existe un problema. Los mantenedores necesitan entender su causa, decidir su gravedad, desarrollar una corrección y asegurarse de que el arreglo no cree otro problema.
Un proyecto pequeño de código abierto puede contar solo con unas pocas personas experimentadas disponibles para este trabajo. Esos mismos colaboradores también mantienen las funciones existentes, revisan cambios y preparan las versiones.
Por tanto, unos descubrimientos mejores aportan beneficios reales, pero también pueden poner al descubierto más trabajo del que los mantenedores pueden completar con rapidez.
Por eso la calidad de los informes y la capacidad de revisión deben tratarse por separado. Unos criterios de envío más exigentes pueden reducir las investigaciones inútiles. No pueden eliminar el trabajo de ingeniería que generan los defectos reales.
GitHub dio un paso relacionado en mayo de 2026, cuando endureció los requisitos de su programa de recompensas por errores. Los investigadores que usan IA deben comprobar sus hallazgos antes de enviarlos y aportar una demostración funcional del problema notificado.
La política no desalienta la investigación asistida por IA. Pide a quien informa que demuestre que una afirmación es creíble antes de trasladarla a los mantenedores.
Eso reduce el trabajo evitable al principio del proceso. PostgreSQL 19 muestra lo que puede ocurrir cuando quedan problemas difíciles cerca de la fecha límite de un lanzamiento.
Qué retrasó realmente PostgreSQL 19
PostgreSQL es uno de los sistemas de bases de datos de código abierto más utilizados. En un principio, se esperaba que su versión 19 se publicara en otoño de 2026.
El calendario de lanzamiento cambió y varias funciones previstas se retiraron de la versión 19.
Peter Eisentraut, uno de los principales desarrolladores de PostgreSQL, escribió en octubre que se habían revertido aproximadamente entre ocho y diez funciones importantes. Revertir (revert) significa retirar un cambio de código aceptado previamente, normalmente porque no está listo para permanecer en la versión.
Algunas informaciones relacionaron estas retiradas con la revisión de código asistida por IA. La explicación era que las herramientas de IA habían descubierto demasiados errores como para que los desarrolladores pudieran corregirlos antes del lanzamiento.
La IA sí contribuyó a encontrar problemas, pero eso era solo una parte de la situación.
Eisentraut describió varios factores. Algunas funciones tenían problemas de diseño graves que habrían exigido cambios amplios. Otras contenían defectos menores que se volvieron más fáciles de encontrar gracias a la revisión de código asistida por LLM.
Al mismo tiempo, los colaboradores experimentados de PostgreSQL habían dedicado gran parte del ciclo de lanzamiento a ocuparse de problemas de seguridad. Eso redujo el tiempo disponible para revisar las nuevas funciones. Por eso la revisión llegó más tarde en el ciclo, y los desarrolladores descubrieron problemas cuando quedaba poco tiempo para resolverlos.
La complejidad de PostgreSQL hizo que algunas correcciones fueran especialmente difíciles. Las funciones deben comportarse correctamente con muchas combinaciones de configuraciones de la base de datos, tipos de datos y operaciones. Un cambio que funciona en un caso normal puede fallar cuando se usan juntas varias funciones menos habituales.
Las pruebas asistidas por IA pueden ayudar a descubrir estas combinaciones inusuales. Pero un problema encontrado cerca del final del desarrollo puede requerir aun así más tiempo del que permite el calendario de lanzamiento.
Tomas Vondra, colaborador de PostgreSQL, examinó las discusiones detrás de doce cambios revertidos. Clasificó uno como relacionado con la IA y otro como posiblemente relacionado con la IA. No encontró un respaldo claro para atribuir a la IA la mayoría de las reversiones restantes.
Vondra lo presentó como su valoración de las discusiones de desarrollo disponibles, no como un recuento oficial de todos los errores descubiertos por IA.
Christophe Pettus ofreció una explicación relacionada. Sostuvo que un problema importante fue el momento en que se produjo la revisión. El trabajo de seguridad había ocupado a los colaboradores experimentados, por lo que algunas revisiones de funciones se hicieron más tarde de lo habitual.
Estos relatos no establecen una única causa para cada función retirada. Sí muestran por qué es incompleta la conocida afirmación de que la IA encontró más errores de los que los desarrolladores podían corregir.
Algunos problemas eran difíciles por su diseño. Otros se hicieron visibles gracias a mejores pruebas. Y otros se descubrieron tarde porque las personas necesarias para la revisión habían estado ocupadas en otras tareas.
| Fuente | Qué examinó | Qué dice | Qué no demuestra |
|---|---|---|---|
| Peter Eisentraut, 9 de octubre de 2026 | Por qué se revirtieron aproximadamente entre ocho y diez funciones importantes | Varios factores: problemas de diseño graves, defectos menores que se volvieron más fáciles de encontrar gracias a la revisión de código asistida por LLM y el trabajo de seguridad que ocupó a los colaboradores experimentados. | Un recuento de errores encontrados por IA, ni una única causa para cada función retirada. |
| Tomas Vondra | Las discusiones detrás de doce cambios revertidos | Uno clasificado como relacionado con la IA, otro como posiblemente relacionado con la IA y ningún respaldo claro para atribuir a la IA la mayoría de los demás. | Un recuento oficial. Es su valoración de las discusiones disponibles. |
| Christophe Pettus | Cuándo tuvo lugar la revisión | El trabajo de seguridad ocupó a los colaboradores experimentados, por lo que algunas revisiones de funciones se hicieron más tarde de lo habitual. | Que el momento de la revisión, por sí solo, explique cada función retirada. |
| Proyecto PostgreSQL, 15 de octubre de 2026 | El calendario de lanzamiento | Una segunda versión candidata el 12 de noviembre y la disponibilidad general el 19 de noviembre de 2026, para incluir las correcciones de la actualización programada de noviembre. | Una fecha fija. El calendario aún puede cambiar antes de la disponibilidad general. |
| Snowflake Engineering, 16 de septiembre de 2026 | Un relato adicional sobre las pruebas asistidas por IA y las decisiones de lanzamiento | Se incluye como lectura adicional. | Nada publicado después del 16 de septiembre, incluidos los relatos de octubre citados arriba. |
El anuncio del proyecto PostgreSQL del 15 de octubre programó una segunda versión candidata para el 12 de noviembre y la disponibilidad general para el 19 de noviembre de 2026. El proyecto indicó que quería incorporar las correcciones de su actualización programada de noviembre antes de que la versión 19 estuviera disponible de forma general.
Por tanto, la experiencia de PostgreSQL no demuestra que la IA causara el retraso del lanzamiento. Muestra cómo unas pruebas más eficaces, un software complejo y el momento de la revisión de código pueden influir en las decisiones de lanzamiento.
Qué ocurre después de que una herramienta encuentra un problema
Un ejemplo sencillo permite ver con más claridad el trabajo que implica.
Supón que una herramienta de IA revisa una aplicación web y advierte de que una entrada inesperada podría provocar la caída del servicio.
La advertencia puede ser útil, pero un desarrollador tiene que comprobar si esa entrada puede llegar realmente al código afectado. Puede que la aplicación ya la rechace, o que la herramienta haya malinterpretado una comprobación anterior.
Si el problema es real, el equipo debe decidir su gravedad. Un fallo que solo se produce en un entorno de pruebas no es lo mismo que una debilidad que un atacante puede explotar de forma remota.
Solo entonces pueden los desarrolladores decidir una corrección adecuada.
La corrección necesita pruebas, y el software corregido debe llegar a los usuarios mediante una nueva versión o una actualización.
La IA puede ayudar en varias etapas. Puede sugerir pruebas, explicar código y proponer cambios. Aun así, el equipo sigue siendo responsable de comprobar los resultados.
Esta distinción importa cuando los equipos de software evalúan herramientas de IA.
Un informe que muestra que una herramienta descubrió cien posibles defectos dice poco sobre la mejora real de la calidad del software. El equipo también necesita saber cuántos hallazgos eran reales, qué gravedad tenían y si se resolvieron.
Esa es la conexión práctica entre curl y PostgreSQL.
curl sufrió la presión del número y la calidad de los informes que recibía. PostgreSQL tuvo que tomar decisiones difíciles sobre si el software estaba listo cuando las revisiones y las correcciones llegaron tarde.
Ambas experiencias hacen visible el trabajo que rodea a un descubrimiento.
Qué deberían cambiar los equipos de desarrollo
El mismo problema puede aparecer en una empresa que usa escáneres de seguridad automatizados, herramientas de revisión de código con IA o plataformas de pruebas de software.
Un equipo puede recibir cientos de advertencias sin saber cuáles requieren atención. Si los desarrolladores dedican la mayor parte de su tiempo a descartar informes incorrectos, el proceso de notificación necesita mejorar.
El enfoque de GitHub ofrece un punto de partida útil. Conviene exigir evidencias suficientes para investigar un hallazgo, incluida una explicación clara del comportamiento afectado y un ejemplo reproducible cuando sea factible.
Pero los equipos también deberían examinar qué ocurre después de que se confirma un problema.
Si los hallazgos válidos siguen abiertos porque los desarrolladores están ocupados con otro trabajo, el problema ya no es la calidad de los informes. La organización debe decidir cómo asignar el tiempo de ingeniería.
Si las correcciones están terminadas pero esperan las pruebas o la aprobación para publicarse, es esa etapa la que necesita atención.
Un ejercicio útil es seguir una pequeña muestra de hallazgos recientes desde su envío hasta su resolución. Anota cuánto tardó cada uno en validarse, corregirse, probarse y publicarse.
| Etapa | Cuánto tardó | Quién hizo el trabajo | Qué estuvo esperando |
|---|---|---|---|
| Validar | completar | completar | completar |
| Corregir | completar | completar | completar |
| Probar | completar | completar | completar |
| Publicar | completar | completar | completar |
Una hoja de trabajo de TechiesJournal, no datos. Cópiala para cada hallazgo de una pequeña muestra de hallazgos recientes.
Los resultados pueden mostrar que el equipo necesita mejores comprobaciones automatizadas antes de aceptar informes. Pueden revelar que unos pocos ingenieros experimentados cargan con la mayor parte del trabajo de revisión. O pueden mostrar que correcciones importantes esperan demasiado para llegar a producción.
Son decisiones que pueden tomarse con las propias evidencias del equipo, en lugar de suponer que otra herramienta de IA resolverá el problema.
El objetivo no es frenar el descubrimiento de vulnerabilidades. Es asegurarse de que la organización pueda actuar sobre lo que descubre.
Descubrir más rápido es solo una parte de un software mejor
El análisis asistido por IA está permitiendo examinar más código y sacar a la luz problemas que antes quizá habrían permanecido ocultos.
Es un avance útil.
La experiencia de curl muestra por qué importa la calidad de los hallazgos que llegan y qué ocurre cuando aumentan los informes válidos. PostgreSQL 19 muestra por qué el momento de la revisión, la complejidad de un cambio y la disponibilidad de desarrolladores experimentados siguen siendo importantes.
Para los equipos de software, la lección es práctica. Mide lo que ocurre con los hallazgos después de que llegan, no solo cuántos descubren las herramientas.
El valor de la detección de errores asistida por IA está en convertir hallazgos creíbles en correcciones fiables que lleguen a los usuarios.
Referencias y lecturas adicionales
curl y la notificación de vulnerabilidades
- Daniel Stenberg, The end of the curl bug-bounty, 26 de enero de 2026. El descenso de los informes confirmados, la historia del programa y su cierre el 31 de enero.
- Daniel Stenberg, High-Quality Chaos, 22 de abril de 2026. La posterior mejora de la calidad de los informes y el aumento de su volumen.
- GitHub, Raising the bar for its bug bounty programme, 15 de mayo de 2026. Lo que se espera de los informes de seguridad asistidos por IA y verificados.
PostgreSQL 19 y la revisión de código
- Peter Eisentraut, The reverts will continue until morale improves, 9 de octubre de 2026. Relato de un desarrollador sobre la presión del lanzamiento, la arquitectura, el trabajo de seguridad y la revisión de código asistida por LLM.
- Tomas Vondra, Are we reverting patches because of bugs found by AI?. Examen caso por caso de doce cambios revertidos.
- Christophe Pettus, The patch is coming from inside the house. Análisis del momento en que se hizo la revisión.
- PostgreSQL 19 Release Candidate 1 announcement, 15 de octubre de 2026. Calendario oficial revisado del lanzamiento.
- Snowflake Engineering, PostgreSQL 19 release delay and feature reverts, 16 de septiembre de 2026. Un relato adicional sobre las pruebas asistidas por IA y las decisiones de lanzamiento.
Lecturas relacionadas en TechiesJournal
- Vulnerabilidad de Brotli en Node.js: cómo quedan expuestas las aplicaciones y qué deben comprobar los desarrolladores (en inglés). Explica cómo determinan los equipos si una debilidad de seguridad notificada afecta a sus aplicaciones.
Fecha de revisión de las fuentes: 30 de octubre de 2026. El calendario de lanzamiento de PostgreSQL puede cambiar antes de la disponibilidad general.