El rendimiento de los agentes de programación debe medirse a través de dos números leídos en conjunto: las pull requests fusionadas y la tasa de rechazo (denial rate), es decir, el porcentaje de pull requests cerradas sin llegar a fusionarse. Añada el tiempo de ciclo desde el plan hasta el merge y el coste por pull request fusionada, y tendrá información suficiente para determinar si los agentes producen trabajo aceptado a un precio justificable. Las pull requests abiertas, la métrica que la mayoría de los equipos reporta primero, no es suficiente por sí sola: un agente puede abrir cincuenta pull requests al día que nadie llega a fusionar, y ese dato parecerá un progreso cuando no lo es. Este artículo define cada métrica, explica qué indica un mal resultado y muestra cómo Ivy Tendril y una calculadora gratuita de Ivy realizan su seguimiento.

Las métricas

Métrica	Definición	Qué significa un mal resultado
PRs abiertas	Pull requests creadas en el período	Por sí sola, nada. Un valor alto y creciente con fusiones estancadas significa que los agentes generan trabajo que el equipo no desea
PRs fusionadas	Pull requests fusionadas en el período	Estancadas o en descenso mientras las abiertas aumentan: la revisión es el cuello de botella o la calidad está cayendo
Tasa de rechazo	PRs cerradas sin fusionar, divididas entre todas las PRs cerradas (fusionadas más cerradas no fusionadas)	Alta: los planes son erróneos, la verificación es débil o los revisores rechazan tarde. Cercana a cero con bajo volumen: solo se intenta el trabajo más seguro
Tiempo de ciclo	Tiempo desde la creación del plan hasta la fusión	Largo: el trabajo se detiene en un punto de control humano. Descubra en cuál
Coste por PR fusionada	Total de tokens o dólares en el período, dividido entre PRs fusionadas	En aumento: reintentos (retries), planes desmesurados o modelos caros donde uno más económico superaría la verificación
Tasa de aprobación de verificación	Porcentaje de ejecuciones que superan pruebas, linter y compilación al primer intento	Baja: los planes están incompletos o el agente carece de contexto sobre el código base

Dos definiciones requieren especial cuidado. La tasa de rechazo utiliza las PRs cerradas como denominador —no las PRs abiertas— para que las pull requests abiertas que aún están bajo revisión no computen ni como aceptadas ni como rechazadas. El coste por PR fusionada divide todo el gasto —incluido el invertido en planes rechazados o descartados— únicamente entre las pull requests efectivamente fusionadas. Esto es intencionado: el coste del trabajo descartado forma parte indispensable del coste del trabajo fusionado.

Por qué las PRs fusionadas y la tasa de rechazo forman la pareja honesta

Cualquier métrica individual puede mejorarse empeorando otra.

Las PRs abiertas aumentan si se relajan los criterios de lo que se autoriza a ejecutar. La tasa de rechazo aumenta junto con ellas.
Las PRs fusionadas aumentan si los revisores aprueban con excesiva prisa. Los defectos detectados tras el merge se disparan, y la tasa de rechazo cae por la razón equivocada.
La tasa de rechazo disminuye si solo se ejecutan los planes más triviales y seguros. Las PRs fusionadas caen en picado como consecuencia.

Esta es la misma lógica que fundamenta las métricas DORA, donde el rendimiento (throughput) y la estabilidad siempre se presentan como un par inseparable, precisamente porque cualquier indicador aislado puede manipularse sacrificando el otro. Las PRs fusionadas y la tasa de rechazo leídas de manera conjunta evitan esta distorsión. Para aumentar las fusiones sin disparar los rechazos, es necesario producir más trabajo que el equipo acepte genuinamente. Para reducir la tasa de rechazo sin recortar las fusiones, es imperativo perfeccionar los planes o la verificación, en lugar de reducir el volumen de ejecución. Ninguna de las dos cifras puede optimizarse ignorando a la otra.

La tentación de medir las PRs abiertas radica en que es lo primero que entrega un agente y lo más sencillo de contabilizar. Sin embargo, una pull request abierta no es más que una solicitud del tiempo de otra persona. Contar solicitudes como producción útil premia a los agentes por saturar a los revisores. Contar fusiones efectivas los premia por completar el trabajo con éxito.

Ivy publica sus propios datos siguiendo este rigor. El gráfico de PRs por día frente a tasa de rechazo en la página Por qué Ivy se basa en 1.946 pull requests en los repositorios de Ivy entre febrero y abril de 2026. Ivy señala que su equipo pasó de aproximadamente 10 a más de 100 pull requests al día tras adoptar el flujo estructurado de planificar, ejecutar, verificar y revisar al que denomina fábrica de software. La cifra de volumen se expone siempre junto a la tasa de rechazo porque, de forma aislada, no demostraría nada.

Coste por PR fusionada y tasa de aprobación de verificación

Una vez que se controlan las fusiones y la tasa de rechazo, el coste por pull request fusionada determina con exactitud cuánto cuesta el trabajo aceptado. Esta es la cifra financiera que exige un CTO, y debe expresarse en dólares o tokens por cambio fusionado —no por plan ni por ejecución individual—, de manera que los reintentos y el trabajo descartado queden integrados.

El coste por pull request fusionada es también la métrica que hace evidente la acumulación en cola: según la ley de Little, una acumulación creciente de pull requests abiertas a un ritmo constante de fusión significa que el tiempo de ciclo está aumentando, se mida o no formalmente. Tres factores mueven el coste por PR fusionada:

