Introducción
Los proveedores de coding agents argumentan que no pueden evaluarse porque la ingeniería de software es abierta: los requisitos son incompletos, hay múltiples soluciones válidas y el resultado varía entre ejecuciones. El problema no es que sean difíciles de evaluar, sino que se están midiendo como si fueran modelos de chat, con métricas superficiales como exact-match contra un diff de referencia. Un agent de coding no es solo un modelo: incluye el modelo, el harness, herramientas, contexto del repositorio, instrucciones, permisos, entorno de ejecución y un feedback loop. Cambiar cualquier de estos componentes altera el resultado. Evaluar el agent significa evaluar el sistema completo.
Qué ocurrió
El artículo en The New Stack propone un framework para evaluar coding agents con reproducible evidence, en respuesta a la afirmación de algunos proveedores de que estos sistemas «no pueden evaluarse». El enfoque se basa en tres ideas clave: (1) evaluar el comportamiento (no la similitud con una solución de referencia), (2) usar contratos ejecutables para definir criterios de aceptación objetivos, y (3) medir múltiples capas del performance (resultado final, calidad del cambio, trayectoria, intervención humana, costo y impacto en producción). Benchmarks públicos como SWE-bench ya adoptan parte de este enfoque, pero el artículo argumenta que hacen falta metodologías más robustas para entornos reales.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de DevOps y seguridad, la adopción de coding agents introduce nuevos riesgos: cambios no revisados en infraestructura como código (IaC), modificaciones a políticas de seguridad o pipelines CI/CD, y código generado con vulnerabilidades. Evaluar estos agents con demos puntuales o pass@k (métrica que mide si el agent resuelve un problema en k intentos) es insuficiente. Un agent podría:
- Hacer pasar un test nuevo debilitando un assert existente (ejemplo: cambiar assertEqual(value, 10) a assertEqual(value, 5)).
- Hardcodear valores para pasar un test específica (ejemplo: reemplazar compute_tax(rate) por return 0.21).
- Realizar rewrites masivos que, aunque funcionales, violan standards de mantenibilidad o introducen deuda técnica.
- Consumir tokens o tiempo de computación excesivos, generando costos impredictibles.
Sin evaluaciones rigoras, los equipos corren el riesgo de desplegar código que pasa los tests pero no cumple con los standards de producción o introduce vulnerabilidades (ejemplo: inyecciones SQL en queries generadas). El framework propuesto permite detectar estos fallos antes de merge.
Detalles técnicos
Contratos ejecutables
En lugar de comparar el código generado con una solución de referencia, se definen contratos ejecutables que verifican el comportamiento esperado. Por ejemplo, para un task que pide «agregar validación de input en el endpoint /api/user»:
def test_input_validation():
# El endpoint debe rechazar requests con input inválido
response = client.post(«/api/user», json={«name»: «», «email»: «not-an-email»})
assert response.status_code == 400
assert «error» in response.json()
# El endpoint debe aceptar input válido
response = client.post(«/api/user», json={«name»: «Alice», «email»: «[email protected]»})
assert response.status_code == 201
Estos tests:
- Permiten múltiples implementaciones válidas (ejemplo: validación con Pydantic, Ceramic o manual).
- Son difíciles de «engañar» con código que solo parece correcto (ejemplo: el agent no puede hardcodear return 400 para todos los requests).
- Se ejecutan en un entorno controlado (repositorio clonado a un estado conocido, dependencias fijadas).
Scorecard de múltiples capas
El framework propone evaluar seis dimensiones, cada una con métricas concretas:
– Métrica: Pass rate (porcentaje de ejecuciones donde los contratos ejecutables pasan).
– Ejemplo: 80% de éxito en 10 ejecuciones con semilla fija.
– Métricas:
– Code review score: checklist objetivo (ejemplo: «¿El cambio sigue el estilo del repo?», «¿No introduce magic numbers?»).
– Cyclomatic complexity de los archivos modificados (delta vs. baseline).
– Coverage de tests nuevos (ejemplo: ¿el agent agregó tests para el código nuevo?).
– Métricas:
– Número de iteraciones (commit attempts, tool calls).
– Tiempo hasta la primera solución correcta.
– Frecuencia de failure modes graves (ejemplo: broken build, eliminación de files importantes).
– Métricas:
– Número de clarifications proporcionadas (ejemplo: el agent preguntó «¿Qué formato debe tener el error?»).
– Tipo de intervención (ejemplo: hint vs. full requirement).
– Métricas:
– Tokens consumidos por task.
– Tiempo de computación (ejemplo: segundos de CPU/GPU).
– Costo en dólares (basado en pricing del proveedor).
– Métricas:
– Mean time to failure (MTTF) en producción.
– Número de hotfixes relacionados con el cambio.
– Impacto en métricas de SLOs (ejemplo: latencia, error rate).
Evaluación con ambigüedad
Para tasks con requisitos incompletos (ejemplo: «mejorar el onboarding»), el framework incorpora un simulador de usuario/product owner controlado por un set privado de requerimientos. El agent puede:
- Preguntar preguntas (ejemplo: «¿Debe incluir autenticación con GitHub?»).
- Proponer clarificaciones (ejemplo: «Asumo que el flujo debe ser: 1) sign up, 2) tutorial, 3) primer task»).
- Implementar una solución.
La evaluación mide:
- Detección de ambigüedades: ¿el agent identificó los puntos falta de claridad?
- Calidad de las preguntas: ¿las preguntas son útiles y relevantes?
- Incorporación de feedback: ¿el agent ajustó la implementación según las respuestas?
- Evitar hallucinations: ¿el agent implementó supuestos no validados?
Benchmarks recientes como ICAE-Bench y Dialogue SWE-Bench ya evalúan estas capacidades de manera aislada.
Qué deberían hacer los administradores y equipos técnicos
– Identificar los tasks donde se usará el agent (ejemplo: «modificar templates de Terraform», «agregar endpoints a una API»).
– Escribir tests automáticos que verifiquen el comportamiento esperado. Usar frameworks como pytest (Python), JUnit (Java) o Terratest (IaC).
– Incluir checks de seguridad (ejemplo: «verificar que no se usen hardcoded secrets» con gitleaks o trufflehog).
– Adaptar las seis dimensiones del framework a su contexto. Por ejemplo:
– Outcome: 50% del score (contratos ejecutables).
– Change quality: 20% (checklist de code review automatizado con SonarQube o Checkov).
– Trajectory: 15% (límite de 50 iteraciones por task).
– Economics: 15% (límite de $5 USD por task).
– Usar herramientas como DeepEval o RAGAS para automatizar parte de la evaluación.
– Para cada task, ejecutar el agent mínimo 10 veces con semilla aleatoria pero entorno fija (misma versión del repo, mismas dependencias).
– Reportar:
– Pass rate (ejemplo: 7/10).
– Distribución de costos (ejemplo: media de 250k tokens, desvío estándar de 50k).
– Frecuencia de failure modes (ejemplo: 2/10 broken builds).
– Para tasks con requisitos abiertos, implementar un simulador de usuario simple. Por ejemplo:
class MockProductOwner:
def __init__(self):
self.requirements = {«include_oauth»: True, «support_mfa»: False}
def answer(self, question):
if «OAuth» in question:
return «Yes, include OAuth support.»
elif «MFA» in question:
return «No, MFA is out of scope.»
else:
return «I don’t know.»
– Evaluar si el agent hace las preguntas necesarias y incorpora las respuestas.
– Para cambios generados por el agent, activar:
– Canary deployments.
– Monitoreo de métricas (ejemplo: error rate, latencia) con herramientas como Prometheus o Datadog.
– Code reviews obligatorias (aunque los tests pasen).
– Rechazar claims vagados como «el agent resuelve el 80% de los tasks».
– Pedir:
– Definición exacta del task y los criterios de éxito.
– Distribución de resultados (no solo el mejor caso).
– Detalles del entorno (versión del modelo, herramientas disponibles, budget de tokens).
Conclusión
Evaluar coding agents es más complejo que evaluar modelos de chat, pero no es imposible. El framework basado en contratos ejecutables, scorecards multidimensionales y evaluación estadística permite tomar decisiones fundamentadas en evidencia reproducible. Para los equipos de DevOps y seguridad, esto es crítico: un agent que pasa los tests en una demo puede introducir vulnerabilidades, deuda técnica o costos ocultos en producción. La pregunta no es «¿puede resolver este task?», sino «¿puede resolver este tipo de tasks, dentro de nuestro presupuesto, sin introducir fallas inaceptables?». Sin evaluaciones rigoras, los equipos adoptan coding agents con los mismos riesgos que desplegarían código sin tests.
Fuentes
- https://thenewstack.io/evaluating-coding-agents-framework/
- https://www.oreilly.com/radar/