Métricas para agentes de código: cómo saber si realmente ahorran tiempo
Un agente que genera mucho codigo no necesariamente ahorra tiempo. La metrica correcta es trabajo aceptado, verificado y mantenible por unidad de coste.
Un agente que genera mucho codigo no necesariamente ahorra tiempo. La metrica correcta es trabajo aceptado, verificado y mantenible por unidad de coste.
Lineas generadas, commits creados o PRs abiertos no miden productividad. Pueden medir actividad. Un agente puede producir mucho codigo y aun asi aumentar trabajo si obliga a revisar, corregir y deshacer.
Metricas basicas
- Acceptance rate: porcentaje de cambios de agente que llegan a main sin reescritura sustancial.
- Review burden: numero y severidad de comentarios humanos por PR.
- Rework rate: porcentaje de cambios que requieren correccion posterior.
- Time to merge: tiempo desde tarea asignada hasta PR integrado.
- Defect escape rate: bugs que llegan despues de merge.
- Coste por PR aceptado: tokens, suscripciones, minutos de CI y tiempo humano.
Checklist
Mide coste completo
El coste no es solo tokens. Incluye tiempo de reviewer, minutos de CI, ejecuciones fallidas, contexto perdido, deuda tecnica y riesgo. Una tarea barata en API puede salir cara si genera un diff confuso.
Tambien hay coste de oportunidad: si el agente tarda veinte minutos en hacer algo que un senior hacia en diez, pero libera atencion durante esos veinte minutos, puede seguir siendo rentable. Por eso conviene medir calendario y foco humano, no solo duracion bruta.
Senales positivas
- El agente reduce espera en tareas repetibles.
- Los PRs son pequenos y faciles de revisar.
- Los tests agregados fallan antes del fix y pasan despues.
- Los comentarios humanos bajan con el tiempo.
- El equipo sabe en que tareas no usarlo.
- El coste por cambio aceptado se estabiliza.
Conclusion
Medir agentes de codigo exige disciplina de producto, no fe en demos. El valor no esta en que escriban rapido, sino en que entreguen cambios correctos con menos carga humana total.
Puntos a revisar
Lo que conviene comprobar
- La metrica final deberia ser aburrida: cambios aceptados, verificados y mantenibles por coste razonable. Todo lo demas es ruido de actividad.
Fuentes y referencias
También te puede interesar
GitHub Copilot y AI CreditsRTK: proxy CLI para reducir tokensCopilot Code Review y GitHub ActionsRecibe una lectura semanal de herramientas IA para devs
Cada martes: Claude Code, Cursor, Copilot, MCP, agentes y herramientas nuevas. En español y sin ruido.
Suscribirme gratis