Cómo evaluar agentes más allá de las pruebas superadas

Un agente de programación que supera las pruebas visibles de una tarea aún puede ser peligroso para fusionar. Puede borrar un comportamiento antiguo que nadie incluyó en los casos de prueba, editar un archivo generado en lugar de su fuente, dedicar cuarenta minutos a explorar el subsistema equivocado o producir un parche que solo tiene sentido en el repositorio que conocían sus diseñadores. Una evaluación seria debe detectar esos resultados, no felicitar al agente por conseguir indicadores verdes.

La unidad útil no es una ejecución de pruebas. Es un intento de tarea con un estado inicial del repositorio, una instrucción, un presupuesto, una trayectoria observable, un parche y varios juicios independientes. Tratar todo el intento como evidencia cambia lo que mide el equipo y los fallos que corrige.

Cómo debe definirse una tarea para un agente de programación

Una tarea para un agente de programación necesita un commit inicial congelado, una petición realista, un entorno de ejecución explícito y comprobaciones de aceptación ocultas. Sin los cuatro elementos, dos ejecuciones que parecen resolver la misma incidencia pueden resolver problemas distintos.

Empiece con trabajo parecido al que llega a la cola real. Una tarea puede ser un informe de error, una función pequeña, la migración de una dependencia o un cambio operativo. Conserve la ambigüedad que una persona competente resolvería leyendo el repositorio, pero elimine la que solo podría aclarar un empleado que ya se fue. "Corregir el redondeo de la factura cuando una línea de crédito sigue a una línea sujeta a impuestos" es justo si el código y el comportamiento existente contienen la respuesta. "Conseguir que finanzas esté contento" no lo es.

Fije algo más que el commit. Registre la cadena de herramientas, la política de caché de dependencias, las variables de entorno disponibles para el agente, la política de red, los puntos de entrada de las pruebas y los límites de recursos. Si el entorno cambia, la puntuación mezcla la calidad del agente con la suerte del runner. Las imágenes de build deben tener identificadores inmutables y los fixtures deben versionarse junto al evaluador.

Cada registro de tarea debe poder inspeccionarse. Una especificación compacta podría ser esta:

{
  "task_id": "billing-credit-rounding-014",
  "repo_commit": "4f93c2a",
  "request": "Preserve tax rounding when a credit line follows a taxable line.",
  "visible_checks": ["test_billing_unit"],
  "hidden_checks": ["credit_after_tax", "mixed_currency_unchanged"],
  "budget": {"wall_seconds": 900, "model_cost_usd": 8.00},
  "allowed_paths": ["src/billing", "tests/billing"]
}

Las comprobaciones ocultas no son una trampa. Impiden que el agente se optimice directamente contra toda la hoja de respuestas. Mantenga algunas comprobaciones de comportamiento fuera del repositorio y cambie una parte de ellas, porque los agentes pueden deducir mucho de los nombres de pruebas y los fixtures cercanos.

Ejecute cada tarea varias veces. El comportamiento del agente cambia aunque el modelo y el prompt sean idénticos. Un acierto afortunado demuestra que la tarea es posible. Los intentos repetidos indican si el sistema es fiable. Guarde la semilla o los ajustes de muestreo cuando el proveedor los muestre, pero no finja que eliminan toda variación.

Por qué superar las pruebas solo aporta un juicio

Las pruebas responden si determinadas observaciones coinciden con lo esperado. No demuestran que el parche tenga el alcance correcto, sea mantenible y seguro, o respete comportamientos que la suite nunca codificó.

Puntúe la finalización de la tarea por capas. Primero, ejecute las comprobaciones visibles que el agente podía usar. Segundo, lance pruebas ocultas que ejerciten entradas cercanas y el caso límite notificado. Tercero, ejecute comprobaciones de todo el repositorio, como lint, tipos, builds y pruebas de paquetes dependientes. Cuarto, examine propiedades que los frameworks de pruebas rara vez detectan: cambios en archivos prohibidos, nuevas dependencias, modificaciones de API públicas, migraciones, artefactos generados y eliminaciones sospechosas de pruebas.

Mantenga esos juicios separados en lugar de reducirlos enseguida a un porcentaje. Un parche que arregla el objetivo pero rompe un paquete no relacionado no es igual que otro que nunca arregló el objetivo. Ambos bloquean la entrega, pero apuntan a remedios distintos. El primero sugiere un análisis de impacto débil o una exploración insuficiente del repositorio. El segundo indica una mala implementación o una comprensión equivocada de la tarea.

