Un nuevo informe de campo de OpenAI y colaboradores académicos sostiene que las herramientas de programación con IA se están volviendo útiles para un problema descuidado pero importante en la ciencia: mantener y modernizar el software de investigación del que dependen muchos laboratorios, pero para el que pocos equipos tienen tiempo de ofrecer un soporte adecuado. A lo largo de ocho estudios de caso, los investigadores usaron agentes de programación para actualizar sistemas de instalación, portar código heredado a marcos de trabajo más nuevos, optimizar el rendimiento e incluso reescribir herramientas envejecidas en nuevos lenguajes.

La conclusión central es más cautelosa que triunfal. Según el informe, sistemas como Codex, Claude Code, GPT-5.5 y GPT-5.2 pueden acelerar el trabajo de implementación, a veces en gran medida, pero no se puede confiar en ellos para determinar si el software resultante es científicamente correcto. En la práctica, eso desplaza el cuello de botella desde escribir código hacia diseñar pruebas, validar resultados y asignar responsabilidad de mantenimiento a largo plazo.

Lo que, según el informe, cambió

El informe, descrito por The Decoder como un relato de campo más que como un estudio formal representativo, se centra sobre todo en software relacionado con la biología. Eso importa porque muchas herramientas de investigación comenzaron como código escrito para un solo artículo o proyecto, y luego quedaron integradas en flujos de trabajo más amplios sin la dotación de personal ni la disciplina de ingeniería típicas del software comercial.

En ese contexto, los agentes de programación parecen más útiles cuando la tarea es clara y el objetivo de validación puede definirse de antemano. Un ejemplo fue cyvcf2, una biblioteca de Python para leer datos genéticos, donde se usó GPT-5.5 para reemplazar una configuración de compilación e instalación obsoleta por una más moderna.

Un ejemplo más complejo fue MHCflurry, un modelo de inmunología usado para predecir qué objetivos pueden reconocer las células inmunitarias. Según el informe, Claude Code y Codex alternaron entre funciones de implementación y revisión mientras portaban unas 10.000 líneas de código de TensorFlow a PyTorch. Ese tipo de migración suele ser necesario para el mantenimiento y el rendimiento, pero también es arriesgado porque el software científico puede parecer que funciona correctamente mientras produce salidas sutilmente erróneas.

El caso más ambicioso fue rustar-aligner, una reescritura de STAR en Rust. STAR se usa ampliamente para mapear lecturas de secuenciación a ubicaciones del genoma, y el informe dice que la base de código original supera las 20.000 líneas de C y C++ y ya no recibe mantenimiento activo. En pruebas sobre 10.000 lecturas cortas de secuenciación de células de levadura, rustar-aligner igualó a STAR en el 99,815 por ciento de los casos de extremo único y en el 99,883 por ciento de los casos de pares, según los criterios de comparación del informe. Los autores también afirmaron que ninguno de los dos herramientas alineó lecturas que la otra no pudiera alinear por completo.

Las grandes mejoras de velocidad vinieron con una salvedad

Las mejoras de rendimiento destacadas en el informe son sustanciales, pero provienen de proyectos individuales y no de un punto de referencia controlado entre muchos equipos.

RustQC, que consolidó 15 herramientas de control de calidad en un solo programa, habría reducido el tiempo de ejecución en un gran conjunto de datos de 15 horas y 34 minutos a 14 minutos y 54 segundos, es decir, más de 60 veces más rápido. Otro proyecto, HelixForge, reemplazó BamSurgeon para la generación de datos genómicos sintéticos con una versión basada en GPU. En la prueba citada, usando datos de un donante y una región genómica de diez millones de pares de bases, todo el flujo de trabajo se ejecutó 59,6 veces más rápido y su principal paso de cómputo 98,6 veces más rápido que con BamSurgeon.

