La computación científica de OpenAI se acelera, pero la verificación se convierte en el cuello de botella

OpenAI publicó ocho estudios de caso sobre computación científica el 28 de julio, que muestran a agentes de programación abordando proyectos que van desde el mantenimiento rutinario hasta reescrituras completas de software de genómica. Los resultados ofrecen algunas mejoras de rendimiento llamativas. También revelan una limitación más difícil: producir código se está volviendo más fácil más rápido de lo que se puede validar.

El nuevo informe de campo examina proyectos realizados principalmente en las ciencias de la vida. Cinco utilizaron solo Codex, mientras que tres combinaron Codex con Claude Code. Los investigadores aplicaron los agentes al empaquetado, la optimización, la migración de frameworks, la traducción entre lenguajes y rediseños centrados en GPU.

Esta combinación hace que el informe científico de OpenAI sea más útil que otro benchmark de programación. Estos agentes trabajaron con software con consecuencias científicas reales, no con ejercicios de programación aislados. Sin embargo, OpenAI y los investigadores participantes no reprodujeron de forma independiente todos los benchmarks informados. La mayoría de los resultados siguen siendo relatos específicos de cada caso proporcionados por los equipos responsables de cada proyecto.

Por tanto, el conflicto central no es Codex contra Claude Code. Es la implementación rápida frente a la verificación científica lenta. Los agentes ya pueden modificar miles de líneas, traducir sistemas maduros y generar extensiones estadísticas plausibles. Los científicos aún deben determinar si esos cambios preservan el significado de un experimento.

Anthropic ha llegado a una conclusión similar desde otra dirección. Su trabajo sobre agentes de larga duración sostiene que la programación científica autónoma depende de oráculos de prueba, mecanismos objetivos que indican a un agente si está avanzando. Ambas empresas apuntan a la misma división del trabajo. Los agentes implementan, mientras los expertos especifican, prueban y evalúan.

La computación científica de OpenAI va más allá de las sugerencias de código

El cambio más importante del informe es la escala de trabajo que los científicos están dispuestos a delegar.

Las herramientas de programación con IA comenzaron como sistemas de autocompletado que sugerían una función o completaban una línea. En cambio, los proyectos del informe de OpenAI utilizaron agentes en repositorios completos. Estos sistemas podían inspeccionar código existente, editar múltiples componentes, ejecutar pruebas, interpretar fallos y seguir trabajando hacia un resultado definido.

Los ocho estudios de caso cubren seis tipos de proyectos que se solapan. Incluyen mantenimiento ligero, optimización específica, migración de compatibilidad, traducción a nuevos lenguajes de programación, reescrituras centradas en el rendimiento y nuevas capacidades científicas.

Un proyecto modernizó cyvcf2, una biblioteca de Python para leer y escribir archivos de variantes genómicas. Tras una década de cambios en Python, la gestión de dependencias y los sistemas de empaquetado, la biblioteca se había vuelto más difícil de compilar y publicar. GPT-5.5 ayudó a sustituir su proceso de empaquetado heredado por un sistema unificado, y los cambios se integraron en el proyecto upstream.

Ese ejemplo importa porque el mantenimiento rara vez recibe el mismo reconocimiento académico que un método o una publicación nuevos. Sin embargo, los sistemas de compilación obsoletos pueden impedir que otros científicos instalen o reutilicen software de investigación valioso. Los agentes de programación pueden asumir trabajo necesario, repetitivo y difícil de financiar.

El caso de MHCflurry fue mucho más allá. MHCflurry predice qué fragmentos de proteínas probablemente aparecerán en las superficies celulares, una tarea relevante para la inmunología y la investigación del cáncer. Sus dependencias envejecidas de TensorFlow y Keras generaban un problema de mantenimiento creciente.

Los agentes ayudaron a migrar el paquete a PyTorch preservando los modelos publicados y sus predicciones. Según los colaboradores, la reescritura modificó casi 10.000 líneas en aproximadamente 130 archivos. Se publicó en MHCflurry 2.2.0 después de que los revisores verificaran que los pesos existentes se cargaban correctamente y que las predicciones se mantenían dentro de las tolerancias definidas.