La inspección del parche puede automatizarse en parte. Rechace ediciones fuera de una lista permitida cuando la tarea tenga un límite estrecho. Marque reducciones del número de aserciones, nuevas omisiones, manejadores de excepciones demasiado amplios y cambios en snapshots. Son motivos de revisión, no pruebas automáticas de engaño. Una corrección legítima puede actualizar un snapshot o retirar una aserción obsoleta, así que conserve el diff y la explicación del agente para la revisión humana.

Añada una rúbrica breve para cualidades que las máquinas aún no juzgan de forma consistente. Los revisores pueden valorar si el parche sigue las abstracciones locales, valida en el límite correcto, deja código muerto o añade carga de mantenimiento. Use opciones ancladas como "coincide con un patrón existente en el repositorio" y "crea un mecanismo paralelo". Las notas imprecisas de uno a cinco cambian entre revisores y enseñan muy poco.

La decisión de aprobado debe ser estricta: el comportamiento requerido, las comprobaciones de regresión y la salud del repositorio tienen que superar los controles. El registro de diagnóstico debe seguir siendo rico. Muchos equipos arruinan una evaluación al guardar solo el resultado verde o rojo y luego carecen de pruebas cuando una nueva versión del agente mueve la puntuación.

El comportamiento ya corregido pertenece a la suite

Una evaluación de agentes de programación debe reproducir errores que su equipo ya pagó por entender. Esos casos exponen el riesgo de regresión mucho mejor que una colección compuesta solo por incidencias nuevas y ordenadas.

Cuando se corrige un error de producción, conserve tres elementos: el estado del repositorio antes de la corrección, el síntoma visible para el usuario y un oráculo que distinga el comportamiento correcto. El oráculo puede ser una prueba enfocada, una petición y respuesta grabadas, una transición de estado de la base de datos o un comando con salida normalizada. Elimine secretos y marcas de tiempo inestables antes de guardar tráfico.

Hay dos preguntas de regresión diferentes. "¿Puede el agente resolver un error antiguo desde el estado roto?" mide la capacidad de reparación. "¿Un nuevo parche para otra tarea vuelve a introducir ese error antiguo?" mide la conservación del comportamiento. Los equipos las confunden y terminan con un benchmark que premia la reparación sin decir nada del daño colateral.

Construya un banco acumulativo de comportamientos con incidentes cerrados y hallazgos difíciles de las revisiones. Etiquete cada caso por subsistema, mecanismo de fallo y consecuencia, y seleccione casos relevantes para cada tarea junto con una muestra más pequeña de todo el repositorio. El conjunto relevante detecta roturas cercanas. La muestra descubre acoplamientos sorprendentes, como un formateador de facturación que cambia una exportación porque ambos usan la misma función de redondeo.

No ejecute únicamente la rama predeterminada actual contra el banco. Ejecute el parche exacto del agente sobre su base congelada, porque cambios humanos posteriores pueden ocultar o crear fallos. Si una prueba falla tanto en la base como en el parche, clasifíquela como ruido preexistente. Si pasa en la base y falla después del parche, la regresión corresponde al intento.

Las comprobaciones inestables necesitan cuarentena con un responsable y evidencia, no reintentos silenciosos hasta obtener verde. Registre cada ejecución individual. Una política de reintento puede indicar si el parche se puede publicar según las reglas actuales de CI, pero los resultados sin procesar revelan que el entorno de evaluación o el producto no es determinista. Mezclarlos mejora la apariencia del agente sin hacer más seguro el parche.

Un banco de comportamientos crece en coste, así que divídalo por niveles. Ejecute los casos rápidos y próximos en cada intento, una reproducción más amplia antes de aceptar una versión candidata del agente y los casos de sistema más lentos según un calendario. La cobertura debe crecer de forma monótona: un caso solo se retira cuando el comportamiento deja de existir o un oráculo mejor lo sustituye.

El coste necesita un denominador y un registro de fallos

El coste por tarea completada con éxito es más útil que el gasto de tokens por ejecución. Los intentos baratos que fallan o exigen que una persona repare el parche no son trabajo barato.

