Google, que vende software de IA con tanto entusiasmo vertiginoso como Microsoft, informa que probó su propia mezcla de IA y salió del laboratorio con un agradable sabor de boca.
en un papel preimpresoLos científicos informáticos de Google Stoyan Nikolov, Daniele Codecasa, Anna Sjovall, Maxim Tabachnyk, Satish Chandra, Siddharth Taneja y Celal Ziftci responden a la pregunta planteada por el título del artículo: «¿Cómo utiliza Google la IA para las migraciones de código interno?»
Las mentes inquisitivas quieren saber, especialmente después de que Amazon afirmó que utilizó su asistente de codificación Q Developer AI para salvar cientos de millones migrando aplicaciones Java 8 a Java 17.
Los ingenieros de software de Chocolate Factory antes mencionados intentan satisfacer dicha curiosidad contando cómo aplicaron modelos de lenguaje grande (LLM) –IA en el lenguaje común– para acelerar el proceso de mover código de un entorno a otro.
«Vemos evidencia de que el uso de LLM puede reducir significativamente el tiempo necesario para las migraciones y puede reducir las barreras para comenzar y completar programas de migración», observan los autores en su artículo.
Se centran en herramientas de IA personalizadas desarrolladas para áreas de productos específicas, como publicidad, búsqueda, espacio de trabajo y YouTube, en lugar de herramientas de IA genéricas que brindan servicios de amplia aplicación, como finalización de código, revisión de código y respuesta a preguntas.
Las migraciones de código de Google implicaron: cambiar los ID de 32 bits en el código base de más de 500 millones de líneas de Google Ads a ID de 64 bits; convirtiendo su antigua biblioteca de pruebas JUnit3 a JUnit4; y reemplazar la biblioteca de tiempo Joda con el paquete java.time estándar de Java.
La migración de int32 a int64, explican los empleados de Google, no fue trivial ya que los ID a menudo se definían genéricamente (int32_t en C++ o Integer en Java) y no era fácil buscarlos. Existían en decenas de miles de ubicaciones de códigos en miles de archivos. Se debía realizar un seguimiento de los cambios en varios equipos y se debían considerar los cambios en las interfaces de clase en varios archivos.
«Se esperaba que todo el esfuerzo, si se hacía manualmente, requería cientos de años de ingeniería de software y una compleja coordinación entre equipos», explican los autores.
Para su flujo de trabajo basado en LLM, los ingenieros de software de Google implementaron el siguiente proceso.
Un ingeniero de Ads identificaría una identificación que necesita migración utilizando una combinación de búsqueda de código, Kythey guiones personalizados.
Luego, se ejecutó un kit de herramientas de migración basado en LLM, activado por alguien con conocimientos en la materia, para generar cambios verificados que contenían código que pasó las pruebas unitarias. Esos cambios serían verificados manualmente por el mismo ingeniero y potencialmente corregidos.
A partir de entonces, los cambios de código se enviarán a varios revisores que son responsables de la parte del código base afectada por los cambios.
El resultado fue que el 80 por ciento de las modificaciones de código en las listas de cambios (CL) fueron puramente producto de la IA; el resto fueron sugerencias de IA escritas o editadas por humanos.
«Descubrimos que en la mayoría de los casos, el ser humano necesitaba revertir al menos algunos cambios realizados por el modelo que eran incorrectos o innecesarios», observan los autores. «Dada la complejidad y la naturaleza sensible del código modificado, se debe dedicar esfuerzo a implementar cuidadosamente cada cambio para los usuarios».
En base a esto, Google emprendió más trabajo en la verificación impulsada por LLM para reducir la necesidad de una revisión detallada.
Incluso con la necesidad de volver a verificar el trabajo del LLM, los autores estiman que el tiempo necesario para completar la migración se redujo en un 50 por ciento.
Con la asistencia de LLM, solo tomó tres meses migrar 5359 archivos y modificar 149 000 líneas de código para completar la transición JUnit3-JUnit4. Aproximadamente el 87 por ciento del código generado por la IA terminó siendo confirmado sin cambios.
En cuanto al cambio del sistema de tiempo Joda-Java, los autores estiman un ahorro de tiempo del 89 por ciento en comparación con el tiempo de cambio manual proyectado, aunque no se proporcionaron detalles específicos que respalden esa afirmación.
«Los LLM ofrecen una importante oportunidad para ayudar, modernizar y actualizar grandes bases de código», concluyen los autores. «Vienen con mucha flexibilidad y, por lo tanto, una variedad de tareas de transformación de código se pueden enmarcar en un flujo de trabajo similar y lograr el éxito. Este enfoque tiene el potencial de cambiar radicalmente la forma en que se mantiene el código en las grandes empresas».
Los empleados de Google también enfatizan que los LLM deben verse como complementarios a las técnicas de migración tradicionales que se basan en árboles de sintaxis abstracta (AST) y búsquedas tipo grep. Señalan que es posible que se necesiten herramientas adicionales para evitar que el proceso de revisión humana se convierta en un cuello de botella.
Otra razón por la que los LLM deben usarse junto con otras herramientas es que pueden ser costosos, por lo que es mejor no usarlos innecesariamente.
«Aunque el costo por token para las predicciones ha disminuido constantemente, las migraciones a menudo requieren tocar miles de archivos y los costos pueden acumularse rápidamente», señalan los autores.
Aun así, no hay duda de que la IA ha cambiado profundamente la forma en que Google desarrolla el software interno. Según el documento, «la cantidad de caracteres en el código que se completan con asistencia basada en IA es ahora mayor que la que los desarrolladores escriben manualmente». ®