Otros proyectos fueron menos espectaculares, pero aun así notables. En hifiasm, una herramienta de ensamblaje genómico, GPT-5.5 habría encontrado optimizaciones que redujeron el tiempo de ejecución en datos reales del genoma humano en casi un 15 por ciento después de que el investigador primero construyera conjuntos separados de entrenamiento y validación. En HI.SIM, GPT-5.2 y luego un modelo más nuevo optimizaron distintas partes del programa, con mejoras combinadas de tiempo de ejecución de alrededor del 31 por ciento sin cambiar la salida, según el informe.

Esos resultados sugieren un papel práctico a corto plazo para los agentes de IA en la ingeniería de investigación: no ciencia autónoma, sino modernización de código, reparación de dependencias, ajuste de rendimiento y migración de marcos de trabajo. Para laboratorios con tuberías frágiles, eso podría ser significativo incluso cuando las mejoras queden por debajo de los mejores ejemplos del informe.

Dónde fallaron los modelos

El mensaje más importante del informe es que superar pruebas o producir salidas plausibles no basta cuando el software incorpora supuestos científicos.

El estudio de caso de bayesm ilustra el problema. Su reescritura en Rust habría corrido entre dos y veinte veces más rápido que el original, pero las primeras versiones de dos métodos avanzados seguían conteniendo errores difíciles de detectar solo a partir de las salidas. En un caso, el agente de programación invirtió un parámetro de control y usó el recíproco del valor previsto. También se le escapó otro error de cálculo. Los investigadores solo encontraron esos problemas después de realizar una calibración detallada con miles de conjuntos de datos sintéticos con resultados conocidos.

Un segundo método de bayesm, HART, ofreció resultados que parecían ampliamente plausibles, pero aún contenían múltiples fallos, incluidos cálculos excesivamente costosos y un factor de corrección mal escalado. La lección de ese ejemplo es contundente: el software puede parecer numéricamente estable e incluso científicamente razonable y aun así estar mal de formas que importan para la interpretación posterior.

Las personas implicadas en los proyectos hicieron explícita esa preocupación. Brent Pedersen, desarrollador de cyvcf2, escribió que los agentes de programación facilitan avanzar rápido, pero que la ciencia sigue requiriendo “expert guidance, understanding, taste, and care.” Philip Ewels, quien dirigió RustQC, describió los sistemas como “eloquent, convincing, and confidently wrong in ways that are easy to miss.” Según el relato de The Decoder, no permitió que los modelos evaluaran su propia corrección y en su lugar utilizó un entorno de pruebas independiente.

Esa división del trabajo aparece repetidamente en los estudios de caso: los humanos definen objetivos, criterios de aceptación y métodos de validación; los agentes producen implementaciones; luego los expertos comprueban si el software realmente hace el trabajo científico correcto.

Evidencia, límites y de quién son estas afirmaciones

Las afirmaciones más fuertes de esta historia provienen de un informe de campo producido con OpenAI y socios académicos, según The Decoder. Los estudios de caso son relatos retrospectivos de los participantes, no una encuesta aleatoria ni representativa del trabajo de software de investigación. Esa limitación importa.

Por lo tanto, las cifras de rendimiento de RustQC, HelixForge, hifiasm, HI.SIM, bayesm, rustar-aligner, MHCflurry y cyvcf2 son resultados específicos de proyectos informados por los equipos involucrados. Deben leerse como ejemplos de lo que es posible bajo condiciones cuidadosamente acotadas, no como una prueba general de que los agentes de programación entregarán de manera fiable las mismas mejoras en otras bases de código.

La misma cautela se aplica a las estimaciones económicas del informe. Los autores sugieren que, si los agentes resolvieran entre una cuarta parte y la mitad de los problemas de instalación en 100 paquetes de investigación, el tiempo de investigación recuperado podría valer entre 600.000 dólares y casi 5 millones de dólares. También estiman unas 650 horas de mantenimiento ahorradas al año para NumPy. Esas cifras son estimaciones orientativas del informe, no datos de mercado verificados externamente.