Registre los cargos de entrada y salida del modelo, los tokens de caché, el cálculo de las herramientas, el tiempo de sandbox y cualquier servicio externo de pago que invoque la ejecución. Mantenga el tiempo de revisión técnica en un campo separado en vez de inventar un valor monetario. Aun así podrá comparar la mediana de minutos de revisión entre versiones del agente y clases de tarea.

Observe el coste desde al menos cuatro perspectivas:

• el coste por intento expone exploraciones descontroladas;
• el coste por tarea aceptada incluye los intentos fallidos;
• el coste por clase de tarea y repositorio impide que el trabajo fácil oculte el caro;
• el coste de ejecuciones desperdiciadas por categoría de fallo señala defectos de orquestación corregibles.

Informe distribuciones, no solo promedios. La mediana describe una ejecución normal, mientras que el percentil 90 o 95 encuentra agentes que recorren en bucle los mismos archivos, recompilan una y otra vez o vuelcan todo el repositorio en el contexto. Un presupuesto firme debe detener esas ejecuciones y marcarlas como presupuesto agotado, no como un fallo ordinario de la tarea.

La caché complica las comparaciones. Una caché de dependencias caliente puede ser realista para un worker interno de CI, pero una caché caliente de prompts puede abaratar artificialmente las tareas repetidas del benchmark. Elija la condición que represente la producción, etiquétela e incluya una muestra con caché fría. Nunca compare una versión en tareas calientes con otra en tareas recién creadas.

El registro de fallos importa porque los ahorros proceden de cambios distintos. Si la mayor parte del gasto perdido viene de fallos al preparar el entorno, cambiar de modelo no ayudará. Si el agente lee repetidamente código de terceros incluido en el repositorio, mejore las instrucciones o los filtros de herramientas. Si alcanza un parche correcto tras largos ciclos de prueba, mejore la selección de pruebas y los builds incrementales.

Los límites de coste también cambian el comportamiento. Con un tope ajustado, el agente puede implementar la primera solución plausible y omitir una verificación amplia. Evalúe la calidad con varios presupuestos antes de declarar eficiente una configuración. El punto operativo útil está donde una unidad adicional de gasto deja de aumentar de forma apreciable las tareas aceptadas o de reducir las regresiones graves.

La latencia debe seguir el camino crítico

Mida el tiempo transcurrido tal como lo experimenta el usuario y divídalo en fases sobre las que el equipo pueda actuar. Una sola duración no indica si el retraso proviene del razonamiento del modelo, el inicio de una herramienta, la instalación de dependencias, las pruebas o un runner congestionado.

Registre las marcas de tiempo de entrada en la cola, disponibilidad de la sandbox, primera respuesta del modelo, cada llamada a herramienta, primer parche, inicio de la verificación y resultado final. A partir de esos eventos, calcule tiempo en cola, preparación, tiempo hasta la primera edición, actividad del agente, verificación y total. Mantenga separadas la latencia del modelo y la duración de los comandos.

El tiempo hasta la primera edición es especialmente revelador. Un tiempo muy corto puede indicar que el agente adivinó antes de leer las convenciones locales. Uno muy largo puede significar que vagó por directorios irrelevantes. Ninguno es malo por sí mismo, así que relaciónelo con la aceptación del parche y los archivos inspeccionados.

CI también debe medir la latencia del camino crítico en lugar de sumar trabajo paralelo. Si las pruebas unitarias y el análisis estático se ejecutan juntos durante ocho minutos, el usuario esperó ocho minutos, no dieciséis. El consumo de recursos aún puede sumar dieciséis minutos de worker, que pertenecen al registro de costes.

Defina objetivos por clase de tarea. Una corrección de configuración de un archivo y un cambio de esquema entre varios paquetes no deben compartir el mismo umbral. Compare el agente con el flujo humano que sustituye o ayuda: tiempo hasta un parche revisable, tiempo hasta la fusión aceptada y tiempo dedicado por el revisor. El agente puede tardar más en producir el parche y aun así acabar antes si sus pruebas facilitan la revisión. También puede ser rápido y consumir una tarde en correcciones.

Los tiempos agotados merecen un resultado propio. No puntúe una ejecución agotada igual que un parche incorrecto. Conserve su último estado coherente, la traza de herramientas y el presupuesto usado. Los agotamientos repetidos en un repositorio suelen revelar un problema del evaluador, como un comando de pruebas que espera un servicio no disponible, en lugar de una generación de código deficiente.

