El reto de medir el éxito de los agentes de codificación sin un techo de reintentos
Los informes que muestran un porcentaje de éxito sin detallar cuántos reintentos se permiten o cuánto tiempo se tarda son comparaciones incompletas. Un nuevo esquema de scorecard propuesto obliga a fijar límites de reintentos y tiempo y a r
Los desarrolladores de agentes de codificación han estado comparando sus herramientas con un simple porcentaje de éxito, como suele aparecer en tablas de README. Esa cifra suele ocultar varios parámetros invisibles: cuántas veces el agente puede regenerar un parche tras una prueba fallida, cuánto tiempo puede usar el runner antes de abortar, o si el runner permite reintentos silenciosos. La propuesta de "Freeze the Retry Budget Before the Percentage" de dev.to sugiere un conjunto de métricas que obligan a publicar un techo de reintentos y una cota de tiempo.
El esquema propuesto es sencillo: cada tarea se describe en un JSON con campos obligatorios como task_id, prompt_template_id, oracle_cmd, hidden_tests_sha256, max_attempts y wall_clock_s. Si falta alguno, el runner lanza IncompleteScorecard. Además, el runner produce una scorecard con campos como passed, attempts_used, elapsed_ms, tool_trace_sha256 y scorecard_complete. Sólo cuando todos los campos están presentes se considera la puntuación válida para incluirla en una tabla.
Al fijar max_attempts y wall_clock_s se evita la comparación de un agente que pasa en el primer intento con otro que necesita un bucle silencioso de reparaciones. También se exige que la prueba oracle sea ejecutada en un entorno aislado sin escritura de red y con un seed fijo cuando sea necesario, garantizando que los resultados sean reproducibles.
El código de referencia que acompaña el artículo no es un runner funcional, sino un esqueleto que muestra cómo cargar una tarea, lanzar el agente, ejecutar la prueba oracle y escribir la trazabilidad. El script verifica que el número de reintentos no supere el techo y que el tiempo de ejecución no exceda el límite. Si alguna de esas condiciones falla, el runner aborta antes de publicar un porcentaje.
Para los administradores de sistemas y arquitectos, la propuesta ofrece una forma de evaluar agentes de codificación de manera controlada y reproducible. Al registrar tool_trace_sha256 se puede detectar reintentos silenciosos que, de lo contrario, quedarían ocultos. El uso de un sealed task pack –una colección de JSON con prompts y tests ocultos– garantiza que los resultados no dependen de repositorios en evolución.
En resumen, el esquema exige transparencia en los límites de reintentos y tiempo, y aporta métricas adicionales que permiten comparar agentes de codificación de forma realista. Si tu equipo decide adoptar esta metodología, la primera acción será generar un sealed task pack con los parámetros correctos y ejecutar el runner de referencia.
Para más detalles, consulta el artículo original en dev.to y el código de referencia en su repositorio.
