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