Ejecute el benchmark de latencia en workers controlados y observe por separado la CI compartida. Las ejecuciones controladas sirven para comparar modelos. Las compartidas muestran la planificación de capacidad y la experiencia real de los desarrolladores. Mezclarlas crea una cifra ruidosa que no responde a ninguna de las dos preguntas.

Los repositorios desconocidos muestran fallos distintos

Un agente evaluado solo en repositorios conocidos por sus diseñadores heredará sus suposiciones. Un código que usted no escribió comprueba si el agente puede descubrir las reglas en lugar de recibirlas mediante el diseño del benchmark.

Los fallos habituales empiezan antes de generar código. El agente elige el comando de prueba incorrecto, confunde código generado con la fuente, omite un segundo lenguaje del build, ignora una convención local de parches o edita un módulo compartido sin encontrar sus consumidores. Estos intentos pueden compilar y superar una prueba enfocada. Fallan porque el agente dibujó un mapa equivocado del sistema.

Seleccione repositorios externos o recién adquiridos con permiso legal y un build reproducible. Congélelos antes de que los autores de tareas los exploren a fondo. Pida a un grupo que prepare el entorno y a otro que cree tareas a partir del historial real de incidencias o defectos observados. Si la misma persona estudia el código, escribe pistas detalladas y juzga el resultado, su conocimiento se filtra en la instrucción.

Mida el comportamiento de descubrimiento sin prescribir una secuencia ideal. Las señales útiles incluyen si el agente lee las instrucciones del repositorio, identifica los puntos de entrada del build, busca sitios de llamada antes de cambiar un símbolo compartido, advierte varias implementaciones y revisa el diff antes de terminar. No dé puntos por el número de llamadas a herramientas. Diez búsquedas pueden reflejar cuidado o confusión.

Incluya repositorios con rasgos incómodos pero reales: varios lenguajes, generadores propios, pocas pruebas, fixtures grandes, scripts específicos de una plataforma y nombres de directorio engañosos. No fabrique trampas. El objetivo es saber si el agente maneja historia acumulada normal, no si resuelve un acertijo diseñado por el evaluador.

La contaminación es difícil de demostrar, así que diseñe para reducirla. Use código privado cuando tenga autorización, snapshots recientes que no pudieron aparecer en conjuntos de entrenamiento antiguos y transformaciones locales como cambiar nombres de entidades del negocio. Renombrar por sí solo no crea un problema de razonamiento nuevo, pero reduce la memorización simple. La evidencia fuerte viene de un rendimiento comparable en repositorios conocidos y realmente desconocidos, no de preguntar al modelo si recuerda el código.

La trayectoria explica fallos que el parche no muestra

Guarde las acciones observables del agente porque el diff final no muestra cómo encontró la respuesta, qué ignoró ni por qué agotó su presupuesto. Una traza compacta de eventos permite reproducir los fallos sin pedir razonamiento privado del modelo.

Para cada turno del modelo, conserve la versión del prompt, el identificador de respuesta, el uso de tokens, la petición de herramienta, el estado del resultado, las marcas de tiempo y los archivos o comandos afectados. Oculte secretos antes de guardar y limite estrictamente el tamaño de las salidas de comandos. El agente puede imprimir valores del entorno o datos del cliente mientras depura, así que el acceso a las trazas debe igualar el acceso al código fuente.

No puntúe textos de razonamiento oculto ni premie al agente por narrar el enfoque que usted esperaba. Los proveedores exponen señales internas diferentes y una explicación pulida puede esconder malas decisiones. Juzgue acciones y artefactos: leyó las instrucciones del build, buscó llamadas, cambió un archivo, ejecutó una comprobación enfocada, vio un fallo y revisó el parche.

Clasifique el primer giro equivocado decisivo. Los síntomas posteriores suelen derivarse de él. Si el agente edita un cliente generado, luego lucha contra el generador y finalmente agota el tiempo, "tiempo agotado" describe el estado terminal, no la respuesta técnica correcta. La categoría útil es identificación de la fuente de verdad. Otras categorías pueden ser descubrimiento del entorno, interpretación de la tarea, elección de dependencias, análisis de impacto, implementación y verificación.

