Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study
Este estudio empírico de más de 11.000 solicitudes de incorporación de agentes revela que confiar únicamente en los resultados de fusión o rechazo para evaluar agentes de codificación con IA es engañoso, ya que una parte significativa de los rechazos se debe a limitaciones del flujo de trabajo en lugar de errores del agente y muchas fusiones requieren una intervención humana sustancial, lo que hace necesaria la adopción de métricas de evaluación conscientes de la interacción basadas en el comportamiento de revisión.
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 una cocina bulliciosa y de alta tecnología donde los robots (agentes de codificación con IA) intentan constantemente preparar nuevos platos (cambios de código) y servirlos al chef principal (el revisor humano) para su aprobación. El objetivo es que estos platos se añadan al menú del restaurante (se fusionen en el software).
Durante mucho tiempo, las personas han juzgado la calidad de estos chefs robots simplemente observando el resultado final: ¿Se sirvió el plato (Fusionado) o se devolvió a la basura (Rechazado)?
Este nuevo estudio argumenta que observar el resultado final es como juzgar a un chef únicamente por si el plato salió de la cocina, sin preguntar por qué. Los investigadores descubrieron que la etiqueta "Sí/No" cuenta una historia muy incompleta.
Aquí está lo que descubrieron, desglosado en analogías simples:
1. La "Basura" No Siempre Es Culpa del Chef
Cuando el plato de un robot es rechazado, a menudo asumimos que el robot cocinó algo incomible (un error de codificación). Sin embargo, el estudio encontró que solo alrededor del 36% de los rechazos fueron realmente porque el robot estropeó la receta.
Los otros dos tercios fueron rechazados por razones que no tenían nada que ver con las habilidades culinarias del robot:
- El Problema de la "Noche Incorrecta" (31%): El plato era perfecto, pero la cocina ya estaba cerrada, o el chef ya había pedido un plato diferente para esa noche. En términos tecnológicos, el código estaba bien, pero el flujo de trabajo del proyecto no lo necesitaba, o era un duplicado.
- El "Trato Silencioso" (33%): El plato fue devuelto, pero el chef no dijo una palabra. No había ninguna nota en el plato explicando por qué. Es imposible saber si el robot falló o si el chef simplemente lo ignoró.
La Conclusión: Si solo cuentas los rechazos como "fallos", estás culpando injustamente al robot por cosas que en realidad fueron solo mala suerte o silencio.
2. El Plato "Servido" No Siempre Es Solo del Robot
Cuando un plato se sirve (fusionado), asumimos que el robot lo cocinó perfectamente de principio a fin. Pero el estudio encontró que aproximadamente el 15% de estos "éxitos" realmente requirieron que el chef humano interviniera y arreglara las cosas antes de que el plato pudiera salir.
- La "Degustación" (Bucles de Retroalimentación): El robot cocinó el plato principal, pero el chef lo probó, dijo: "Necesita más sal", y el robot lo arregló.
- La "Presentación" (Intervención Humana): El robot cocinó la comida, pero el chef tuvo que reorganizar la guarnición o arreglar la presentación antes de servirla.
De hecho, para algunos robots (como Copilot y Devin), el chef humano estuvo involucrado en el proceso mucho más a menudo que para otros (como Codex y Cursor), quienes parecían tener sus platos servidos con casi ninguna interacción.
La Conclusión: Una etiqueta de "Fusionado" no siempre significa que el robot hizo todo el trabajo solo. A veces, el humano hizo el trabajo pesado al final para que funcionara.
3. Diferentes Robots, Diferentes Cocinas
El estudio notó que diferentes robots se comportaban de manera distinta dependiendo de en qué "cocina" (proyecto de software) estaban.
- Algunos robots fueron enviados a cocinas con reglas estrictas y chefs ocupados que daban retroalimentación constantemente. Estos robots tuvieron más rechazos y más ayuda humana.
- Otros robots fueron enviados a cocinas donde los chefs eran más distantes, lo que llevó a más aprobaciones o rechazos "silenciosos".
La Gran Conclusión
El documento concluye que no podemos juzgar la habilidad de un chef robot simplemente observando el sello de "Servido" o "Rechazado" en el ticket.
- Los Rechazos a menudo son solo problemas de flujo de trabajo o silencio, no una mala cocina.
- Las Fusiones a menudo involucran a chefs humanos arreglando el plato antes de servirlo.
Para entender verdaderamente qué tan buenos son estos agentes de IA, necesitamos observar la conversación entre el robot y el humano: los comentarios, las correcciones y las razones detrás de las decisiones, en lugar de solo el resultado final. Si no lo hacemos, estamos juzgando al chef basándonos en un menú que no cuenta toda la historia.
¿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.