Un método para que las notas de los agentes de código sean reproducibles
Una propuesta fija el conjunto de tareas con hash antes de ejecutar nada y sustituye el porcentaje único por un vector con tokens, reintentos y línea base.
Un porcentaje de éxito de un agente de código no es una medición hasta que un tercero puede repetir la ejecución. Esa es la tesis de una nota técnica que propone congelar el conjunto de tareas como un artefacto versionado antes de que el modelo haga la primera llamada, y publicar un vector de métricas en lugar de un solo número.
El dataset, antes que el modelo
Cada tarea sería un registro inmutable con hash, licencia y etiqueta de dificultad fijados antes de cualquier ejecución. El registro nombra el repositorio de origen, el commit donde falla el test y el oráculo que después juzgará el parche. Si esos metadatos se escriben cuando ya se conocen los resultados, el libro de cuentas está contaminado por la clasificación que pretende justificar.
También pide agrupar por clúster las tareas que comparten commit padre o una aserción fallida casi idéntica, para que un mismo bug no cuente como varias victorias independientes. Y describe el caso típico: un agente que parece resolver casi todo puede haber visto duplicados cercanos, haber quemado reintentos sin límite o haber compartido contexto con su propio evaluador.
El texto acompaña la idea con un script corto en Python que calcula el SHA-256 del fichero de tareas y aborta la evaluación si el digest no coincide con el valor fijado en el mismo commit que el harness. Ese rechazo es el mecanismo: cualquier pull request que añada tareas después de existir un ranking debe romper la puerta, no renegociar el porcentaje. El autor lo plantea como propuesta con ejemplos, no como cifras de un benchmark privado.
Vector en vez de trofeo
El segundo bloque ataca la métrica única. Una puntuación repetible debería llevarse al lado, para cada agente, la tasa de acierto, los tokens gastados, los segundos de reloj, el número de reintentos y el commit del harness. Sin esos acompañantes, dos agentes pueden compartir porcentaje mientras uno gastó una tarde que al otro no se le permitió.
A eso suma un control: una línea base congelada sobre el mismo ledger, con el mismo evaluador y el mismo sandbox. Lo relevante no es el porcentaje absoluto sino el desplazamiento frente a esa base. Si la base se mueve sola entre el martes y el jueves, la clasificación está midiendo el laboratorio y no al agente.
Conviene precisar qué hay aquí y qué no. No hay resultados de ningún modelo, ni repositorio público con el ledger, ni comparativa ejecutada. Es un esquema de método con ejemplos etiquetados como tales, y eso limita lo que se puede afirmar sobre él.
La parte útil, en cambio, es directamente trasladable. Cualquiera que publique números de agentes sobre tareas de código —interno o de cara a un cliente— puede adoptar el hash fijado antes de la primera llamada y el vector de métricas con base congelada. El coste es bajo y el beneficio es concreto: cuando alguien pida repetir la ejecución, habrá algo que repetir.