Registre la recuperación además del fallo. Un agente que detecta una suposición errónea después de una comprobación fallida es distinto de otro que repite seis veces el mismo comando. Entre las métricas útiles están las llamadas idénticas repetidas, el tiempo entre un fallo y la siguiente edición, la proporción de archivos inspeccionados fuera del subsistema cambiado y si la verificación final se ejecutó sobre un estado limpio. Interprete estas señales junto al resultado de la tarea. Ninguna es por sí sola una puntuación de calidad.

Las trazas también revelan interferencias del arnés. Una herramienta puede truncar justo el error del compilador que identifica el defecto, una política de sandbox puede bloquear un comando normal del repositorio o la capa de orquestación puede declarar que un comando tuvo éxito tras matar su proceso hijo. Mantenga separados los eventos del evaluador y del agente para que se vea el propietario de cada fallo.

La retención necesita una política deliberada. Conserve el parche, los resultados normalizados y las métricas agregadas durante más tiempo que las salidas brutas de los comandos. Cuando borre trazas detalladas, mantenga las etiquetas de fallo y las versiones del evaluador para permitir comparaciones históricas. Un archivo de evaluación que acumula en silencio credenciales y fragmentos de producción constituye en sí mismo un control de seguridad fallido.

El evaluador puede fallar antes que el agente

Un arnés de evaluación es software de producción. Si su oráculo es incorrecto, la sandbox filtra estado o el fixture de tarea no compila, la puntuación mide defectos del evaluador.

Valide cada tarea con dos controles. El control negativo es el commit roto sin cambios y debe fallar en el oráculo objetivo. El control positivo es la corrección humana conocida y debe superar los oráculos objetivo y de regresión. Una tarea que falla cualquiera de los controles queda fuera del conjunto puntuado hasta que se repare.

Después pruebe el aislamiento. Dé a cada intento un worktree nuevo, un espacio de procesos limpio, un reloj controlado cuando el tiempo importe y recursos de servicio únicos. Una base de datos dejada por la ejecución anterior puede hacer que el siguiente parche parezca correcto. Las cachés de dependencias compartidas pueden ser aceptables, pero no deben contener resultados mutables de la tarea.

El runner debe emitir un resultado compacto y estable que CI pueda conservar:

$ ./eval-agent fixtures/billing-credit-rounding-014
task=billing-credit-rounding-014 outcome=regression
target=pass hidden=pass repository=fail
cost_usd=3.42 wall_seconds=286 review=required
artifacts=patch.diff,events.json,test-results.xml

Normalice los valores no deterministas antes de comparar salidas. Ordene registros sin orden, sustituya identificadores generados por marcadores estables y compare datos estructurados en lugar de capturas de pantalla o logs cuando sea posible. Cada regla de normalización puede ocultar un defecto, así que conserve el artefacto bruto junto al normalizado.

Versione el evaluador, la tarea y el oráculo de manera independiente. Cuando cambie un oráculo, guarde suficientes metadatos para reproducir puntuaciones antiguas y recalcularlas si es posible. Una versión del modelo no debe parecer mejor solo porque alguien relajó un fixture en la misma pull request.

Revise manualmente una muestra de fallos del evaluador. Inspeccione errores de infraestructura, aprobados sospechosamente rápidos y grupos donde todas las versiones del agente fallan de forma idéntica. Suelen ser tareas rotas. Contarlas como fallos del modelo puede parecer conservador, pero dirige el trabajo técnico al sistema equivocado.

El cuadro de mando debe conservar los fallos graves

El cuadro de mando debe aclarar las decisiones de lanzamiento sin diluir una regresión de seguridad o una corrupción de datos en promedios. Use barreras para resultados inaceptables y métricas para las compensaciones.

Empiece con barreras de elegibilidad: el agente debe permanecer en el entorno permitido, evitar accesos prohibidos a secretos, producir un parche revisable y superar todos los oráculos de regresión grave. Cualquier infracción vuelve inelegible al candidato sin importar su tasa media de éxito. Defina la gravedad antes de ejecutar la comparación o los equipos cambiarán la etiqueta de los fallos incómodos después de verlos.

Para candidatos elegibles, muestre una tabla por clase de tarea y repositorio. Incluya tasa de tareas aceptadas, tasa de corrección del objetivo, tasa libre de regresiones, mediana y cola del coste por tarea aceptada, mediana y cola del tiempo total, minutos de revisión y categorías de fallo. Muestre recuentos junto a los porcentajes. Tres aciertos de cuatro y setenta y cinco de cien comparten porcentaje, pero no confianza.