Estos proyectos representan el centro práctico de la ciencia con IA agéntica. El agente no decide si una hipótesis biológica es significativa. Reduce el esfuerzo de ingeniería necesario para mantener utilizable el software que respalda esa hipótesis.

Los casos de OpenAI también muestran por qué las herramientas científicas conocidas son objetivos atractivos. Los paquetes maduros contienen comportamientos funcionales, suites de pruebas existentes y resultados de referencia. Estos artefactos dan a los investigadores una base para evaluar los cambios de un agente.

El desarrollo científico desde cero es menos indulgente. Cuando no existe una implementación aceptada, los investigadores deben diseñar simulaciones, comprobaciones estadísticas u otros criterios de aceptación antes de confiar en el resultado. Cuanto menos objetivo sea el objetivo, más difícil se vuelve la supervisión del agente.

Por ello, el informe describe avances con límites. Los agentes gestionaron la implementación en superficies más amplias que los asistentes convencionales. No eliminaron la necesidad de orientación científica y rindieron mejor cuando el éxito podía medirse externamente.

El código de investigación antiguo se ha convertido en una infraestructura costosa

Los agentes de programación llegan en un momento en que el crecimiento de los datos ha hecho menos tolerable el software científico descuidado.

El software de investigación suele comenzar como material de apoyo para un artículo. Un pequeño equipo académico desarrolla suficiente código para probar un método, publica el resultado y pasa al siguiente problema financiado. Otros investigadores pueden adoptar ese código hasta que un prototipo se convierte silenciosamente en infraestructura compartida.

Los incentivos siguen desalineados. Las universidades recompensan más directamente los artículos, las subvenciones y las contribuciones científicas novedosas que el empaquetado, la documentación, las pruebas o las actualizaciones de dependencias. El apoyo profesional de ingeniería de software también escasea en muchos laboratorios.

La evidencia recopilada antes de la actual ola de IA agéntica muestra la escala del problema. Un estudio sobre código de investigación probó más de 9.000 scripts de R publicados en entornos de computación limpios. Encontró que el 74 por ciento falló en la primera ejecución, mientras que el 56 por ciento seguía fallando después de una limpieza automatizada.

Un examen independiente de 98 herramientas de biología computacional concluyó que el 57,1 por ciento fallaba cuando los investigadores seguían las instrucciones de instalación documentadas. Otro 27,6 por ciento no podía instalarse ni siquiera después de una intervención manual. Un fallo de instalación automática añadía unos 70 minutos de trabajo de media, según el estudio sobre software ómico.

Estas cifras no significan que cada fallo corrompiera un resultado científico. Muestran cuánto tiempo de investigación puede desaparecer antes de que siquiera comience el análisis. Dependencias rotas, detalles de configuración ausentes y supuestos sin documentar convierten la reutilización de software en un trabajo de investigación.

La genómica hace que esta presión sea especialmente visible. Los costes de secuenciación han caído más rápido que los costes de análisis posteriores durante la última década. Los laboratorios pueden generar datos a escalas que tensionan el almacenamiento, la computación y las canalizaciones de software utilizadas para procesarlos.

El problema no es simplemente código lento. Una canalización de análisis frágil puede reducir la reproducibilidad, dificultar la revisión de resultados antiguos y crear diferencias sutiles entre laboratorios. La implementación pasa a formar parte del método experimental, incluso cuando los incentivos académicos la tratan como un artefacto desechable.

La ciencia con IA agéntica cambia la economía de afrontar esta deuda. Un investigador puede pedir a un agente que actualice dependencias, añada pruebas, migre frameworks o inspeccione cuellos de botella de rendimiento. El trabajo que antes competía con la fecha límite de un artículo o una subvención se vuelve más fácil de intentar.

Ese cambio ejerce presión sobre universidades, financiadores y líderes de laboratorio tanto como sobre los desarrolladores de software. Si la implementación se vuelve menos costosa, las expectativas aumentan. Los investigadores tendrán menos excusas para distribuir código que no puede instalarse, probarse o reproducirse.

Sin embargo, unos costes de desarrollo más bajos no crean automáticamente infraestructura duradera. Una reescritura generada aún necesita revisores, publicaciones, documentación, soporte para usuarios y mantenimiento futuro. El agente puede reducir una acumulación de trabajo pendiente sin crear una institución responsable del resultado.

