Understanding the Rejection of Fixes Generated by Agentic Pull Requests -- Insights from the AIDev Dataset
Este artículo analiza el conjunto de datos AIDev para identificar 14 razones específicas por las cuales casi la mitad de los pull requests generados por IA son rechazados, categorizando estos modos de falla para proporcionar orientación accionable para mejorar el rendimiento de los agentes, la priorización de tareas y la integración en los flujos de trabajo de desarrollo de software.
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 contratas a un equipo de pasantes robóticos súper rápidos y entusiastas para corregir errores en tu software. Les das un problema y ellos inmediatamente comienzan a escribir código, construyendo un "Pull Request" (que es como una propuesta para cambiar el código).
Este artículo es básicamente una boleta de calificaciones sobre lo que sucede cuando estos pasantes robóticos (específicamente Copilot, Devin, Cursor y Claude) intentan arreglar cosas. Los investigadores encontraron una estadística sorprendente: casi la mitad de las veces (46.41%), el jefe humano tira el trabajo del robot a la basura.
Aquí hay un desglose de por qué sucede esto, utilizando analogías simples:
El Gran Problema: La Factura del "Esfuerzo Desperdiciado"
Cada vez que un robot genera una corrección que es rechazada, se produce una pérdida doble. Primero, el robot desperdicia su propio "poder cerebral" (recursos de computación y tokens). Segundo, y más importante, un humano tiene que detener lo que está haciendo, leer el trabajo desordenado del robot, darse cuenta de que está mal y escribir un comentario explicando por qué. Eso es tiempo humano desperdiciado.
Los investigadores analizaron 306 de estas propuestas rechazadas para averiguar exactamente por qué los humanos dijeron "No". Encontraron cuatro razones principales para el rechazo:
1. La "Herramienta Equivocada para el Trabajo" (Problemas de Implementación)
A veces el robot intenta arreglar el problema, pero utiliza el enfoque equivocado.
- La Analogía: Imagina que tu auto no arranca. Le pides a un mecánico que lo arregle. Él llega e intenta arreglar el radio en lugar del motor, o intenta arreglar el motor con un martillo en lugar de una llave inglesa.
- Lo que pasó: Los robots a menudo malinterpretaron las instrucciones, arreglaron la cosa equivocada o propusieron una solución que era técnicamente imposible o incompleta.
2. La "Prueba Rota" (Problemas Técnicos)
En el software, antes de que una corrección sea aceptada, debe pasar una serie de pruebas automatizadas (como una inspección de seguridad).
- La Analogía: El robot construye un puente nuevo, pero cuando el inspector conduce un camión sobre él, el puente colapsa. El robot no verificó si su propio puente podía soportar peso.
- Lo que pasó: El código que escribieron los robots a menudo falló las "pruebas de seguridad" automatizadas (pipelines de CI) o rompió otras partes del software que ya estaban funcionando.
3. El "Pasante Fantasma" (Problemas del Proveedor)
A veces el robot simplemente deja de trabajar o se corta.
- La Analogía: Le pides al pasante que escriba un informe, pero a mitad de camino, el pasante sale del edificio, o la conexión a internet se corta, dejándote con una página en blanco.
- Lo que pasó: El servicio de IA en sí mismo falló, el robot recibió un "límite de velocidad" (se quedó sin las solicitudes permitidas) o la sesión simplemente murió antes de que pudiera terminar el trabajo.
4. La "Corrección Inútil" (Problemas de Relevancia)
A veces el robot está trabajando en un problema que ya no importa.
- La Analogía: Le pides al pasante que arregle una fuga en la cocina. Para cuando el pasante termina la reparación, la cocina ha sido remodelada, o la fuga ya no existe, o alguien más ya la arregló con un método mejor.
- Lo que pasó: El problema que el robot estaba arreglando era de baja prioridad, el problema ya había sido resuelto por alguien más, o el robot se quedó inactivo tanto tiempo que el proyecto avanzó sin él.
El "Costo" del Error
El artículo también midió cuánto "desorden" hicieron los robots antes de ser rechazados.
- Code Churn (Rotación de Código): Esta es una forma elegante de decir "cuánto código fue escrito y luego eliminado". Los investigadores encontraron que las correcciones rechazadas involucraron una mediana de 81 a 293 líneas de código. ¡Eso es mucho escribir para un error!
- Comentarios: Los humanos tuvieron que escribir un promedio de 1 a 4.5 comentarios para explicar por qué la corrección era mala. Dado que casi la mitad de todas las correcciones de los robots son rechazadas, eso significa que la mitad de todos los comentarios humanos escritos a estos robots son solo para decir: "No, esto no funciona".
La Conclusión: Cómo Entrenar Mejor a los Pasantes
Los autores sugieren que para dejar de perder el tiempo, los humanos necesitan dar mejores instrucciones a los robots antes de que comiencen a trabajar. Específicamente:
- Dar un Mapa: Dile al robot exactamente cómo arreglar el problema y qué no hacer.
- Configurar la Prueba: Dile al robot cómo verificar su propio trabajo para asegurarse de que pase las pruebas de seguridad antes de mostrárselo al jefe.
- Elegir los Trabajos Adecuados: No le pidas al robot que arregle errores diminutos y sin importancia que no valgan el tiempo de revisión humana.
En resumen: los agentes de IA son poderosos, pero en este momento, son como pasantes entusiastas que necesitan instrucciones muy claras y específicas para evitar desperdiciar el tiempo y la energía de todos.
¿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.