Un agente que genera mucho código no necesariamente ahorra tiempo. La métrica correcta es trabajo aceptado, verificado y mantenible por unidad de coste.
Líneas generadas, commits creados o PRs abiertos no miden productividad. Pueden medir actividad. Un agente puede producir mucho código y aun así aumentar trabajo si obliga a revisar, corregir y deshacer.
La trampa de medir output — La pregunta correcta es: cuánto trabajo aceptado y mantenible produce el sistema por unidad de tiempo, coste y riesgo. Esa métrica es menos vistosa, pero mucho más cercana a valor real.
Métricas básicas
- Acceptance rate: porcentaje de cambios de agente que llegan a main sin reescritura sustancial.
- Review burden: número y severidad de comentarios humanos por PR.
- Rework rate: porcentaje de cambios que requieren corrección posterior.
- Time to merge: tiempo desde tarea asignada hasta PR integrado.
- Defect escape rate: bugs que llegan después de merge.
- Coste por PR aceptado: tokens, suscripciones, minutos de CI y tiempo humano.
Segmenta por tipo de tarea
Un agente puede ser excelente escribiendo documentación y mediocre en cambios de arquitectura. Puede arreglar bugs localizados y fallar en migraciones grandes. Si mezclas todo en una media global, no sabrás dónde usarlo.
Segmenta por docs, tests, fixes, features, refactors, migraciones, frontend, backend y seguridad. Después decide políticas por categoría. No todos los agentes deben poder tocar todo.
Mide el coste completo
El coste no es solo tokens. Incluye tiempo de reviewer, minutos de CI, ejecuciones fallidas, contexto perdido, deuda técnica y riesgo. Una tarea barata en API puede salir cara si genera un diff confuso.
También hay coste de oportunidad: si el agente tarda veinte minutos en hacer algo que un senior hacía en diez, pero libera atención durante esos veinte minutos, puede seguir siendo rentable. Por eso conviene medir calendario y foco humano, no solo duración bruta.
Señales positivas
- El agente reduce espera en tareas repetibles.
- Los PRs son pequeños y fáciles de revisar.
- Los tests agregados fallan antes del fix y pasan después.
- Los comentarios humanos bajan con el tiempo.
- El equipo sabe en qué tareas no usarlo.
- El coste por cambio aceptado se estabiliza.
Señales negativas
- Mucho código nuevo y pocas merges.
- PRs grandes con explicaciones genéricas.
- Tests que solo validan mocks.
- Correcciones humanas constantes sobre el mismo patrón.
- Coste creciente sin mayor throughput.
- Dependencia de un agente para entender cambios que nadie revisó bien.
Conclusión
Medir agentes de código exige disciplina de producto, no fe en demos. El valor no está en que escriban rápido, sino en que entreguen cambios correctos con menos carga humana total.
La métrica final debería ser aburrida: cambios aceptados, verificados y mantenibles por coste razonable. Todo lo demás es ruido de actividad.
Fuentes y referencias
- AIDev: Studying AI Coding Agents on GitHub
- Comparing AI Coding Agents: Task-Stratified PR Acceptance
- How AI Coding Agents Modify Code
- OpenAI Codex
¿Te ha resultado útil? Cada martes envío una lectura sobre herramientas IA para devs (Claude Code, Cursor, Copilot, MCP, agentes) en español y sin ruido. Suscríbete gratis.
Publicado originalmente en devaisemanal.com.
