Un equipo de investigadores ha mapeado los desafíos de la IA en el desarrollo de software y delineado una agenda de investigación para hacer avanzar el campo.
Imagine un futuro donde la inteligencia artificial se encargue silenciosamente de la monotonía del desarrollo de software: refactorizando código complejo, migrando sistemas heredados y buscando condiciones de competencia, para que los ingenieros humanos puedan dedicarse a la arquitectura, el diseño y los problemas genuinamente novedosos que aún están fuera del alcance de una máquina. Avances recientes parecen haber acercado ese futuro de forma tentadora, pero un nuevo artículo de investigadores del Laboratorio de Ciencias de la Computación e Inteligencia Artificial (CSAIL) del MIT y varias instituciones colaboradoras argumenta que esta posible realidad futura exige un análisis profundo de los desafíos actuales.
Titulado “ Desafíos y caminos hacia la IA para la ingeniería de software ”, el trabajo mapea las muchas tareas de ingeniería de software más allá de la generación de código, identifica los cuellos de botella actuales y destaca las direcciones de investigación para superarlos, con el objetivo de permitir que los humanos se concentren en el diseño de alto nivel mientras el trabajo de rutina se automatiza.
“Todo el mundo habla de que ya no necesitamos programadores, y que ahora disponemos de toda esta automatización”, afirma Armando Solar-Lezama, profesor de ingeniería eléctrica e informática del MIT, investigador principal de CSAIL y autor principal del estudio. “Por un lado, el campo ha avanzado enormemente. Disponemos de herramientas mucho más potentes que cualquier otra que hayamos visto antes. Pero también queda mucho camino por recorrer para alcanzar la plena capacidad de automatización que esperamos”.
Solar-Lezama argumenta que las narrativas populares suelen reducir la ingeniería de software a «la parte de programación de pregrado: alguien te da una especificación para una pequeña función y la implementas, o a resolver entrevistas de programación al estilo LeetCode». La práctica real es mucho más amplia. Incluye refactorizaciones cotidianas que pulen el diseño, además de migraciones radicales que trasladan millones de líneas de COBOL a Java y transforman negocios enteros. Requiere pruebas y análisis continuos (fuzzing, pruebas basadas en propiedades y otros métodos) para detectar errores de concurrencia o corregir fallas de día cero. E implica el trabajo duro de mantenimiento: documentar código de hace una década, resumir los historiales de cambios para los nuevos compañeros de equipo y revisar las solicitudes de extracción para comprobar su estilo, rendimiento y seguridad.
La optimización de código a escala industrial —pensemos en el reajuste de los kernels de la GPU o en los incesantes refinamientos multicapa del motor V8 de Chrome— sigue siendo extremadamente difícil de evaluar. Las métricas principales actuales se diseñaron para problemas breves e independientes, y si bien los exámenes de opción múltiple aún dominan la investigación en lenguaje natural, nunca fueron la norma en la IA para código. El criterio de facto en este campo, SWE-Bench, simplemente pide a un modelo que solucione un problema de GitHub: útil, pero similar al paradigma del «ejercicio de programación de pregrado». Solo afecta a unos pocos cientos de líneas de código, corre el riesgo de fugas de datos de repositorios públicos e ignora otros contextos del mundo real: refactorizaciones asistidas por IA, programación en parejas humano-IA o reescrituras críticas para el rendimiento que abarcan millones de líneas. Hasta que los benchmarks se expandan para abarcar estos escenarios de mayor riesgo, medir el progreso —y, por lo tanto, acelerarlo— seguirá siendo un desafío abierto.
Si la medición es un obstáculo, la comunicación entre humanos y máquinas es otro. El primer autor, Alex Gu, estudiante de posgrado del MIT en ingeniería eléctrica e informática, considera la interacción actual como una delgada línea de comunicación. Cuando le pide a un sistema que genere código, a menudo recibe un archivo grande y desestructurado, e incluso un conjunto de pruebas unitarias; sin embargo, estas pruebas tienden a ser superficiales. Esta brecha se extiende a la capacidad de la IA para utilizar eficazmente el conjunto más amplio de herramientas de ingeniería de software, desde depuradores hasta analizadores estáticos, de las que los humanos dependen para un control preciso y una comprensión más profunda. «Realmente no tengo mucho control sobre lo que escribe el modelo», afirma. «Sin un canal para que la IA muestre su propia confianza —’esta parte es correcta… esta parte, quizás vuelva a comprobarla’—, los desarrolladores se arriesgan a confiar ciegamente en una lógica alucinada que compila, pero colapsa en producción. Otro aspecto crítico es que la IA sepa cuándo pedirle aclaraciones al usuario».
La escala agrava estas dificultades. Los modelos de IA actuales presentan serias dificultades con bases de código extensas, que a menudo abarcan millones de líneas. Los modelos de base aprenden de GitHub público, pero «la base de código de cada empresa es bastante diferente y única», afirma Gu, lo que elimina por completo las convenciones de codificación propietarias y los requisitos de especificación de la distribución. El resultado es un código que parece plausible, pero que invoca funciones inexistentes, infringe las reglas de estilo internas o falla en los procesos de integración continua. Esto a menudo conduce a un código generado por IA que «alucina», es decir, crea contenido que parece plausible, pero que no se alinea con las convenciones internas, las funciones auxiliares ni los patrones arquitectónicos específicos de una empresa determinada.
Los modelos también suelen recuperar datos incorrectamente, ya que recuperan código con un nombre (sintaxis) similar en lugar de la funcionalidad y la lógica, que es lo que un modelo podría necesitar para saber cómo escribir la función. «Las técnicas de recuperación estándar son fácilmente engañadas por fragmentos de código que hacen lo mismo, pero parecen diferentes», afirma Solar-Lezama.
Los autores mencionan que, dado que no existe una solución milagrosa para estos problemas, solicitan, en cambio, esfuerzos a escala comunitaria: más enriquecidos, con datos que capturen el proceso de los desarrolladores escribiendo código (por ejemplo, qué código conservan y cuál descartan, cómo se refactoriza el código con el tiempo, etc.), suites de evaluación compartidas que midan el progreso en la calidad de la refactorización, la longevidad de las correcciones de errores y la corrección de la migración; y herramientas transparentes que permitan a los modelos exponer la incertidumbre e invitar a la dirección humana en lugar de la aceptación pasiva. Gu enmarca la agenda como un «llamado a la acción» para colaboraciones más amplias de código abierto que ningún laboratorio podría reunir por sí solo. Solar-Lezama imagina avances incrementales («resultados de investigación que tomen mordiscos de cada uno de estos desafíos por separado») que retroalimenten las herramientas comerciales y conviertan gradualmente a la IA de un compañero de autocompletado a un verdadero socio de ingeniería.
“¿Por qué importa todo esto? El software ya sustenta las finanzas, el transporte, la atención médica y las minucias de la vida cotidiana, y el esfuerzo humano necesario para desarrollarlo y mantenerlo de forma segura se está convirtiendo en un cuello de botella. Una IA capaz de encargarse del trabajo pesado, sin introducir fallos ocultos, liberaría a los desarrolladores para que se centraran en la creatividad, la estrategia y la ética”, afirma Gu. “Pero ese futuro depende de reconocer que completar el código es la parte fácil; lo difícil es todo lo demás. Nuestro objetivo no es reemplazar a los programadores. Es potenciarlos. Cuando la IA pueda abordar lo tedioso y lo aterrador, los ingenieros humanos finalmente podrán dedicar su tiempo a lo que solo los humanos pueden hacer”.
“Con tantos nuevos trabajos emergentes en IA para programación, y con la comunidad a menudo siguiendo las últimas tendencias, puede resultar difícil detenerse y reflexionar sobre qué problemas son más importantes que abordar”, afirma Baptiste Rozière, científico de IA en Mistral AI, quien no participó en el artículo. “Disfruté de la lectura de este artículo porque ofrece una visión clara de las tareas y los desafíos clave de la IA para la ingeniería de software. También describe líneas prometedoras para futuras investigaciones en este campo”.
Gu y Solar-Lezama escribieron el artículo junto con el profesor Koushik Sen de la Universidad de California en Berkeley y los estudiantes de doctorado Naman Jain y Manish Shetty; el profesor adjunto Kevin Ellis de la Universidad de Cornell y el estudiante de doctorado Wen-Ding Li; el profesor adjunto Diyi Yang de la Universidad de Stanford y el estudiante de doctorado Yijia Shao; y el profesor adjunto entrante Ziyang Li de la Universidad Johns Hopkins. Su trabajo fue financiado, en parte, por la Fundación Nacional de Ciencias (NSF), patrocinadores y afiliados industriales de SKY Lab, Intel Corp. a través de una subvención de la NSF y la Oficina de Investigación Naval.
Los investigadores presentarán su trabajo en la Conferencia Internacional sobre Aprendizaje Automático (ICML).
MIT News. R. G. Traducido al español
