← Últimos artículos
🤖 AI

What Process Evaluation of Coding Agents Actually Measures: Action, Task, and Step Are Three Different Levels

Este artículo introduce un marco de medición que distingue entre los niveles de acción, tarea y paso para demostrar que las evaluaciones de proceso actuales de los agentes de codificación suelen confundir la relevancia semántica con la contribución causal, revelando que el comportamiento del agente está impulsado por la procedencia de la ejecución y la incertidumbre a nivel de tarea en lugar de simples transiciones de código.

Autores originales: Jiawei He, Mengyu Shi, Jie jia, Xikai Yang, Dong Sun

Publicado 2026-08-25
📖 6 min de lectura🧠 Análisis profundo

Autores originales: Jiawei He, Mengyu Shi, Jie jia, Xikai Yang, Dong Sun

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

En el mundo del desarrollo de software, ha surgido un nuevo tipo de trabajador: el agente de codificación. Impulsados por modelos de lenguaje de gran tamaño, estos programas pueden leer la descripción de un problema, navegar por una base de código compleja y escribir las correcciones necesarias para resolverlo. Durante años, la industria ha juzgado a estos agentes simplemente por si tuvieron éxito o fracasaron al final del día. Pero a medida que estos trabajadores digitales se vuelven más comunes, los desarrolladores se han dado cuenta de que el resultado final no es suficiente. Necesitan saber cómo llegaron allí. Quieren entender qué movimientos específicos ayudaron a la tarea, cuáles causaron el fallo y si el proceso fue lógico o solo una suposición afortunada. Esta necesidad ha dado lugar a un campo de estudio centrado en la "evaluación de procesos", un intento de calificar el trayecto del agente paso a paso, en lugar de solo su destino.

El desafío central en este campo es que las personas han estado tratando tres preguntas muy diferentes como si fueran la misma. Una pregunta indaga qué es probable que haga el agente a continuación, basándose en su situación actual. Otra pregunta sobre qué tan incierta permanece la tarea completa mientras el agente trabaja. La tercera, y la más difícil, pregunta si una acción específica realmente causó que el resultado final cambiara. Durante mucho tiempo, investigadores y herramientas han mezclado estos conceptos, asumiendo que una herramienta diseñada para predecir el siguiente movimiento podría también explicar por qué un paso fue crítico. Un equipo de investigadores de Alibaba y la Universidad de Nanjing decidió desenredar estos hilos. Construyeron un marco riguroso para medir cada uno de estos tres niveles por separado, utilizando un método que consiste en observar al agente trabajar, detenerlo y luego reiniciarlo desde el mismo punto exacto para ver qué sucede.

Para hacer esto, los investigadores se centraron en un tipo específico de tarea llamada localización de archivos. Imagine que se le entrega a un agente un informe de error y una instantánea de un proyecto de software. Su trabajo es encontrar los archivos exactos que deben cambiarse para solucionar el error. Este entorno es perfecto para el estudio porque el objetivo es claro y verificable. Los investigadores registraron 499 episodios de agentes trabajando en repositorios de software del mundo real. Luego tomaron estas sesiones grabadas y las rebobinaron a varios puntos. Desde esos puntos, dejaron que el agente corriera de nuevo, a veces permitiéndole elegir su propio siguiente movimiento, y otras veces obligándolo a tomar un camino diferente para ver si el resultado final cambiaba. Esto les permitió aislar el efecto de los pasos individuales del ruido de todo el trayecto.

Su investigación reveló que la forma en que los agentes se mueven a través del código no es lo que la mayoría de la gente espera. Al intentar predecir qué hará un agente a continuación, la señal más poderosa no es la estructura del código en sí, como la forma en que los archivos están vinculados en un grafo de dependencias. En cambio, el agente es impulsado casi por completo por su propio historial reciente. Observa las rutas que acaba de ver en la salida de sus herramientas previas y utiliza ese contexto inmediato para decidir hacia dónde ir después. La estructura del código importa menos para el siguiente paso inmediato que el rastro de migas de pan que el agente acaba de dejar atrás. Este hallazgo sugiere que el agente está reaccionando a lo que acaba de observar en lugar de seguir un mapa preplanificado del repositorio.

El estudio también descubrió dónde reside realmente la incertidumbre en estas tareas. Muchas personas asumen que el riesgo de fracaso proviene de un solo mal paso, como la elección de un archivo incorrecto. Sin embargo, los investigadores encontraron que la incertidumbre es una propiedad de toda la tarea, no de los pasos individuales. Algunas tareas son inherentemente difíciles o ambiguas desde el principio, mientras que otras son sencillas. La variación en si un agente tiene éxito o fracasa está determinada por la naturaleza del problema específico que está resolviendo, no por la secuencia específica de movimientos que realiza en el camino. Esto significa que intentar señalar un único paso de "error fatal" es a menudo un ejercicio fútil porque el resultado probablemente fue decidido por la dificultad de la tarea misma.

Quizás el descubrimiento más sorprendente concierne a cómo evaluamos actualmente a estos agentes. Muchos sistemas utilizan un "juez", a menudo otro modelo de lenguaje de gran tamaño, para revisar todo el historial del trabajo del agente y decidir qué paso fue responsable de un fallo. Los investigadores probaron estos jueces ocultando o revelando diferentes partes del historial del agente. Encontraron que cuando el juez podía ver los pasos posteriores del trayecto, desplazaba sistemáticamente la culpa hacia el final del proceso. Esto sucedía incluso cuando los pasos posteriores no tenían nada que ver con la causa real del problema. El juez no estaba identificando la causa verdadera; simplemente se aferraba a la evidencia más reciente que parecía relevante. Esto reveló un sesgo sistemático en los métodos de evaluación actuales, donde las herramientas utilizadas para calificar a los agentes están midiendo en realidad la relevancia semántica —lo que parece importante en retrospectiva— en lugar de la contribución causal certificada.

Los investigadores concluyeron que la evaluación de procesos no es un solo problema, sino una colección de desafíos distintos. Predecir el siguiente movimiento es un problema soluble impulsado por el contexto reciente. Comprender la dificultad de la tarea es una cuestión de analizar el problema mismo. Pero determinar el impacto causal de un solo paso es increíblemente difícil y, a menudo, imposible de medir con las herramientas actuales. El estudio sugiere que debemos dejar de tratar estos diferentes niveles como si fueran lo mismo. Si queremos mejorar los agentes de codificación, necesitamos usar la herramienta adecuada para la pregunta adecuada, reconociendo que una señal que predice el siguiente movimiento no es lo mismo que una señal que prueba que un paso causó un éxito o un fracaso. Al separar estos niveles, finalmente podemos entender qué nos están diciendo realmente nuestras herramientas de evaluación y qué es simplemente una suposición.

¿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.

Probar Digest →