Para los laboratorios que intentan conservar decisiones, benchmarks y contexto experimental, una base de conocimiento de ingeniería consultable puede respaldar esa custodia. No puede validar resultados científicos, pero sí puede mantener conectadas las decisiones de diseño y las pruebas de revisión con el código.

Las mejoras más rápidas llegaron con respuestas claras

Los agentes obtuvieron sus mejores resultados cuando los investigadores podían definir el éxito antes de que comenzara la implementación.

HI.SIM ofrece el ejemplo más claro. El simulador genómico contenía cálculos repetidos, copias de datos innecesarias y muchas escrituras pequeñas de archivos. GPT-5.2 recibió una solicitud de optimización zero-shot y produjo cambios locales sin más intervención humana.

En una suite de benchmarks de cuatro cargas de trabajo, los colaboradores informaron de una reducción del 30,97 por ciento en el tiempo de ejecución agregado. El software optimizado produjo resultados idénticos byte a byte, lo que significa que cada byte de salida coincidía con la versión de referencia. Esa comparación estricta redujo notablemente la ambigüedad sobre si la velocidad había cambiado la ciencia.

El proyecto hifiasm utilizó un objetivo más flexible. Hifiasm ensambla genomas a partir de lecturas largas de secuenciación de ADN, y su tiempo de ejecución se concentra en varias operaciones computacionalmente exigentes. GPT-5.5 optimizó rutas críticas seleccionadas dentro de la implementación existente en C.

Los colaboradores informaron de una reducción del 25,1 por ciento en el tiempo de ejecución con datos sintéticos reservados para evaluación. En lecturas registradas del cromosoma humano 20, la reducción fue del 14,7 por ciento. Los cambios también debían cumplir los umbrales de ordenación de lecturas definidos antes de la evaluación.

RustQC produjo la mayor aceleración informada. Sustituyó 15 pasos de control de calidad posteriores al alineamiento en un flujo de trabajo de secuenciación de ARN por un programa Rust de una sola pasada. En un conjunto de datos con 186 millones de lecturas, el tiempo de ejecución secuencial de las tareas cayó de 15 horas y 34 minutos a 14 minutos y 54 segundos.

Ese resultado representa una reducción de más de 60 veces. El tráfico de disco informado también cayó de 2,5 terabytes a 0,1 terabytes, mientras que los resultados numéricos probados siguieron siendo equivalentes. Los colaboradores también informaron de una ejecución siete veces más rápida para Trim Galore y mejoras de tres veces para FastQC-Rust.

HelixForge adoptó un enfoque centrado en hardware. El proyecto sustituyó una canalización de CPU para insertar mutaciones conocidas en lecturas de secuenciación por una implementación nativa de GPU. Estos datos sintéticos ayudan a los investigadores a comprobar si las herramientas de detección de variantes pueden encontrar mutaciones en ubicaciones conocidas.

En un donante y una región de 10 megabases, los colaboradores informaron de que la fase de edición se ejecutó 98,6 veces más rápido. El tiempo de ejecución de extremo a extremo mejoró 59,6 veces. El error medio de frecuencia de mutación cayó de 0,076 a 0,034, mientras que un artefacto de realineamiento detectable fue casi eliminado.

Estos resultados son sustanciales, pero no deberían convertirse en afirmaciones universales sobre la productividad de los agentes de programación. El informe completo etiqueta explícitamente sus hallazgos numéricos como informados por los colaboradores y específicos de cada caso. Los equipos utilizaron modelos, alcances de proyecto, conjuntos de datos y objetivos de validación diferentes.

El patrón importa más que una media combinada. La equivalencia exacta de resultados funcionó bien para la optimización acotada. Las tolerancias de predicción ayudaron con la migración de frameworks. Los conjuntos de datos simulados con respuestas conocidas respaldaron proyectos que introducían un comportamiento nuevo.

Este es el mecanismo detrás de los proyectos exitosos de computación científica de OpenAI. Los agentes no reconocieron de forma independiente la verdad científica. Los investigadores tradujeron los requisitos científicos en pruebas ejecutables y luego utilizaron agentes para explorar el espacio de implementación.

