RubberDuckBench: A Benchmark for AI Coding Assistants
El artículo presenta RubberDuckBench, una evaluación multilingüe derivada de solicitudes de incorporación de cambios reales de GitHub para evaluar asistentes de codificación con IA, revelando que incluso los modelos más avanzados tienen dificultades con la consistencia y la corrección mientras alucinan con frecuencia, sin que se observe ninguna correlación entre el costo y el rendimiento.
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 tienes un equipo de robots muy inteligentes y muy rápidos que pueden escribir código informático por ti. Les haces preguntas como: «¿Por qué esta parte del código se comporta de forma extraña?» o «¿Qué sucede si cambio este número?». Esperas que examinen el código específico en el que estás trabajando y te den una respuesta perfecta.
Este artículo, RubberDuckBench, es como un examen final para estos asistentes robóticos. Los autores (investigadores del Bryn Mawr College, Google y Meta) querían saber si estos robots son realmente buenos respondiendo preguntas sobre código específico o si simplemente están adivinando.
Aquí tienes el desglose de su estudio utilizando analogías sencillas:
1. El problema: La trampa del «fuera de contexto»
Antes de este estudio, la mayoría de las pruebas para los programadores de IA eran como pedirle a un estudiante que escribiera un ensayo completamente nuevo desde cero basado en una consigna. Pero en la vida real, los programadores no solo piden código nuevo; hacen preguntas sobre código que ya existe en un proyecto específico.
- Las pruebas antiguas: Como pedirle a un chef: «¿Cómo se hace un pastel?».
- El mundo real: Como pedirle a un chef: «¿Por qué se quemó mi pastel en el horno en la tercera rejilla?».
Los investigadores se dieron cuenta de que nadie había creado una buena prueba para el segundo tipo de pregunta.
2. Construyendo el examen: El método del «patito de goma»
Los programadores a menudo hablan con «patitos de goma» (o con sus colegas) para resolver problemas de código. Los investigadores analizaron conversaciones reales entre desarrolladores en GitHub (un lugar donde las personas comparten código).
- La fuente: Encontraron miles de comentarios donde los desarrolladores se hacían preguntas específicas sobre su código.
- El filtro: Muchos comentarios eran solo sugerencias como «arregla este error tipográfico». Los investigadores utilizaron IA y humanos para filtrar el ruido y convertir las buenas preguntas en un examen claro de 15 preguntas.
- La clave de corrección: Como no hay una sola forma «correcta» de explicar el código, crearon rúbricas detalladas (hojas de calificación). Piénsalo como una guía del profesor que dice: «Si el estudiante menciona la palabra clave 'const', dale 2 puntos. Si miente sobre cómo funciona el código, réstale 3 puntos».
3. La prueba: 20 robots rinden el examen
Sometieron 20 modelos de IA diferentes (los «robots») a este examen. Entre ellos se incluían nombres famosos como GPT-5, Claude Opus, Grok 4 y otros. Les pidieron que respondieran las 15 preguntas basándose en el código específico proporcionado.
4. Los resultados: Los robots tienen fallos
Los resultados fueron sorprendentes y un poco decepcionantes para los robots «superinteligentes»:
- No hay ganadores claros: El robot superior, Grok 4, respondió correctamente aproximadamente el 69% de las preguntas. Los siguientes mejores obtuvieron alrededor del 68%. Estadísticamente, todos estaban en la misma «liga». No hubo un campeón claro.
- El mito de la «puntuación perfecta»: Incluso los mejores robots rara vez respondieron una pregunta completamente bien. Los robots superiores solo lograron responder 2 de 15 preguntas perfectamente en todos sus intentos. La mayoría de sus puntos provino de «puntos parciales» (acertar parte de la respuesta).
- El problema de la mentira (alucinaciones): Este fue el problema más grande. En promedio, los robots mintieron o inventaron hechos en el 58% de sus respuestas.
- Analogía: Imagina que le preguntas a un guía turístico sobre una calle específica de tu ciudad. La mitad de las veces, te dice con confianza que la calle es un parque cuando en realidad es una panadería.
- Incluso los mejores modelos, como o3, mintieron en el 67% de sus respuestas.
- Dificultades con Python: Los robots fueron mucho mejores respondiendo preguntas sobre código en Java y C++, pero tropezaron significativamente cuando el código estaba escrito en Python.
5. El precio versus el rendimiento
Los investigadores también verificaron si pagar más dinero o usar un «cerebro más grande» (más parámetros) hacía a los robots más inteligentes.
- El dinero no compra genio: Los modelos más caros (como Claude Opus) costaban mucho ejecutar pero no funcionaban mucho mejor que los más baratos. De hecho, Grok 4 fue el mejor rendimiento pero costó 12 veces menos que los modelos caros de Claude.
- Más grande no es mejor: Para los modelos de código abierto, el más grande (120 mil millones de parámetros) en realidad funcionó peor que uno más pequeño (20 mil millones de parámetros).
La conclusión
El artículo concluye que, aunque los asistentes de programación con IA están mejorando, aún no son confiables para responder preguntas complejas sobre código específico. A menudo adivinan, mienten con frecuencia y las opciones más caras no son necesariamente las más inteligentes.
Los autores crearon RubberDuckBench como un objetivo para la investigación futura, con la esperanza de impulsar a los desarrolladores a crear asistentes de IA que sean honestos, precisos y que realmente comprendan el código con el que trabajan, en lugar de simplemente inventar cosas.
¿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.