OpenAI : l'IA booste le code mais pas la véracité scientifique

OpenAI : l'IA booste le code mais pas la véracité scientifique

Les agents de codage IA peuvent moderniser les logiciels de recherche, mais ne peuvent pas juger si la science est correcte.

Un rapport de terrain d'OpenAI et de partenaires académiques montre que les agents de codage peuvent mettre à jour et accélérer les logiciels de recherche vieillissants. Cependant, une grande partie du travail se déplace de l'écriture de code à la vérification des résultats.

De nombreux outils de recherche largement utilisés ont commencé comme du code de soutien pour un seul article. De petites équipes académiques les ont souvent écrits sans le temps ni les ressources nécessaires pour des tests, une maintenance ou une optimisation appropriés. Le résultat est un logiciel fragile qui reste critique pour des domaines entiers mais nécessite des réparations constantes. Un rapport de terrain d'OpenAI et de partenaires académiques suggère que les agents de codage IA pourraient aider à combler cette lacune.

Le rapport documente huit études de cas, principalement en biologie, dans lesquelles des groupes de recherche ont utilisé des agents de codage tels que Codex et Claude Code. Les projets vont de la maintenance de base et de l'optimisation ciblée à des réécritures complètes dans des langages de programmation modernes.

Accélérations impressionnantes

Les agents de codage ont permis des accélérations de plus de 60 fois.

Un des projets les plus simples a consisté à moderniser cyvcf2, une bibliothèque Python pour lire des données génétiques. GPT-5.5 a remplacé son processus de construction et d'installation obsolète par un processus moderne.

La migration de MHCflurry a été beaucoup plus complexe. MHCflurry est un modèle d'immunologie qui prédit quels cibles les cellules immunitaires vont reconnaître. Claude Code et Codex ont alterné entre les rôles de développeur et de réviseur tout en transférant environ 10 000 lignes de code de TensorFlow à PyTorch.

Le projet rustar-aligner était plus ambitieux. Il a reconstruit STAR à partir de zéro en Rust. STAR cartographie les lectures de séquençage des cellules aux emplacements correspondants dans un génome. L'original contient plus de 20 000 lignes de C et C++ et n'est plus activement maintenu, même s'il reste une partie intégrante de nombreux pipelines de recherche.

Pour vérifier si la réécriture se comportait comme l'original, l'équipe a testé les deux outils sur 10 000 courtes lectures de séquençage provenant de cellules de levure. Pour les lectures simples, rustar-aligner a produit le même résultat que STAR dans 99,815 % des cas. Pour les lectures appariées, le taux d'accord était de 99,883 %.

La comparaison couvrait plus que l'emplacement cartographié dans le génome. Elle incluait également plusieurs autres champs clés que les deux programmes produisent pour chaque lecture. Aucun des outils n'a cartographié des lectures que l'autre n'a pas réussi à cartographier.

RustQC a offert la plus grande accélération en combinant 15 outils de contrôle de qualité distincts en un seul programme. Sur un grand ensemble de données, le temps d'exécution est passé de 15 heures et 34 minutes à 14 minutes et 54 secondes, soit une accélération de plus de 60 fois.

Un autre projet, HelixForge, a remplacé un outil de génération de données génomiques synthétiques par une version fonctionnant sur des GPU. Dans un test utilisant des données d'un donneur et une section de génome de dix millions de paires de bases, HelixForge a complété l'ensemble du pipeline 59,6 fois plus rapidement que BamSurgeon. L'étape de calcul principale à elle seule a fonctionné 98,6 fois plus vite.

La rapidité du code ne garantit pas la qualité scientifique

À travers les études de cas, les agents ont accompli des tâches bien définies rapidement mais n'ont pas pu juger de manière fiable si leur travail était scientifiquement correct. Même lorsque leur code contenait des erreurs, les systèmes le présentaient souvent avec une confiance totale.

"Avec les agents de codage, il est assez facile d'aller vite ; pour l'instant, pour aller loin en science, il y a encore besoin de conseils d'experts, de compréhension, de goût et de soin", écrit Brent Pedersen, développeur de cyvcf2.

Philip Ewels, qui a dirigé RustQC, décrit les agents comme "éloquents, convaincants et assurément erronés de manière à être faciles à manquer". Il n'a jamais permis aux modèles de juger l'exactitude de leur propre travail et a plutôt construit un cadre de test indépendant.

L'accélération est venue d'une série de petits changements de code plutôt que d'une seule optimisation.

L'étude de cas bayesm montre à quel point ces erreurs peuvent être difficiles à détecter. Sa réécriture en Rust a fonctionné entre deux et vingt fois plus vite que l'original, mais les premières versions de deux méthodes avancées contenaient des erreurs difficiles à repérer à partir de la sortie seule.