Los casos también se basaron en una iteración por etapas. Los equipos dividieron objetivos amplios en cambios más pequeños, construyeron benchmarks intermedios y revisaron sus sistemas de validación a medida que aparecían fallos. Las implementaciones iniciales llegaron rápido, pero las sutiles diferencias numéricas y los casos límite realistas consumieron más tiempo.

Ese último tramo impide que el informe respalde una narrativa simple de automatización. La ciencia con IA agéntica acelera la parte intermedia del proceso, donde una especificación se convierte en código. No elimina el trabajo necesario para crear la especificación ni para establecer después evidencia convincente.

El código plausible no es evidencia científica

La advertencia más contundente del informe es que un agente puede sonar seguro de sí mismo mientras produce un resultado científicamente defectuoso.

El caso de bayesm-rs expone claramente este riesgo. Los investigadores utilizaron GPT-5.2 para traducir modelos estadísticos bayesianos y muestreadores seleccionados de un paquete de R a Rust. La reescritura base contaba con una implementación de referencia madura, lo que permitió al equipo comparar el comportamiento posterior con el original.

Los problemas aparecieron cuando el agente añadió nuevas extensiones estadísticas. Los resultados iniciales parecían plausibles, pero las implementaciones contenían defectos en los muestreadores y en la lógica específica de HART. Los revisores corrigieron esos problemas antes de que los muestreadores evaluados superaran las comprobaciones de convergencia y de calibración basada en simulaciones.

Un gráfico plausible o un programa estable no basta. El software estadístico puede ejecutarse correctamente mientras muestrea la distribución equivocada, aplica una simplificación inadecuada u oculta sesgos tras promedios de apariencia razonable.

El proyecto rustar-aligner presentó otro reto de verificación. STAR, un alineador de secuenciación de ARN ampliamente utilizado, contiene más de 20.000 líneas de comportamiento acumulado en C y C++. Los agentes ayudaron a construir un reemplazo en Rust destinado a reproducir ese comportamiento.

En 10.000 lecturas de secuenciación de ARN de levadura, los colaboradores informaron tasas de concordancia del 99,815 por ciento para datos single-end y del 99,883 por ciento para datos paired-end en varios campos de alineamiento. Estas cifras suenan cercanas a una equivalencia completa. Sin embargo, en los pipelines científicos, las discrepancias restantes todavía pueden requerir investigación.

Una diferencia puede reflejar una decisión de implementación inocua, un error en la reescritura o una convención no documentada en el original. Un agente no puede resolver esa cuestión a partir de un porcentaje por sí solo. Los expertos del dominio deben rastrear las diferencias a través de análisis posteriores y decidir qué comportamiento es científicamente aceptable.

Esta limitación también aparece en evaluaciones independientes. FrontierSWE prueba agentes de programación en problemas amplios de implementación y de nivel de investigación. El informe señala que los agentes no completaron por completo ninguna de sus cinco tareas de implementación desde cero, lo que refuerza la brecha entre el trabajo en repositorios y la ingeniería abierta.

El riesgo aumenta cuando el código generado afecta al comportamiento científico, en lugar de al empaquetado o al rendimiento. Las comparaciones exactas se vuelven imposibles cuando un proyecto introduce un método nuevo. Los investigadores deben entonces elegir simulaciones, tolerancias y medidas de resultados que podrían pasar por alto modos de fallo ocultos.

Los datos reales añaden más presión. Las cargas de trabajo sintéticas pequeñas aceleran la iteración, pero los colaboradores de OpenAI encontraron repetidamente casos límite adicionales al pasar a conjuntos de datos realistas. Una suite de validación solo puede detectar el comportamiento que fue diseñada para examinar.

La investigación más amplia de Anthropic sobre agentes de programación respalda la necesidad de experiencia especializada. Su análisis de aproximadamente 400.000 sesiones descubrió que las personas tomaban la mayoría de las decisiones de planificación, mientras Claude tomaba la mayoría de las decisiones de ejecución. Los expertos del dominio obtuvieron mejores resultados porque podían reconocer errores y recuperarse de malentendidos.

Por lo tanto, la distinción competitiva entre Codex y Claude Code es secundaria. Ambos avanzan hacia una ejecución más larga y autónoma. La competencia importante se da entre la creciente autonomía de los agentes y la capacidad de las organizaciones científicas para auditar el trabajo resultante.

