IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
IDE-Bench introduce un marco de evaluación integral y dockerizado que cuenta con 80 tareas a través de ocho repositorios nunca antes publicados para evaluar las capacidades de los agentes de IDE de IA en tareas de ingeniería de software multilingües del mundo real mediante una interfaz de herramientas estructurada y nativa de IDE.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que estás contratando a un nuevo desarrollador junior para trabajar en tu proyecto de software. Quieres saber si realmente puede hacer el trabajo: encontrar errores, añadir nuevas funciones y arreglar código roto sin romper todo lo demás.
Durante mucho tiempo, hemos probado a los asistentes de programación con IA dándoles un único acertijo para resolver en una habitación vacía. Pero el desarrollo de software real no es un acertijo en una habitación; es como trabajar en un taller concurrido y de alta tecnología lleno de herramientas, planos y otros trabajadores.
IDE-Bench es un nuevo "taller" diseñado para probar los modelos de IA exactamente como se utilizarán en el mundo real. Aquí está el desgrecado de lo que encontró el artículo, utilizando analogías sencillas.
1. La nueva prueba: De "lápiz y papel" al "taller completo"
Las pruebas anteriores (como SWE-Bench) eran como darle a un estudiante un problema matemático en una hoja de papel y pedirle que escribiera la respuesta. No podían usar una calculadora ni buscar fórmulas; solo tenían que adivinar la respuesta basándose en lo que habían memorizado.
IDE-Bench es diferente. Le da a la IA un taller Dockerizado (una habitación digital segura y aislada) y un juego completo de herramientas, tal como las que usan los desarrolladores en aplicaciones como Cursor o Windsurf.
- Las Herramientas: La IA puede buscar en el código, leer archivos, editar líneas, ejecutar pruebas e incluso revisar bases de datos.
- El Objetivo: La IA tiene que actuar como un ingeniero real. No puede simplemente adivinar; tiene que explorar, realizar cambios, comprobar si funcionan y corregir errores si algo se rompe.
2. Los libros de cocina de la "receta secreta"
Para asegurar que la IA no haya simplemente memorizado las respuestas de internet, los investigadores crearon 80 tareas totalmente nuevas a través de 8 bases de código secretas.
- La Analogía: Imagina una competición de cocina donde los jueces crean 8 recetas nuevas y nunca antes vistas. Los concursantes (los modelos de IA) tienen que cocinarlas. Debido a que estas recetas nunca han sido publicadas en internet, la IA no puede hacer trampa buscando la solución en sus datos de entrenamiento.
- La Variedad: Las recetas cubren diferentes "cocinas" (lenguajes de programación): C/C++ (programación de sistemas), Java (aplicaciones empresariales) y MERN (aplicaciones web modernas).
3. Los resultados: ¿Quién es el Maestro Chef?
Los investigadores probaron 15 modelos de IA diferentes. Esto es lo que encontraron:
- El Nivel Superior (Los Maestros Chefs): Algunos modelos, liderados por GPT-5.2, resolvieron aproximadamente el 95% de las tareas. Eran como chefs que podían leer la receta, agarrar las herramientas adecuadas y cocinar el plato perfectamente al primer intento.
- El Nivel Medio (Los Cocineros Competentes): Modelos como Claude Sonnet y Claude Haiku resolvieron entre el 85 y el 88% de las tareas. Son muy buenos, pero podrían necesitar un segundo intento para que sea perfecto.
- El Nivel Inferior (Los Novatos): Muchos modelos de código abierto tuvieron dificultades, resolviendo menos del 50% de las tareas. A menudo se perdían en el taller o rompían el código mientras intentaban arreglarlo.
4. El problema del "casi lo logra"
Uno de los hallazgos más interesantes es que las puntuaciones binarias (Aprobado/Suspenso) ocultan mucha sutileza.
- La Analogía: Imagina que un estudiante hace un examen y acierta 11 de 12 preguntas. En un sistema de calificación estricto, obtiene un "Suspenso" porque no alcanzó el 100%.
- La Realidad: En IDE-Bench, muchos modelos hicieron bien el núcleo del código pero fallaron debido a detalles minúscleos, como una coma faltante o un formato ligeramente incorrecto. El artículo llama a esto "fallos por poco" (near misses).
- La Lección: Un modelo puede estar al 90% de una solución, pero si falla en los detalles diminutos, la prueba lo marca como un fallo total. Esto sugiere que, para el uso en el mundo real, es posible que no necesitemos desechar el código y empezar de nuevo; solo podríamos necesitar que un humano corrija los pequeños errores de formato.
5. Eficiencia frente a Exhaustividad
El artículo también analizó qué tan "caro" era para la IA resolver una tarea (medido en "tokens", o palabras de pensamiento).
- Rápido y Barato: Algunos modelos (como Grok 4.1 Fast) fueron muy eficientes. Resolvían las tareas rápidamente y utilizaban menos recursos, pero fallaban con más frecuencia.
- Lento y Exhaustivo: Otros modelos (como Claude Opus) tardaban mucho tiempo, leían muchos archivos y pensaban profundamente. Tenían más probabilidades de tener éxito, pero costaba mucho más en términos de tiempo y potencia de cómputo.
- La Conclusión: No existe un único modelo "mejor". Si quieres velocidad y bajo coste, eliges un tipo. Si necesitas alta fiabilidad y no te importa el coste, eliges otro.
6. Cómo fallan
Los investigadores categorizaron cómo fallaron los modelos de IA, lo cual es como un mecánico diagnosticando por qué un coche no arranca:
- Edición Prematura (63% de los fallos): La IA empezó a cambiar el código antes de entender siquiera el plano. Era como intentar arreglar el motor de un coche sin abrir primero el capó.
- Trastorno o "Thrashing" (28%): La IA seguía cambiando el mismo archivo de un lado a otro, deshaciendo su propio trabajo, como una persona que no puede decidir qué camino tomar y sigue caminando en círculos.
- Pérdida de Contexto (27%): La IA olvidó lo que debía hacer a mitad de la tarea, como un chef que empieza a cocinar un pastel pero olvida que debía hacer una pizza.
Resumen
IDE-Bench demuestra que los mejores modelos de IA ya son capaces de actuar como ingenieros de software reales en un entorno complejo y rico en herramientas. Sin embargo, también muestra que:
- La especialización importa: Algunos modelos son excelentes en aplicaciones web pero malos en código de sistemas de bajo nivel.
- La perfección es difícil: Llegar al 99% es común, pero el último 1% (los detalles diminutos) es donde la mayoría de los modelos fallan.
- La estrategia importa: El mejor enfoque podría ser usar un modelo "rápido" primero y, si falla, cambiar a un modelo "exhaustivo" para terminar el trabajo.
El artículo concluye que debemos dejar de buscar una única "puntuación" para juzgar a la IA y empezar a observar cómo trabajan, en qué son buenos y cuánto cuesta hacer el trabajo.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.