
Crédito: Dominio público de Pixabay/CC0
Imagine un futuro en el que la inteligencia artificial asuma silenciosamente el trabajo pesado del desarrollo de software: refactorizar el código enredado, la migración de sistemas heredados y la caza de condiciones de carrera, para que los ingenieros humanos puedan dedicarse a la arquitectura, el diseño y los problemas genuinamente novedosos aún más allá del alcance de una máquina.
Los avances recientes parecen haber empujado que el futuro tentadoramente se cierra, pero un nuevo artículo de los investigadores del Laboratorio de Informática e Inteligencia Artificial del MIT (CSAIL) y varias instituciones colaboradoras argumentan que esta posible realidad futura exige una mirada dura en los desafíos actuales.
Titulado «Desafíos y rutas 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 instrucciones de investigación para superarlas, con el objetivo de permitir que los humanos se centren en el diseño de alto nivel mientras el trabajo de rutina se automatiza. El papel es disponible en el arxiv servidor de preimpresión, y los investigadores presentan su trabajo en la Conferencia Internacional sobre Aprendizaje Autor (ICML 2025) en Vancouver.
«Todos hablan sobre cómo ya no necesitamos programadores, y ahora está toda esta automatización disponible», dice Armando Solar-Lezama, profesor de Ingeniería Eléctrica e Informática, Investigador Principal de CSAIL y autor senior del estudio.
«Por un lado, el campo ha progresado enormemente. Tenemos herramientas que son mucho más poderosas que cualquiera que hayamos visto antes. Pero también hay un largo camino por recorrer para obtener la promesa completa de la automatización que esperaríamos».
Solar-Lezama argumenta que las narrativas populares a menudo reducen la ingeniería de software a «la parte de programación de pregrado: alguien le entrega una especie para una pequeña función y la implementa, o resuelve entrevistas de programación al estilo Leetcode».
La práctica real es mucho más amplia. Incluye refactores cotidianos que pulen el diseño, además de migraciones radicales que mueven millones de líneas de COBOL a Java y remodelan empresas enteras. Requiere pruebas y análisis sin parar (fuzgador, pruebas basadas en propiedades y otros métodos) para atrapar errores de concurrencia o fallas de parche de día cero. E implica la rutina de mantenimiento: documentar el código de la década, resumir los historiales de cambios para los nuevos compañeros de equipo y revisar las solicitudes de extracción de estilo, rendimiento y seguridad.
La optimización del código a escala de la industria, piense en el ajuste de los núcleos de la GPU o los implacables refinamientos de varias capas detrás del motor V8 de Chrome, se mantienen obstinadamente difíciles de evaluar. Las métricas de titulares de hoy se diseñaron para problemas cortos y autónomos, y aunque las pruebas de opción múltiple aún dominan la investigación en lenguaje natural, nunca fueron la norma en el código AI para el código.
El criterio de facto del campo, Swe-Bench, simplemente le pide a un modelo que repare un problema de GitHub: útil, pero aún similar al paradigma del «ejercicio de programación de pregrado». Toca solo unos pocos cientos de líneas de código, arriesga la fuga de datos de los repositorios públicos e ignora otros contextos del mundo real: refactores asistidos por AI, programación de pares humanos-AI o reescrituras críticas de rendimiento que abarcan millones de líneas. Hasta que los puntos de referencia se expandan para capturar esos escenarios de mayor riesgo, midiendo el progreso, y acelerando así, seguirá siendo un desafío abierto.
Si la medición es un obstáculo, la comunicación de la máquina humana es otra. El primer autor Alex Gu, estudiante graduado del MIT en Ingeniería Eléctrica e Informática, ve la interacción de hoy 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 no estructurado e incluso un conjunto de pruebas unitarias, sin embargo, esas pruebas tienden a ser superficiales. Esta brecha se extiende a la capacidad de la IA para usar efectivamente el conjunto más amplio de herramientas de ingeniería de software, desde debuggers hasta analizadores estáticos, en los que los humanos confían para un control preciso y una comprensión más profunda.
«Realmente no tengo mucho control sobre lo que escribe el modelo», dice. «Sin un canal para que la IA exponga su propia confianza:» esta parte es correcta … esta parte, tal vez dos verificaciones «, los desarrolladores corren el riesgo de confiar ciegamente en la lógica alucinada que compila, pero colapsa en la producción. Otro aspecto crítico es tener la IA saber cuándo aplazar al usuario para aclarar».
Escala compensa estas dificultades. Los modelos actuales de IA luchan profundamente con grandes bases de código, a menudo abarcando millones de líneas. Los modelos de base aprenden de GitHub público, pero «la base de código de cada compañía es algo diferente y única», dice Gu, haciendo convenciones de codificación propietarias y requisitos de especificación fundamentalmente fuera de la distribución.
El resultado es un código que parece plausible pero llama funciones inexistentes, viola las reglas de estilo interno o falla las tuberías de integración continua. Esto a menudo conduce a un código generado por IA que «alucina», lo que significa que crea contenido que parece plausible pero que no se alinea con las convenciones internas específicas, las funciones de ayuda o los patrones arquitectónicos de una compañía determinada.
Los modelos también a menudo se recuperarán incorrectamente, ya que recupera el código con un nombre similar (sintaxis) en lugar de funcionalidad y lógica, que es lo que un modelo podría necesitar saber cómo escribir la función. «Las técnicas de recuperación estándar son muy engañadas por piezas de código que están haciendo lo mismo pero que se ven diferentes», dice Solar-Lezama.
Los autores mencionan que, dado que no hay una bala de plata en estos problemas, están llamando a los esfuerzos a escala comunitaria: más rico, con datos que capturan el proceso de los desarrolladores que escriben el código (por ejemplo, que los desarrolladores de código mantienen versus tirar, cómo se refactora el código con el tiempo, etc.), los suites de compartir el progreso en la calidad de los refactores, la longevidad de la mezcla de errores y la corrección de la migración; y herramientas transparentes que permiten que los modelos expongan la incertidumbre e inviten 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 de código abierto más grandes que ningún laboratorio solo podría reunir solo. Solar-Lezama imagina avances incrementales: «Los resultados de la investigación que eliminan las picaduras de cada uno de estos desafíos por separado», que vuelven a tomar herramientas comerciales y mueven gradualmente la IA del compañero autocompliado hacia un socio de ingeniería genuino.
«¿Por qué importa? El software ya sustenta las finanzas, el transporte, la atención médica y las minucias de la vida diaria, y el esfuerzo humano requerido para construirlo de manera segura se está convirtiendo en un cuello de botella. Una IA que puede asumir el trabajo gruñido, y hacerlo sin introducir fallas ocultas, los desarrolladores liberados para centrarse en la creatividad, la estrategia y la ética y la ética» dice Gu.
«Pero ese futuro depende de reconocer que la finalización del código es la parte fácil; la parte difícil es todo lo demás. Nuestro objetivo no es reemplazar a los programadores. Es para amplificarlos. Cuando la IA puede abordar los tediosos y terroríficos ingenieros humanos finalmente pueden pasar su tiempo en lo que solo los humanos pueden hacer».
«Con tantos trabajos nuevos que surgen en la IA para la codificación, y la comunidad a menudo persigue las últimas tendencias, puede ser difícil dar un paso atrás y reflexionar sobre qué problemas son más importantes para abordar», dice Baptiste Rozière, un científico de IA de la IA Mistral, que no estaba involucrado en el documento. «Disfruté leyendo este documento porque ofrece una visión general clara de las tareas y desafíos clave en la IA para la ingeniería de software. También describe direcciones prometedoras para futuras investigaciones en el campo».
Más información:
Alex Gu et al, desafíos y caminos hacia la IA para la ingeniería de software, arxiv (2025). Doi: 10.48550/arxiv.2503.22625
Esta historia se vuelve a publicar por cortesía de MIT News (web.mit.edu/newsoffice/), un sitio popular que cubre noticias sobre la investigación del MIT, la innovación y la enseñanza.
Citación: ¿Puede AI realmente codificar? El estudio mapea los obstáculos para la ingeniería de software autónomo (2025, 17 de julio) Consultado el 25 de julio de 2025 de https://techxplore.com/news/2025-07-ai-code-roadblocks-autonomous-software.html
Este documento está sujeto a derechos de autor. Además de cualquier trato justo con el propósito de estudio o investigación privada, no se puede reproducir ninguna parte sin el permiso por escrito. El contenido se proporciona solo para fines de información.