Dans une méthode, l'agent a inversé un paramètre de contrôle clé, entraînant le programme à utiliser le réciproque des valeurs prévues. Un bug séparé a affecté le calcul lui-même. Les chercheurs ne l'ont découvert qu'après avoir effectué un test de calibration détaillé contre des milliers de jeux de données synthétiques avec des résultats connus.

Une calibration statistique a permis de détecter un bug que des tests d'accord antérieurs avaient manqué.

Une autre méthode, appelée HART, a produit des résultats plausibles dans l'ensemble mais contenait encore plusieurs défauts. Ceux-ci incluaient des calculs inutilement coûteux et un facteur de correction mal échelonné. Des résultats de test plausibles à eux seuls ne pouvaient pas établir que le code était correct.

Une tentative antérieure de transférer MHCflurry vers PyTorch avait échoué début 2025. Le développeur Sergey Feldman attribue maintenant l'échec aux modèles disponibles à l'époque plutôt qu'aux outils de codage eux-mêmes. À son avis, seules les générations de modèles plus récentes sont devenues suffisamment fiables pour gérer une grande partie de ce travail de manière autonome.

Les humains définissent les tests tandis que les agents écrivent le code

Les projets ont suivi une division du travail cohérente. Les humains ont défini les objectifs, les critères de succès et les méthodes de validation, tandis que les agents ont géré l'implémentation.

Le projet hifiasm montre comment cela a fonctionné en pratique. Hifiasm assemble un génome complet à partir de nombreux courts fragments. Avant de demander à GPT-5.5 de l'optimiser, le chercheur a construit un cadre de test avec des ensembles de données d'entraînement et de validation séparés. Le modèle a ensuite trouvé des changements qui ont réduit le temps d'exécution sur des données génomiques humaines réelles de près de 15 %.

HI.SIM, une bibliothèque pour simuler des données génétiques, a nécessité encore moins d'implication humaine. GPT-5.2 a trouvé des moyens d'optimiser des parties individuelles du programme en un seul passage. Un second passage avec un modèle plus récent a trouvé d'autres améliorations. Ensemble, les changements ont réduit le temps d'exécution d'environ 31 % sans changer la sortie.

Des réécritures peu coûteuses créent un problème de maintenance

Les auteurs fournissent également des estimations approximatives des économies potentielles. Si les agents pouvaient résoudre entre un quart et la moitié de tous les problèmes d'installation affectant les logiciels de recherche, le temps de recherche économisé sur 100 paquets vaudrait entre 600 000 $ et près de 5 millions de dollars. Pour NumPy seul, le rapport estime que les agents pourraient économiser environ 650 heures de travail de maintenance chaque année.

La maintenance à long terme reste un problème majeur aux côtés de la validation et de l'exactitude scientifique. Des réécritures à faible coût pourraient fragmenter les communautés d'utilisateurs et étendre encore plus le temps déjà limité des mainteneurs expérimentés.

Les équipes ont adopté différentes approches en matière de propriété et de maintenance. Certains changements ont été directement intégrés dans les projets originaux. Comme STAR n'était plus maintenu, rustar-aligner a été transféré au consortium de recherche scverse. L'auteur de FastQC a refusé de remplacer l'outil original par sa réécriture en Rust. L'équipe a plutôt ajouté les améliorations qu'elle avait trouvées à la version originale en Java, qui a atteint le même triplement de vitesse.

Le rapport de terrain revient sur des projets achevés et s'appuie sur les témoignages des personnes impliquées. Ses auteurs soulignent que les résultats ne proviennent pas d'une étude représentative. Ils voient toujours le principal goulot d'étranglement se déplacer de la codification elle-même vers la validation, la révision scientifique et la responsabilité claire en matière de maintenance et de développement futur.

Le même schéma apparaît dans le développement de logiciels en dehors de la recherche. Une étude de METR a révélé que les véritables mainteneurs de projets rejetteraient environ la moitié des solutions que le benchmark SWE-bench Verified évalue comme réussies.

Une étude sur la frustration des développeurs face au code généré par l'IA a trouvé un compromis similaire. Le temps économisé lors de la génération de code peut plutôt être dépensé à le réviser. Le projet curl a fermé son programme de récompense pour les bogues après que les rapports de vulnérabilité générés par l'IA aient consommé le temps des mainteneurs sans produire de résultats utiles.

Le rapport de terrain fait partie de l'effort plus large d'OpenAI dans le domaine scientifique. L'entreprise a créé une équipe scientifique dédiée dirigée par Kevin Weil, qui s'attend à ce que 2026 soit pour la science ce que 2025 a été pour l'ingénierie logicielle. En avril, OpenAI a introduit GPT-Rosalind, un modèle pour la recherche en sciences de la vie, et a publié un plugin de sciences de la vie disponible gratuitement pour Codex, qui connecte les modèles à plus de 50 bases de données publiques et outils de biologie.