Google utilise les LLM pour rationaliser les migrations de code interne, réalisant des gains de temps significatifs allant jusqu'à 89% :

Comment Google utilise l'IA pour les migrations de code interne

Google a publié un rapport d'expérience sur l'utilisation des LLM pour les migrations de code. Les informaticiens de Google ont constaté que l'utilisation des LLM peut réduire de manière significative le temps nécessaire aux migrations, ainsi que les obstacles au démarrage et à l'achèvement des programmes de migration. En outre, ils ont partagé leurs impressions et les enseignements qu'ils ont tirés de l'utilisation de l'IA pour la migration de code.

Les informaticiens de Google ont utilisé les LLM pour rationaliser les migrations de code internes, réalisant des gains de temps significatifs allant jusqu'à 89 % dans certains cas. Les résultats ont été publiés dans un document intitulé "How is Google using AI for internal code migrations ?" (Comment Google utilise l'IA pour les migrations de code interne ?).

Pour rappel, un grand modèle de langage (LLM) est un type de modèle d'apprentissage automatique conçu pour les tâches de traitement du langage naturel telles que la génération de langage. Les LLM sont des modèles de langage comportant de nombreux paramètres et sont formés par apprentissage auto-supervisé sur une grande quantité de texte. Les modèles modernes peuvent être affinés pour des tâches spécifiques ou guidés par l'ingénierie d'aide.

Selon le rapport de Google, l'accent est mis sur les outils d'IA sur mesure développés pour des domaines de produits spécifiques, tels que les annonces, la recherche, l'espace de travail et YouTube, plutôt que sur les outils d'IA génériques qui fournissent des services largement applicables tels que l'achèvement du code, l'examen du code et la réponse aux questions.

Les migrations de code de Google ont consisté à remplacer les ID 32 bits de la base de code de plus de 500 millions de lignes pour Google Ads par des ID 64 bits, à convertir son ancienne bibliothèque de test JUnit3 en JUnit4 et à remplacer la bibliothèque Joda time par le package standard java.time de Java. La migration de int32 à int64 n'était pas triviale car les identifiants étaient souvent définis de manière générique (int32_t en C++ ou Integer en Java) et n'étaient pas facilement consultables.

Ils existaient dans des dizaines de milliers d'emplacements de code dans des milliers de fichiers. Les modifications devaient être suivies par plusieurs équipes et les changements apportés aux interfaces des classes devaient être pris en compte dans plusieurs fichiers. "L'ensemble de l'effort, s'il était réalisé manuellement, devait nécessiter des centaines d'années d'ingénierie logicielle et une coordination transversale complexe", expliquent les auteurs.


Pour leur flux de travail basé sur le LLM, les ingénieurs logiciels de Google ont mis en œuvre le processus suivant. Un ingénieur d'Ads identifiait un identifiant nécessitant une migration en utilisant une combinaison de recherche de code, de Kythe et de scripts personnalisés. Ensuite, une boîte à outils de migration basée sur LLM, déclenchée par une personne compétente en la matière, était exécutée pour générer des modifications vérifiées contenant du code qui passait les tests unitaires. Ces modifications sont vérifiées manuellement par le même ingénieur et éventuellement corrigées.

Ensuite, les modifications de code sont envoyées à plusieurs réviseurs responsables de la partie de la base de code affectée par les modifications. Il en est ressorti que 80 % des modifications de code figurant dans les listes de modifications (CL) étaient purement le fruit de l'IA, le reste étant constitué de suggestions d'IA rédigées ou modifiées par l'homme.

"Nous avons découvert que dans la plupart des cas, l'homme devait revenir sur au moins quelques modifications apportées par le modèle qui étaient soit incorrectes, soit inutiles", observent les auteurs. "Compte tenu de la complexité et de la nature sensible du code modifié, des efforts doivent être déployés pour que chaque modification soit appliquée avec soin aux utilisateurs."

Sur la base de ce constat, Google a entrepris des travaux supplémentaires sur la vérification pilotée par LLM afin de réduire la nécessité d'un examen détaillé. Même s'il est nécessaire de revérifier le travail du LLM, les auteurs estiment que le temps nécessaire pour achever la migration a été réduit de 50 %. Avec l'aide du LLM, il n'a fallu que trois mois pour migrer 5 359 fichiers et modifier 149 000 lignes de code pour achever la transition JUnit3-JUnit4. Environ 87 % du code généré par l'IA a fini par être validé sans aucun changement. En ce qui concerne le changement de cadre temporel Joda-Java, les auteurs estiment que le gain de temps est de 89 % par rapport au temps de changement manuel prévu, bien qu'aucune spécification n'ait été fournie pour étayer cette affirmation.


Ces résultats permettent de mieux comprendre les déclarations du PDG de Google, Sundar Pichai. Lors de l'annonce des résultats financiers du troisième trimestre 2024, il a dévoilé que plus de 25 % du nouveau code produit par Google est désormais généré par l'intelligence artificielle (IA). Il a déclaré que l'utilisation de l'IA pour le codage permettait de "stimuler la productivité et l'efficacité" au sein de Google.

"Une fois le code généré, il est ensuite vérifié et revu par les employés... Cela permet à nos ingénieurs d'en faire plus et d'aller plus vite... Je suis enthousiasmé par nos progrès et les opportunités qui s'offrent à nous, et nous continuons à nous concentrer sur la création de produits de qualité." a-t-il ajouté.

Ces résultats permettent également d'estimer les performances de l'assistant de codage doté d'IA de Google. Dévoilé le 11 novembre 2024, l'assistant de codage doté d'IA "Jules" serait capable de corriger de manière autonome les bogues des logiciels et de préparer les modifications de code pendant que les développeurs se concentrent sur ce qu'ils veulent réellement construire.

L'agent de codage expérimental alimenté par l'IA est construit sur la...