Reintentos (Retries). Cada verificación fallida implica una nueva ejecución. La tasa de aprobación de verificación es el indicador adelantado; cuando cae, el coste por PR fusionada se incrementa pocos días después. El artículo Puertas de verificación detalla qué comprobar y por qué la puerta del plan es la más crítica.
Tamaño del plan. Los planes extensos cuestan más por ejecución y son rechazados con mayor frecuencia, ya que el revisor encuentra más objeciones. Dividir un plan grande en otros más concisos suele reducir tanto la tasa de rechazo como el coste por PR fusionada, a cambio de gestionar un mayor número de pull requests.
Elección del modelo. Un modelo más económico que supere la verificación a la misma tasa supone un ahorro directo e inmediato. La única forma de comprobarlo es registrar el coste y la tasa de aprobación por plan, comparando distintos modelos sobre el mismo código base.

Para profundizar en la transición general entre medir la actividad del desarrollador y medir el trabajo aceptado, consulte In the loop, out of the loop: el cambio de KPIs tras la ingeniería basada en agentes.

Cómo registra estas métricas Ivy Tendril

Ivy Tendril es una aplicación de escritorio local-first (macOS, Windows, Linux) que gestiona los agentes de programación desde el plan inicial hasta la pull request revisada, registrando de forma nativa los datos de cada métrica expuesta durante la ejecución del flujo de trabajo. No requiere configuración ni instrumentación externa adicional.

Dashboard. El Dashboard muestra el estado de los planes a lo largo del ciclo de vida, los KPIs de coste, gráficos de tendencias temporales y la actividad de Git para los repositorios vinculados. El estado del plan desglosa las PRs abiertas, fusionadas y rechazadas; la actividad de Git aporta el historial verificado de fusiones.
Coste por plan y por tarea (job). Se registran los tokens y costes económicos de cada plan y de cada tarea interna. Si un plan requirió tres ejecuciones antes de superar la verificación, se muestran las tres, garantizando que el coste por PR fusionada incluya por construcción todos los reintentos. La sección Jobs expone la salida en streaming y las llamadas a herramientas (tool calls) de cada tarea junto con su gasto.
Comparación entre agentes y modelos. Tendril orquesta Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode y cualquier otro agente CLI, permitiendo seleccionar el agente o modelo por cada plan específico. De este modo, los costes y las tasas de éxito pueden compararse entre modelos sobre la misma base de código sin alterar el flujo de trabajo.
Datos locales. Los planes, registros y reportes de costes permanecen en su máquina local. Las únicas llamadas externas son hacia la API del modelo configurado y hacia GitHub.

Para aquellos equipos que aún no han implementado Tendril, Ivy ofrece una PR Cost Calculator gratuita y de código abierto. Lee la información pública de GitHub de cualquier repositorio y calcula la media móvil de 14 días de PRs fusionadas y tasa de rechazo, permitiendo registrar la línea base antes de introducir cambios. Pruébela en su repositorio hoy y evalúela de nuevo un mes después de incorporar agentes.

Cómo empezar

Obtenga la línea base. Ejecute la PR Cost Calculator en su repositorio principal y registre las métricas móviles de 14 días de PRs fusionadas y tasa de rechazo.
Instale Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) o irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Documentación en instalación.
Ejecute planes durante dos semanas y revise el Dashboard: fusionados, rechazados, coste por plan y tendencias.
Calcule manualmente el coste por PR fusionada al menos una vez (dividiendo el gasto total entre el número de PRs fusionadas), asegurando que el equipo comparta la misma definición antes de convertirla en un reporte formal.

Tendril es gratuito y con código disponible bajo la Functional Source License. Las capacidades de equipo, despliegue on-premise, SSO e importación de verificaciones de CI están disponibles en los planes Pro (59 $ por usuario al mes) y Enterprise.

Preguntas frecuentes

¿Cuál es una buena tasa de rechazo?

No existe un objetivo universal válido para todos los casos, y una tasa del cero por ciento suele indicar que no se está asumiendo ningún riesgo real en las tareas encomendadas. Supervise su evolución a lo largo del tiempo y entienda un repunte como una advertencia para auditar la calidad de los planes y la verificación, no como una señal para recortar ejecuciones de forma artificial.

¿Debe el coste por PR fusionada incluir el tiempo de revisión humana?

Inclúyalo si cuenta con un método fiable para medirlo con consistencia. La mayoría de los equipos comienza contabilizando los tokens o el gasto directo de los modelos al estar completamente automatizado, y añade el tiempo del revisor cuando la metodología interna se ha consolidado. Mezclar ambos valores antes de acordar el criterio dificulta la comparación mes a mes.

¿En qué se diferencian estas métricas de las métricas DORA?

Presentan puntos en común. El tiempo de ciclo desde la concepción del plan hasta el merge guarda estrecha relación con el Lead Time for Changes. Sin embargo, la tasa de rechazo no tiene un equivalente directo en DORA, puesto que este modelo presupone que el código fue escrito por un humano y se centra en evaluar si llegó a desplegarse. La tasa de rechazo indaga si el cambio fue si quiera aceptado, lo cual resulta mucho más esclarecedor cuando son agentes quienes generan las propuestas.

Primeros pasos con Ivy Tendril

¿Listo para la orquestación paralela de agentes a nivel de desarrollador?

Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.

Medir el rendimiento de los agentes: PRs fusionadas, tasa de rechazo y coste por PR