Los investigadores también deberían separar la verificación del código de la validación científica. Las pruebas unitarias pueden confirmar que una función se comporta de forma coherente. No pueden establecer que los supuestos biológicos subyacentes sean apropiados, que el conjunto de datos sea representativo o que la interpretación respalde una afirmación publicada.

Los hallazgos científicos de OpenAI sitúan a los expertos en un nuevo papel. Dedican menos tiempo a teclear implementaciones y más a diseñar criterios de aceptación, seleccionar conjuntos de datos de referencia, investigar discrepancias y decidir si la evidencia es lo bastante sólida como para publicar.

No se trata de eliminar el trabajo humano. Es una transferencia de trabajo desde la construcción hacia el juicio. Los laboratorios que traten la salida de los agentes como código terminado pasarán por alto la lección central del informe.

Las reescrituras más rápidas pueden fragmentar las comunidades científicas

La implementación barata crea un segundo problema: demasiados proyectos técnicamente impresionantes sin propietarios claros.

El software científico conlleva más que código fuente. Los proyectos maduros acumulan promesas de compatibilidad, convenciones de nomenclatura, documentación, expectativas de los usuarios y soluciones para conjuntos de datos inusuales. Muchas de estas restricciones nunca aparecen en una especificación formal.

Un agente puede traducir funciones a Rust o reemplazar un antiguo framework de aprendizaje automático. No puede heredar automáticamente la confianza asociada al proyecto original. Los usuarios necesitan saber quién revisará incidencias, publicará actualizaciones, corregirá vulnerabilidades y gestionará futuros cambios en el ecosistema circundante.

El informe de OpenAI identifica la coordinación temprana con los mantenedores como la vía preferida cuando resulta práctica. La modernización de cyvcf2 se incorporó al proyecto original. La migración de framework de MHCflurry también se publicó aguas arriba, preservando un hogar reconocido para el desarrollo futuro.

Rustar-aligner siguió una vía diferente porque STAR ya no recibía mantenimiento activo. El reemplazo pasó a estar bajo la tutela de una nueva comunidad. Este acuerdo puede funcionar, pero requiere un propietario visible y un plan de mantenimiento creíble.

El peligro es una oleada de reescrituras paralelas. Si varios laboratorios generan nuevas versiones de una herramienta de confianza, cada versión puede divergir en su comportamiento. Los usuarios se dividen entre paquetes, mientras el limitado grupo de revisores expertos se reparte entre más bases de código.

La fragmentación es especialmente arriesgada cuando distintas implementaciones producen resultados científicos ligeramente diferentes. Los datos generados por un laboratorio podrían dejar de combinarse limpiamente con los de otro. Los estudios longitudinales también podrían cambiar de comportamiento tras una actualización del pipeline.

Por tanto, una programación más rápida incrementa el valor de la gobernanza. Los proyectos necesitan reglas de contribución, suites de benchmarks, procesos de publicación, políticas de compatibilidad y atribución clara. Es posible que los financiadores deban respaldar el mantenimiento como infraestructura científica, en lugar de como una obligación informal.

También existe una dimensión de seguridad. Los agentes de programación suelen operar con acceso a repositorios, gestores de paquetes, sistemas de pruebas y recursos informáticos. Una mayor autonomía deja más margen para que un agente malinterprete una solicitud o interactúe con una dependencia insegura. La validación científica no sustituye la revisión ordinaria de seguridad.

Los esfuerzos de computación científica de OpenAI afrontarán la misma cuestión institucional que el software de código abierto en general. ¿Quién rinde cuentas cuando un cambio asistido por un agente parece correcto, supera las pruebas disponibles y posteriormente produce un error con consecuencias?

El informe de campo no resuelve esa cuestión. Recomienda colaboración y tutela, pero estas dependen de financiación, incentivos y mantenedores dispuestos. La ciencia con IA agéntica puede reducir el trabajo de escribir un parche. No puede garantizar que alguien siga siendo responsable cinco años después.