Evite una puntuación ponderada única salvo que un sistema de selección automática la necesite. Los pesos ocultan decisiones de política e invitan a discutir la aritmética. Una revisión de lanzamiento puede preguntar si el candidato supera todas las barreras, mejora las métricas que importan y mantiene las regresiones dentro de la tolerancia declarada.

Compare con referencias útiles. Incluya la configuración actual del agente, un agente mínimo con menos herramientas y un estado sin agente donde el evaluador no aplica ningún parche. Los resultados humanos pueden ayudar cuando las tareas y condiciones de trabajo son comparables, pero los mantenedores expertos en su propio código no son la referencia universal de un agente que llega a un repositorio desconocido.

Segmente los resultados antes de confiar en el agregado. Revise lenguaje, tamaño del repositorio, calidad de las pruebas, tipo de tarea y si el cambio cruza límites de subsistemas. Un candidato puede mejorar la tasa principal al avanzar mucho en pequeños cambios de TypeScript y empeorar a la vez en migraciones de bases de datos.

Trate las anulaciones de revisores como datos. Si un revisor acepta un parche que rechaza el arnés, o rechaza uno que el arnés aprueba, exija un código de motivo e inspeccione el oráculo. El revisor puede equivocarse, pero el desacuerdo permite aprender al cuadro de mando.

El despliegue en CI necesita controles y reglas de parada

Despliegue un agente de programación mediante CI como un cambio medido, con un periodo de comparación fijo y condiciones de parada. Ejecutarlo enseguida en todas las pull requests convierte a los desarrolladores en infraestructura de evaluación no remunerada.

Empiece en modo sombra con tareas representativas. El agente recibe el mismo estado del repositorio y la misma petición, pero no puede modificar la rama real. Compare su parche y evidencia con el resultado del trabajo normal. El modo sombra descubre carencias del entorno y carga de revisión sin situar sus cambios en la ruta de fusión.

Después, permita sugerencias en clases de tareas de baja consecuencia con revisión obligatoria. Mantenga al azar un grupo de control con la versión anterior del agente o el flujo normal. Sin un control concurrente, los cambios en la mezcla de tareas, actividad del repositorio y carga de CI pueden parecer mejoras.

Escriba las reglas de parada antes del despliegue. Pause las sugerencias automáticas si aparece una regresión grave, se cruzan límites de secretos, los errores de infraestructura del evaluador superan la tolerancia o el coste de cola rebasa el presupuesto. Una regla debe indicar quién puede reanudar el despliegue y qué evidencia necesita.

Vigile la adaptación. Los desarrolladores pueden empezar a escribir incidencias demasiado explícitas para el agente, evitar tareas que resuelve mal o aprobar sin atención formas de parche conocidas. Esos cambios afectan al rendimiento aparente. Revise una muestra de peticiones y comentarios, y mantenga un benchmark estable fuera de la cola activa.

El arnés de paridad que usamos en CodeHero compara el comportamiento del sistema reescrito con tráfico de producción grabado, porque un build limpio no demuestra que décadas de casos límite hayan sobrevivido a un cambio de arquitectura. El mismo principio se aplica a un agente de CI: conserve el comportamiento real como evidencia ejecutable y juzgue cada parche contra él.

La promoción debe ser reversible. Mantenga disponible la configuración antigua, etiquete cada parche del agente con la versión del evaluador y conserve el intento suficiente tiempo para investigar regresiones posteriores. Si no puede relacionar un defecto de producción con el prompt, el estado del repositorio, el parche y las comprobaciones que lo aprobaron, el registro de evaluación está incompleto.

Repita el benchmark después de cualquier cambio importante del modelo, prompt del sistema, permisos de herramientas, composición del contexto o imagen del runner. Esos componentes interactúan, así que una etiqueta de versión del modelo no identifica el sistema que produjo un parche. Mantenga un conjunto canario pequeño y estable para comparaciones rápidas y actualice el conjunto amplio según cambie el trabajo real. Cuando retire tareas, ejecute los conjuntos antiguo y nuevo durante un periodo común para que un cambio de dificultad no parezca un cambio de calidad.

Un agente solo merece más autoridad cuando produce repetidamente parches aceptables en los repositorios donde trabajará y dentro de un presupuesto que el equipo puede defender. Las pruebas verdes abren la revisión. No la terminan.