El informe también señala un riesgo organizativo importante: las reescrituras baratas pueden crear fragmentación. Si los laboratorios generan versiones alternativas de herramientas consolidadas más rápido de lo que las comunidades pueden mantenerlas, podrían dividir a los usuarios y consumir aún más tiempo de los mantenedores. Esa preocupación apareció en los ejemplos. Algunas mejoras se integraron de nuevo en los proyectos originales, otras no. Como STAR ya no se mantenía, rustar-aligner se trasladó a scverse. En otro caso, el autor de FastQC se negó a reemplazar la herramienta original por su reescritura en Rust, y el equipo aplicó en su lugar las mejoras descubiertas a la versión Java existente, obteniendo la misma aceleración por tres.

Por qué esto importa para los creadores y los equipos empresariales de IA

Para los creadores de IA, el informe refuerza el caso de los agentes de programación como asistentes de infraestructura en lugar de desarrolladores autónomos de extremo a extremo. El patrón útil no es “el agente escribe código, se publica”, sino “el agente propone cambios dentro de un ciclo riguroso de validación”. Eso es especialmente relevante para los equipos empresariales de IA que trabajan en ámbitos regulados o de alto riesgo como la salud, la biotecnología, las finanzas y los sistemas industriales.

Para los equipos de producto que evalúan Codex, Claude Code, GPT-5.5 o GPT-5.2, la conclusión práctica es que la fiabilidad depende menos del modelo por sí solo que del proceso que lo rodea. Siguen siendo esenciales los entornos de pruebas independientes, los conjuntos de datos de referencia, los criterios formales de aceptación y la revisión humana. Cuanto mejor pueda especificarse la tarea, más valor parece aportar un agente de programación.

Para las organizaciones de investigación y los compradores empresariales, el ángulo del mantenimiento puede ser incluso más importante que las mejoras brutas de velocidad. Muchas instituciones dependen de software antiguo pero esencial cuyos autores originales siguieron adelante. Si las herramientas de programación con IA pueden reducir el coste de las actualizaciones, los portos de marcos, las correcciones de dependencias o el ajuste de rendimiento, pueden prolongar la vida de herramientas críticas. Pero el comprador también hereda la carga de la verificación y de la administración futura.

Qué vigilar a continuación

La próxima señal a seguir es si estos métodos de estudio de caso se convierten en flujos de trabajo repetibles. Eso significa más que mejores modelos. Implica entornos de evaluación estandarizados, modelos de propiedad más claros y prácticas más sólidas para comparar herramientas reescritas con líneas base de confianza.

También vale la pena observar si más comunidades siguen el modelo de scverse al dar un hogar institucional a las reescrituras asistidas por IA, en lugar de dejarlas como experimentos puntuales. Otro indicador será si los mantenedores de proyectos importantes como NumPy o bibliotecas científicas cercanas a PyTorch adoptan el mantenimiento impulsado por agentes para tareas rutinarias, mientras conservan una revisión humana más estricta para los cambios algorítmicos.

Por último, el progreso de los modelos sigue importando. Según se informa, una persona implicada en el esfuerzo de MHCflurry dijo que un intento anterior a principios de 2025 fracasó porque los modelos disponibles aún no eran lo bastante capaces. Si esa evaluación es correcta, las nuevas generaciones podrían ampliar la gama de tareas que los agentes pueden manejar. Pero el informe sugiere que una mejor fluidez en programación no resuelve el problema más difícil del juicio científico.

Perspectiva de Creati.ai

Este informe llega en un momento importante del debate sobre los agentes de IA porque separa dos ideas que a menudo se confunden: generar software que parezca correcto y producir software científicamente fiable. En contextos de investigación, no son lo mismo. Cuanto más convincentes se vuelven los agentes de programación, más peligroso es confundir la calidad de la implementación con la corrección del dominio.

Para la industria de la IA, eso apunta a una oportunidad más fundamentada. El mercado inmediato no es la ingeniería de investigación totalmente autónoma. Es la creación de herramientas que ayuden a los expertos a modernizar pilas de software frágiles, migrar código heredado y reducir retrasos de mantenimiento mientras la validación se vuelve más sistemática. Los proveedores que combinen una fuerte generación de código con pruebas robustas, trazabilidad y flujos de trabajo de revisión probablemente crearán un valor más duradero que quienes vendan solo autonomía.