Esta incertidumbre debería influir en la selección de proyectos. Actualizar una biblioteca con mantenimiento activo junto a su comunidad es distinto de publicar una reescritura competidora. Una mejora de velocidad por sí sola no justifica romper la compatibilidad ni crear una nueva carga de mantenimiento.

Los científicos que dirigen agentes deberían empezar por identificar el futuro hogar del trabajo. La validación demuestra que una publicación cumple hoy los criterios definidos. La tutela determina si los usuarios pueden seguir confiando en ella después de que cambien las dependencias, los conjuntos de datos y las prácticas de investigación.

Tres señales mostrarán si el modelo funciona

La siguiente etapa debe demostrar que estos proyectos aislados pueden convertirse en una práctica científica repetible.

La primera señal es la replicación independiente. OpenAI describe su informe como retrospectivo y exploratorio, y los equipos contribuyentes siguen siendo responsables de las afirmaciones específicas de cada proyecto. Grupos externos deberían reproducir los benchmarks principales en hardware, conjuntos de datos y flujos de trabajo posteriores adicionales.

La replicación reforzaría el argumento de que los agentes de programación pueden modernizar la computación científica de forma fiable. Las grandes diferencias de rendimiento que se reduzcan fuera del entorno original debilitarían las afirmaciones amplias de productividad, incluso si los proyectos individuales siguen siendo útiles.

La segunda señal es la adopción aguas arriba. Más cambios asistidos por agentes deberían incorporarse a proyectos establecidos mediante procesos ordinarios de revisión, pruebas y publicación. La aceptación aguas arriba demuestra que los mantenedores consideran el trabajo compatible con los requisitos técnicos y comunitarios del software.

Una colección creciente de reescrituras desvinculadas sugeriría lo contrario. Mostraría que los agentes pueden generar alternativas más rápido de lo que las comunidades pueden evaluarlas o absorberlas. Ese resultado podría mejorar la experimentación y, al mismo tiempo, hacer menos coherente la infraestructura compartida.

La tercera señal es el desarrollo de prácticas estándar de validación. Los campos científicos necesitan arneses de pruebas reutilizables, conjuntos de datos de referencia, políticas de tolerancia y registros de procedencia para los cambios asistidos por agentes. Estos sistemas deben examinar el significado científico, no solo si el código se ejecuta.

La competencia reciente podría acelerar ese trabajo. Anthropic ha puesto énfasis en la recuperación determinista, los oráculos de prueba y los artefactos auditables para agentes científicos. Un sistema de software científico de 2026 publicado en Nature también refleja el creciente interés por los agentes que ayudan a los expertos del dominio a producir software empírico.

El enfoque ganador no será el modelo que escriba más código. Será el flujo de trabajo que haga visibles los errores, preserve la evidencia y asigne responsabilidades tras el despliegue.

Para los desarrolladores, esto significa construir infraestructura de evaluación antes de añadir más autonomía. Para los líderes de investigación, significa tratar el tiempo de verificación como un coste de proyecto de primera clase. Para los financiadores, significa respaldar a los mantenedores y los benchmarks compartidos junto con el acceso a los modelos.

Los trabajadores del conocimiento fuera de la ciencia también deberían prestar atención. El patrón subyacente se aplica siempre que el software codifica juicio profesional. Un agente puede acelerar la implementación en finanzas, ingeniería, políticas públicas u operaciones. Un experto del dominio aún debe definir la corrección e investigar las excepciones.

La computación científica de OpenAI está pasando de la demostración a la prueba institucional. Los ocho proyectos muestran que los agentes pueden completar trabajos que antes exigían un esfuerzo considerable de ingeniería especializada. También muestran que una implementación más rápida hace más visibles la verificación y la tutela, no menos necesarias.

El siguiente paso práctico es elegir un proyecto acotado con una sólida salida de referencia. Defina los criterios de aceptación antes de que el agente edite nada. Registre cada benchmark, discrepancia y decisión humana. Después, pregúntese si la evidencia resultante convencería a un revisor independiente.

Esa cuestión importa más que la rapidez con la que apareció la primera implementación. Si las organizaciones de investigación pueden escalar una revisión fiable junto con la ciencia de IA basada en agentes, el software científico podrá avanzar más rápido y ser más sostenible. Si no pueden, la deuda técnica del mañana simplemente se generará a mayor velocidad.