Los agentes de IA pueden modernizar software, pero no juzgar la ciencia
Un reporte de campo de OpenAI y socios académicos demuestra que los agentes de codificación pueden actualizar y acelerar software de investigación antiguo. Gran parte del trabajo, sin embargo, se desplaza de la escritura de código a la verificación de los resultados.
Muchas herramientas de investigación ampliamente utilizadas comenzaron como código de soporte para un solo artículo científico. Pequeños equipos académicos a menudo las desarrollaron sin el tiempo o los recursos necesarios para pruebas, mantenimiento u optimización adecuados. El resultado es un software frágil que sigue siendo crítico para campos enteros, pero que requiere reparaciones constantes. Un reporte de campo de OpenAI y socios académicos sugiere que los agentes de codificación de IA podrían ayudar a cerrar esa brecha.
El reporte documenta ocho casos de estudio, principalmente en biología, donde grupos de investigación utilizaron agentes de codificación como Codex y Claude Code. Los proyectos abarcan desde el mantenimiento básico y la optimización dirigida hasta reescrituras completas en lenguajes de programación modernos.
Los ocho proyectos van desde una simple modernización del proceso de compilación hasta una reescritura completa nativa para GPU.
¿Los agentes de IA realmente entregan mejoras de velocidad?
Los agentes de codificación entregaron mejoras de velocidad de más de 60 veces. Uno de los proyectos más sencillos involucró la modernización de cyvcf2, una librería de Python para la lectura de datos genéticos. GPT-5.5 reemplazó su proceso de compilación e instalación obsoleto por uno moderno.
La migración de MHCflurry fue mucho más compleja. MHCflurry es un modelo de inmunología que predice qué objetivos reconocerán las células inmunes. Claude Code y Codex alternaron entre los roles de desarrollador y revisor mientras portaban cerca de 10,000 líneas de código de TensorFlow a PyTorch.
El proyecto rustar-aligner fue más ambicioso. Reconstruyó STAR desde cero en Rust. STAR mapea lecturas de secuenciación de células a las ubicaciones correspondientes en un genoma. El original contiene más de 20,000 líneas de C y C++ y ya no recibe mantenimiento activo, aunque sigue siendo parte de muchos pipelines de investigación.
Para verificar si la reescritura se comportaba como la original, el equipo probó ambas herramientas en 10,000 lecturas de secuenciación cortas de células de levadura. Para lecturas de extremo único, rustar-aligner produjo el mismo resultado que STAR en el 99.815 por ciento de los casos. Para lecturas de extremo pareado, la tasa de coincidencia fue del 99.883 por ciento.
La comparación cubrió más que solo la ubicación mapeada en el genoma. También incluyó varios otros campos clave que ambos programas producen para cada lectura. Ninguna herramienta mapeó lecturas que la otra no lograra mapear.
RustQC entregó la mayor mejora de velocidad al combinar 15 herramientas de control de calidad separadas en un solo programa. En un conjunto de datos grande, el tiempo de ejecución cayó de 15 horas y 34 minutos a 14 minutos y 54 segundos, una mejora de más de 60 veces.
Otro proyecto, HelixForge, reemplazó una herramienta para generar datos genómicos sintéticos con una versión que se ejecuta en GPUs. En una prueba utilizando datos de un donante y una sección de diez millones de pares de bases del genoma, HelixForge completó el pipeline completo 59.6 veces más rápido que BamSurgeon. Solo el paso de cómputo principal se ejecutó 98.6 veces más rápido.
La reescritura nativa en GPU supera a la herramienta de CPU establecida en cada eje medido, no solo en velocidad.
¿Puede el código rápido producir mala ciencia?
A través de los casos de estudio, los agentes completaron tareas bien definidas rápidamente, pero no pudieron juzgar de manera confiable si su trabajo era científicamente correcto. Incluso cuando su código contenía errores, los sistemas a menudo lo presentaban con total confianza.
"Con los agentes de codificación, es bastante fácil ir rápido; por ahora, para llegar lejos en la ciencia, todavía existe la necesidad de guía experta, comprensión, buen juicio y cuidado", escribe el desarrollador de cyvcf2, Brent Pedersen.
Philip Ewels, quien lideró RustQC, describe a los agentes como "elocuentes, convincentes y confiadamente erróneos de maneras que son fáciles de pasar por alto". Nunca permitió que los modelos juzgaran la precisión de su propio trabajo y, en cambio, construyó un banco de pruebas independiente.
La mejora de velocidad provino de una serie de pequeños cambios de código en lugar de una optimización única.
El caso de estudio de bayesm muestra lo difícil que pueden ser de detectar estos errores. Su reescritura en Rust se ejecutó entre dos y veinte veces más rápido que la original, pero las primeras versiones de dos métodos avanzados contenían errores difíciles de notar solo a partir de la salida.
En un método, el agente invirtió un parámetro de control clave, causando que el programa utilizara el recíproco de los valores previstos. Un error separado afectó el cálculo mismo. Los investigadores solo lo encontraron después de ejecutar una prueba de calibración detallada contra miles de conjuntos de datos sintéticos con resultados conocidos.
La calibración estadística detectó un error que las pruebas de acuerdo anteriores habían pasado por alto.
Otro método, llamado HART, produjo resultados plausibles en general, pero aún contenía varios defectos. Estos incluían cálculos innecesariamente costosos y un factor de corrección escalado incorrectamente. Los resultados de prueba plausibles por sí solos no pudieron establecer que el código fuera correcto.
Un intento anterior de portar MHCflurry a PyTorch había fallado a principios de 2025. El desarrollador Sergey Feldman ahora atribuye el fracaso a los modelos disponibles en ese momento y no a las herramientas de codificación en sí. En su opinión, solo las nuevas generaciones de modelos se volvieron lo suficientemente confiables para manejar gran parte de este trabajo por sí mismas.
¿Cómo se dividen las tareas entre humanos y agentes?
Los proyectos siguieron una división de trabajo consistente. Los humanos definieron los objetivos, los criterios de éxito y los métodos de validación, mientras que los agentes manejaron la implementación.
El proyecto hifiasm muestra cómo funcionó esto en la práctica. Hifiasm ensambla un genoma completo a partir de muchos fragmentos cortos. Antes de pedirle a GPT-5.5 que lo optimizara, el investigador construyó una configuración de prueba con conjuntos de datos de entrenamiento y validación separados. El modelo luego encontró cambios que redujeron el tiempo de ejecución en datos reales del genoma humano en casi un 15 por ciento.
HI.SIM, una librería para simular datos genéticos, requirió aún menos participación humana. GPT-5.2 encontró formas de optimizar partes individuales del programa en una sola pasada. Una segunda pasada con un modelo más nuevo encontró más mejoras. Juntos, los cambios redujeron el tiempo de ejecución en alrededor del 31 por ciento sin cambiar la salida.
¿Por qué las reescrituras baratas crean problemas de mantenimiento?
Los autores también proporcionan estimaciones aproximadas de los ahorros potenciales. Si los agentes pudieran resolver entre un cuarto y la mitad de todos los problemas de instalación que afectan al software de investigación, el tiempo de investigación ahorrado en 100 paquetes tendría un valor de entre 600,000 y casi 5 millones de dólares. Solo para NumPy, el reporte estima que los agentes podrían ahorrar alrededor de 650 horas de trabajo de mantenimiento cada año.
El mantenimiento a largo plazo sigue siendo un problema abierto importante junto con la validación y la precisión científica. Las reescrituras de bajo costo podrían fragmentar las comunidades de usuarios y dispersar aún más el tiempo ya limitado de los mantenedores experimentados.
Los equipos tomaron diferentes enfoques respecto a la propiedad y el mantenimiento. Algunos cambios fueron directamente a los proyectos originales. Debido a que STAR ya no recibía mantenimiento, rustar-aligner se trasladó al consorcio de investigación scverse. El autor de FastQC se negó a reemplazar la herramienta original con su reescritura en Rust. En su lugar, el equipo agregó las mejoras encontradas a la versión original en Java, lo cual logró la misma mejora de velocidad de tres veces.
El reporte de campo analiza proyectos completados y se basa en los relatos de las personas involucradas. Sus autores enfatizan que los hallazgos no provienen de un estudio representativo. Aún ven que el principal cuello de botella se aleja de la codificación en sí y se desplaza hacia la validación, la revisión científica y la responsabilidad clara para el mantenimiento y el desarrollo futuro.
El mismo patrón aparece en el desarrollo de software fuera de la investigación. Un estudio de METR encontró que los mantenedores de proyectos reales rechazarían cerca de la mitad de las soluciones que el benchmark ampliamente utilizado SWE-bench Verified califica como aprobadas. Un estudio sobre la frustración de los desarrolladores con el código generado por IA encontró una compensación similar. El tiempo ahorrado al generar código puede gastarse, en cambio, revisándolo.
Vía The Decoder.
