Preludio

El Centro de Control de EntendIA rastrea seis métricas de rendimiento que cuantifican cómo trabajas con Claude Code. No son números de vanidad. Cada métrica se deriva de datos de eventos deterministas capturados durante cada sesión de Claude Code, proporcionándote una imagen precisa de tus patrones de interacción, eficiencia y crecimiento a lo largo del tiempo.

Si alguna vez has mirado las tarjetas de métricas en el Centro de Control y te has preguntado qué miden exactamente, cómo se calculan o qué aspecto tiene una buena puntuación, esta guía cubre todo eso.

El Problema

Las sesiones de Claude Code generan enormes cantidades de datos. Cada lectura de archivo, cada edición, cada comando bash, cada prompt que envías, cada error que ocurre — todo se captura como eventos estructurados. Sin métricas, esos datos son solo ruido. No puedes saber si hoy fue más productivo que ayer, si tu tasa de errores está aumentando o si realmente estás usando las herramientas disponibles.

Las seis métricas del Centro de Control destilan esos datos brutos de eventos en números accionables. Responden a preguntas específicas: ¿Con qué rapidez estoy iterando? ¿Cuán limpia es mi ejecución? ¿Estoy paralelizando eficazmente? ¿Cuántos datos fluyen a través de mis sesiones? ¿Estoy usando el kit completo de herramientas? ¿Estoy delegando trabajo a subagentes?

El Camino

APM (Acciones Por Minuto) {#apm}

APM mide la tasa de interacciones significativas entre tú y Claude Code por minuto de tiempo de sesión. Cuenta cada ejecución de herramienta (lecturas de archivo, ediciones, búsquedas, comandos bash) y cada prompt que envías.

Fórmula:

APM = (usos_de_herramienta + prompts) / duración_sesión_minutos

Fuente de datos: plugin_session_summaries.tool_uses, plugin_session_summaries.prompts y duración de sesión calculada a partir de los timestamps started_at / ended_at.

Por qué importa. APM mide tu velocidad de iteración con IA. Un APM más alto indica bucles de retroalimentación más ajustados — estás dando instrucciones, revisando resultados y corrigiendo el rumbo rápidamente. En términos de StarCraft, estas son tus acciones por minuto brutas. Una sesión donde envías 5 prompts y Claude ejecuta 45 llamadas a herramientas durante 10 minutos te da un APM de 5,0. Los jugadores profesionales de StarCraft promedian más de 300 APM; los usuarios efectivos de Claude Code normalmente se sitúan entre 5-30 APM dependiendo de la complejidad de la tarea.

Cómo interpretar tu APM:

  • Por debajo de 5 — Puede indicar tareas autónomas de larga duración o tiempo inactivo dentro de las sesiones. No es necesariamente malo si Claude está ejecutando operaciones complejas de múltiples pasos.
  • De 5 a 20 — Rango típico para sesiones de desarrollo interactivas. Estás guiando activamente a Claude y revisando las salidas.
  • Por encima de 20 — Sesiones interactivas rápidas con bucles de retroalimentación ajustados. Común durante la depuración, refactorización o codificación exploratoria donde das correcciones frecuentes.

EAPM (Acciones Efectivas Por Minuto) {#eapm}

EAPM es APM con los errores eliminados. Cuenta solo las ejecuciones exitosas de herramientas y los prompts, excluyendo las llamadas a herramientas fallidas.

Fórmula:

EAPM = (usos_de_herramienta + prompts - errores) / duración_sesión_minutos

Fuente de datos: Los mismos campos que APM, más plugin_session_summaries.errors.

Por qué importa. EAPM separa la señal del ruido. Si tienes 50 de APM pero 20 de esas acciones son errores, tu EAPM de 30 revela tu verdadero ritmo productivo. En StarCraft, esta es la diferencia entre hacer clic frenéticamente y acciones significativas. Un APM alto con EAPM bajo sugiere que puede ser necesario ajustar tus prompts o configuraciones de herramientas para reducir errores.

Cómo interpretar la brecha entre APM y EAPM:

  • EAPM cercano a APM — Ejecución limpia. Tus sesiones se ejecutan con errores mínimos, lo que significa que los prompts son claros y las configuraciones de herramientas son correctas.
  • EAPM significativamente menor que APM — Tasa de errores alta que merece investigación. Las causas comunes incluyen herramientas mal configuradas, prompts ambiguos que llevan a Claude por caminos equivocados, o trabajar en entornos con dependencias inestables.

Concurrencia {#concurrency}

La concurrencia mide el número de sesiones de Claude Code ejecutándose simultáneamente. Se calcula contando las ventanas de tiempo de sesión superpuestas — sesiones donde los rangos de started_at a ended_at se solapan.

Fórmula:

Pico = número máximo de sesiones con rangos de tiempo superpuestos
Media = media ponderada por tiempo del recuento de sesiones concurrentes durante el día

Fuente de datos: plugin_session_summaries.started_at y plugin_session_summaries.ended_at, calculados usando un algoritmo de línea de barrido.

Por qué importa. La concurrencia muestra con qué eficacia paralelizas el trabajo con IA. Ejecutar múltiples sesiones de Claude Code en diferentes tareas simultáneamente es como gestionar múltiples bases en StarCraft — multiplica tu producción. Una concurrencia pico de 4 significa que tuviste 4 asistentes de IA trabajando en paralelo en algún momento durante el día.

Cómo interpretar tu concurrencia:

  • 1 — Trabajo serial. Una sesión a la vez. Está bien para tareas complejas y enfocadas, pero deja rendimiento sobre la mesa.
  • 2 a 3 — Paralelismo moderado. Estás ejecutando un par de sesiones simultáneamente, quizás una para una tarea principal y otra para una tarea secundaria o revisión de código.
  • 4 o superior — Territorio de usuario avanzado. Estás aprovechando múltiples sesiones eficazmente, delegando tareas independientes a instancias separadas de Claude Code y gestionándolas concurrentemente.

Throughput {#throughput}

Throughput mide el volumen total de datos intercambiados entre tú y Claude Code. Esto incluye todo el contenido enviado a la IA (prompts, contenidos de archivos, entradas de herramientas) y todo el contenido recibido (respuestas, salidas de herramientas, código generado).

Fórmula:

Total = bytes_entrada_contenido + bytes_salida_contenido
Tasa = bytes_totales / segundos_activos_sesión_total

Fuente de datos: plugin_session_summaries.content_input_bytes y plugin_session_summaries.content_output_bytes.

Por qué importa. El throughput refleja el volumen de trabajo que se está procesando. Un throughput alto significa que se están leyendo archivos grandes, se está generando código significativo o se están realizando análisis complejos. En términos de StarCraft, esta es tu tasa de recolección de recursos — cuánto material fluye a través de tu pipeline de IA. Una sesión que genera 2 MB de salida está haciendo sustancialmente más trabajo que una que genera 50 KB.

Cómo interpretar tu throughput:

  • Se muestra como bytes totales (KB/MB) y tasa (bytes por segundo).
  • Un throughput más alto generalmente se correlaciona con sesiones más productivas, pero el contexto importa. Una sesión de refactorización que toca muchos archivos naturalmente tendrá un throughput más alto que una sesión de depuración enfocada.
  • Las caídas repentinas de throughput pueden indicar sesiones que se estancan o alcanzan los límites de contexto.

Diversidad de Herramientas {#tool-diversity}

La diversidad de herramientas es el número de herramientas únicas usadas a lo largo de todas las sesiones en un día. Las herramientas incluyen Read (lectura de archivos), Edit (modificación de archivos), Bash (ejecución de comandos), Grep (búsqueda de código), Glob (búsqueda de archivos), Write (creación de archivos) y Agent (delegación a subagentes).

Fórmula:

Diversidad de Herramientas = COUNT(DISTINCT nombre_herramienta) WHERE tipo_evento = 'PostToolUse'

Fuente de datos: plugin_usage_events.tool_name filtrado a ejecuciones exitosas de herramientas.

Por qué importa. La diversidad de herramientas indica cuán versátil es tu uso de la IA. Usar solo Read y Bash es como construir un único tipo de unidad en StarCraft — funciona, pero no estás aprovechando el kit completo de herramientas. Los usuarios que emplean Read, Edit, Grep, Glob, Bash, Write y Agent tienen un patrón de interacción más rico y normalmente completan tareas más complejas. Una diversidad de 7 (todas las herramientas) sugiere flujos de trabajo sofisticados de múltiples pasos.

Cómo interpretar tu diversidad de herramientas:

  • 1 a 2 — Uso básico. Puede que estés usando Claude Code principalmente para leer archivos o ejecutar comandos. Considera si Edit, Grep o Glob podrían acelerar tu flujo de trabajo.
  • 3 a 4 — Diversidad moderada. Estás usando un subconjunto razonable de las herramientas disponibles.
  • 5 o superior — Uso avanzado. Estás aprovechando el kit completo de herramientas de Claude Code, incluyendo herramientas de búsqueda y delegación a subagentes.

Puntuación de Multitarea {#multitasking}

La puntuación de multitarea es una métrica compuesta (0-100) que mide cuán eficazmente delegas y paralelizas el trabajo. Tiene en cuenta la creación de subagentes (Claude creando agentes auxiliares) y la concurrencia de sesiones.

Fórmula:

Multitarea = min(100, (creaciones_subagentes × 2 + concurrencia_pico × 3) / recuento_sesiones × 10)

Fuente de datos: plugin_session_summaries.subagent_spawns, sesiones concurrentes pico y recuento total de sesiones.

Por qué importa. La puntuación de multitarea captura tu capacidad para aprovechar la IA a escala. Crear subagentes significa que estás dejando que Claude divida tareas complejas en subtareas paralelas — el equivalente en IA de dividir el ejército en StarCraft. Combinado con la concurrencia de sesiones, esto muestra si estás usando la IA como un único trabajador o como un equipo coordinado.

Cómo interpretar tu puntuación de multitarea:

  • 0 a 20 — Uso secuencial, de tarea única. Estás trabajando con una sesión de Claude a la vez sin delegación a subagentes. Esto está bien para tareas simples.
  • 20 a 50 — Delegación moderada. Estás ejecutando sesiones concurrentes o activando la creación de subagentes, pero no ambas cosas intensamente.
  • 50 o superior — Paralelismo y delegación intensos. Estás ejecutando múltiples sesiones concurrentes y usando subagentes dentro de esas sesiones. Este es el patrón de usuarios que tratan a Claude Code como un equipo en lugar de un único asistente.

Combinaciones de Métricas: Leyendo el Panorama Completo

Las métricas individuales te dicen algo útil. Las métricas leídas en conjunto te dicen lo que realmente está ocurriendo en tu flujo de trabajo.

Velocidad vs Precisión: APM + EAPM

La brecha entre APM y EAPM es tu tasa de errores. Si tu APM es 15 y tu EAPM es 12, tienes una tasa de errores del 20%. Rastrea esta proporción a lo largo del tiempo en lugar de los valores absolutos.

Patrón APM EAPM Proporción Diagnóstico
Ejecución limpia 12 11,5 96% Los prompts son claros, las herramientas están configuradas correctamente
Ruido moderado 18 13 72% Algunos errores, probablemente de trabajo exploratorio o bases de código desconocidas
Tasa de errores alta 25 10 40% Sobrecarga significativa de reintentos. Comprueba herramientas mal configuradas, prompts ambiguos o suites de tests inestables

Cuando la proporción cae por debajo del 70%, investiga tus fuentes de error. Las causas más comunes son: ejecutar comandos bash que fallan por dependencias faltantes, ediciones de archivos que entran en conflicto con cambios concurrentes y patrones grep que no coinciden con nada. Cada uno de estos desperdicia una llamada a herramienta y tiempo.

Eficiencia vs Escala: EAPM + Concurrencia

EAPM alto con concurrencia de 1 significa que eres rápido pero secuencial. EAPM bajo con concurrencia de 4 significa que estás paralelizando pero cada sesión es lenta. La combinación revela tu capacidad real de rendimiento.

Un usuario con EAPM de 10 y concurrencia de 3 está produciendo efectivamente a una tasa de 30 acciones efectivas por minuto en todo su espacio de trabajo. Compáralo con EAPM de 20 con concurrencia de 1 — técnicamente más rápido por sesión pero menor producción total.

Amplitud vs Profundidad: Diversidad de Herramientas + Throughput

Baja diversidad de herramientas con alto throughput sugiere que estás realizando operaciones masivas repetitivas (leyendo muchos archivos, ejecutando muchos comandos bash). Alta diversidad de herramientas con throughput moderado sugiere flujos de trabajo complejos de múltiples pasos que aprovechan el kit completo de herramientas.

Diversidad Throughput Patrón
2 (Read + Bash) Alto (5 MB+) Análisis masivo o revisión de logs
4 (Read + Edit + Bash + Grep) Moderado (500 KB-2 MB) Flujo de trabajo de desarrollo estándar
6+ (todas las herramientas) Moderado a Alto Refactorización compleja o trabajo multi-repositorio
7 (todas las herramientas incluyendo Agent) Cualquiera Orquestación avanzada con delegación a subagentes

Efectividad de la Delegación: Multitarea + Concurrencia

La puntuación de multitarea combina el uso de subagentes y la concurrencia de sesiones. Pero los dos componentes cuentan historias diferentes. Muchas creaciones de subagentes dentro de una sola sesión significa que Claude está descomponiendo tareas complejas internamente. Alta concurrencia sin subagentes significa que estás gestionando manualmente sesiones paralelas.

El patrón más efectivo es ambos: múltiples sesiones concurrentes donde Claude también crea subagentes dentro de esas sesiones. Esto representa la utilización completa de las capacidades de paralelismo de Claude Code.

Perfiles de Sesión: Qué Aspecto Tiene lo Bueno

Diferentes tipos de trabajo producen diferentes firmas de métricas. Comparar tus métricas con estos perfiles te ayuda a entender si tus números son típicos o indican algo que merece ajustarse.

El Depurador

Bucles de retroalimentación ajustados, muchas lecturas y búsquedas, pocas ediciones hasta que se encuentra la solución.

Métrica Rango Típico
APM 8-20
EAPM 6-18
Concurrencia 1
Throughput 200 KB-1 MB
Diversidad de Herramientas 4-5 (Read, Grep, Bash, Edit, Glob)
Multitarea 0-15

El Refactorizador

Alto throughput por tocar muchos archivos, APM moderado, alta diversidad de herramientas.

Métrica Rango Típico
APM 10-25
EAPM 9-23
Concurrencia 1-2
Throughput 1-10 MB
Diversidad de Herramientas 5-7
Multitarea 10-40

El Arquitecto

Múltiples sesiones concurrentes, delegación a subagentes, exploración de diferentes enfoques en paralelo.

Métrica Rango Típico
APM 5-15 por sesión
EAPM 4-14 por sesión
Concurrencia 3-6
Throughput 2-15 MB total
Diversidad de Herramientas 6-7
Multitarea 40-100

El Revisor

APM bajo, alta proporción de lectura frente a edición, enfocado en entender código más que en cambiarlo.

Métrica Rango Típico
APM 2-8
EAPM 2-7
Concurrencia 1
Throughput 500 KB-3 MB
Diversidad de Herramientas 3-4 (Read, Grep, Glob, Bash)
Multitarea 0-5

Mejorando Tus Métricas

Las métricas son descriptivas, no prescriptivas. Perseguir números más altos por sí mismos es contraproducente. Pero si notas patrones que sugieren ineficiencia, aquí tienes acciones específicas vinculadas a cada métrica.

Subir el EAPM (reducir errores)

  1. Escribe prompts más específicos. En lugar de "arregla los tests", di "arregla el test que falla en test_auth.rs actualizando el mock para que devuelva un estado 200". Los prompts específicos reducen la probabilidad de que Claude tome caminos equivocados.
  2. Verifica tu entorno previamente. Muchos errores provienen de dependencias faltantes, directorios de trabajo incorrectos o artefactos de compilación obsoletos. Ejecutar una compilación o test rápido antes de iniciar una sesión de Claude elimina estos problemas.
  3. Usa /compact para gestionar el contexto. Cuando las sesiones se alargan, el contexto de Claude se llena y las tasas de error aumentan. Compactar la conversación mantiene la IA enfocada en el contexto relevante.

Subir la Concurrencia

  1. Identifica tareas independientes. Si tienes una funcionalidad que construir y tests que escribir, pueden ejecutarse en sesiones separadas. Si tienes dos bugs no relacionados, cada uno obtiene su propia sesión.
  2. Usa worktrees. Los worktrees de Git permiten que múltiples sesiones de Claude Code operen en el mismo repositorio sin conflictos de archivos. Cada sesión obtiene su propia copia de trabajo.
  3. Empieza con dos sesiones. El salto de 1 a 2 sesiones concurrentes es la mayor ganancia de productividad. No intentes gestionar 5 sesiones el primer día.

Subir la Diversidad de Herramientas

  1. Usa Grep en lugar de Bash grep. La herramienta Grep integrada de Claude es más rápida y proporciona salida estructurada. Si ves que Claude ejecuta grep -r, tu diversidad de herramientas es artificialmente baja.
  2. Usa Glob para descubrir archivos. En lugar de find . -name "*.rs", deja que Claude use la herramienta Glob. Más rápido y cuenta para la diversidad.
  3. Delega con Agent. Si una tarea tiene subtareas independientes (investigar un componente, modificar otro), dile a Claude que use subagentes. Esto sube tanto la diversidad de herramientas como la puntuación de multitarea.

Subir el Throughput

El throughput es principalmente una función de la complejidad de la tarea. No necesitas inflarlo artificialmente. Pero si el throughput es consistentemente bajo, puede que estés infrautilizando a Claude:

  1. Deja que Claude lea más contexto. En lugar de pegar fragmentos, deja que Claude lea los archivos completos. Más contexto de entrada generalmente lleva a mejor salida.
  2. Pide implementaciones completas. En lugar de pedir a Claude que esboce un enfoque, pídele que escriba el código completo. Esto genera más salida y normalmente te ahorra tiempo.

Subir la Puntuación de Multitarea

La puntuación de multitarea recompensa tanto la delegación a subagentes como la concurrencia de sesiones. Si tu puntuación está consistentemente por debajo de 20, prueba estos enfoques:

  1. Usa el modo planificación para tareas complejas. Cuando Claude entra en modo planificación y luego ejecuta, naturalmente crea subagentes para investigación en paralelo. Una única sesión de planificación puede generar 3-6 creaciones de subagentes, lo que eleva directamente la puntuación de multitarea.
  2. Dile a Claude que delegue. Instruye explícitamente a Claude para que use la herramienta Agent para subtareas independientes. "Investiga el módulo de autenticación en un agente mientras refactorizas la capa de base de datos en otro" activa trabajo paralelo que tanto se completa más rápido como mejora tu puntuación.
  3. Ejecuta sesiones concurrentes en tareas independientes. Si estás trabajando en una rama de funcionalidad y también necesitas revisar el PR de un compañero, esas son sesiones separadas. El multiplicador de concurrencia en la fórmula de multitarea recompensa esto.
  4. Combina subagentes con concurrencia. Las puntuaciones de multitarea más altas provienen de usuarios que ejecutan 2-3 sesiones concurrentes donde cada sesión también delega a subagentes. Este es el patrón de "equipo de equipos".

Reducir el Desperdicio de Throughput

Un throughput alto no siempre es throughput productivo. Vigila estos patrones de desperdicio:

  1. Leer los mismos archivos repetidamente. Si Claude lee src/main.rs cinco veces en una sesión, esos bytes cuentan para el throughput pero no aportan valor tras la primera lectura. Usa /compact para mantener el contexto enfocado y reducir las relecturas.
  2. Salida verbose de Bash. Un cargo build que produce 200 líneas de resolución de dependencias infla el throughput sin añadir información útil. Considera redirigir la salida verbose: cargo build 2>&1 | tail -20.
  3. Escrituras de archivos grandes que se sobreescriben inmediatamente. Si Claude escribe un archivo de 500 líneas y luego lo reescribe tras tu corrección, ambas escrituras cuentan para el throughput. Proporciona requisitos claros desde el principio para reducir las reescrituras.

Errores Comunes

Las métricas pueden engañar si las lees sin contexto. Estos son los patrones que más comúnmente hacen que los desarrolladores saquen conclusiones equivocadas.

APM Alto por Bucles de Error

Una sesión donde Claude intenta un comando Bash, falla, reintenta con una ligera variación, falla de nuevo y repite puede producir un APM de 30 o superior. Esto parece productivo sobre el papel. En realidad, la sesión está atrapada en un bucle de reintentos. Comprueba siempre la proporción EAPM/APM junto al APM bruto. Si la proporción está por debajo del 60%, el APM alto es ruido, no señal.

Throughput Inflado por Recarga de Contexto

Cuando una sesión alcanza el límite de contexto y Claude compacta la conversación, las lecturas de archivos posteriores son "nuevas" desde la perspectiva de las métricas aunque los mismos archivos se leyeron antes. Una sesión larga que compacta dos veces puede mostrar 5 MB de throughput cuando los datos únicos realmente procesados fueron 2 MB. Esto no es un error en las métricas. Refleja con precisión los datos que fluyeron a través de la sesión. Pero no debería compararse directamente con una sesión corta que nunca compactó.

La Baja Concurrencia No Siempre Es Mala

Un desarrollador trabajando en una refactorización compleja y fuertemente acoplada a lo largo de 15 archivos no puede ejecutar sesiones concurrentes de forma segura. Los archivos entran en conflicto. Los cambios dependen unos de otros. Una concurrencia de 1 es correcta aquí. No fuerces el paralelismo en tareas que son inherentemente secuenciales. La métrica es diagnóstica, no prescriptiva.

Techo de Diversidad de Herramientas

Solo hay 7 herramientas principales (Read, Edit, Bash, Grep, Glob, Write, Agent). Una puntuación de diversidad de 7 es el máximo. Una vez que alcanzas 5-6 regularmente, la mejora adicional es marginal. Concéntrate en otras métricas en su lugar.

Inflar Métricas vs Mejora Genuina

Es posible inflar artificialmente cada métrica. Ejecutar comandos Bash vacíos para subir el APM. Crear subagentes innecesarios para subir la multitarea. Leer archivos grandes que no necesitas para inflar el throughput. Nada de esto te hace más productivo. Las métricas existen para revelar patrones en el trabajo genuino. Si cambias tu comportamiento para complacer a las métricas en lugar de mejorar tu flujo de trabajo, las métricas pierden su valor diagnóstico.

Métricas para Equipos

Las métricas individuales te hablan de los patrones de interacción de un desarrollador. Los agregados a nivel de equipo te hablan de la salud del flujo de trabajo, la distribución de cuellos de botella y la madurez de adopción. Si lideras un equipo que usa Claude Code, así es como debes leer los datos agregados.

Agregación por Equipo

El Centro de Control puede mostrar métricas de todos los miembros del equipo. Los agregados útiles son:

  • Mediana de la proporción EAPM/APM en todo el equipo. Esto muestra la calidad general de los prompts y la salud del entorno. Si un desarrollador tiene una proporción del 95% y otro del 40%, el segundo desarrollador probablemente tiene problemas de entorno (tests rotos, dependencias faltantes, herramientas mal configuradas) que vale la pena investigar juntos.
  • Distribución de concurrencia. ¿Cuántos miembros del equipo están ejecutando sesiones concurrentes? Si todos están en concurrencia 1, el equipo no está aprovechando los flujos de trabajo paralelos. Una sesión de equipo sobre worktrees y uso concurrente de Claude Code puede cambiar esto.
  • Dispersión de diversidad de herramientas. Si la mayoría del equipo usa 3-4 herramientas y una persona usa 7, esa persona ha encontrado flujos de trabajo que vale la pena compartir. Si todos están en 2 (Read + Bash), el equipo está infrautilizando las capacidades de Claude Code.

Usando Métricas en Retrospectivas

Las métricas pertenecen a las retrospectivas, no a las evaluaciones de rendimiento. El objetivo es sacar a la luz patrones de flujo de trabajo, no clasificar individuos. Preguntas productivas para retrospectivas:

  1. "La mediana del equipo de la proporción EAPM/APM bajó del 85% al 70% este sprint. ¿Qué cambió en nuestro entorno?" (Quizás una dependencia se rompió, o la suite de tests se volvió inestable.)
  2. "Dos miembros del equipo tienen concurrencia por encima de 3 mientras el resto está en 1. ¿Qué están haciendo diferente?" (Quizás descubrieron los worktrees, o dividen sus tickets en fragmentos paralelizables.)
  3. "Nuestro throughput total se duplicó este sprint pero nuestro EAPM se mantuvo estable. ¿Estamos procesando más datos o solo reintentando más?" (Comprueba la tasa de errores para distinguir.)

Nunca uses métricas para comparar la producción individual. Un desarrollador trabajando en un problema difícil y desconocido naturalmente tendrá un EAPM más bajo que uno haciendo cambios rutinarios. Las métricas reflejan la dificultad de la tarea tanto como la capacidad del desarrollador.

Identificando Cuellos de Botella del Equipo

Cuando el throughput del equipo se estanca a pesar de un número creciente de sesiones, busca estos cuellos de botella:

  • Dependencias de revisión serial. Si el trabajo de un desarrollador bloquea la revisión de otro, la concurrencia del equipo está artificialmente limitada. Las revisiones de PR automatizadas con Claude Code GitHub Actions pueden desbloquear esto.
  • Contención de recursos compartidos. Si múltiples sesiones necesitan modificar los mismos archivos o ejecutar tests en la misma base de datos, las sesiones concurrentes interfieren entre sí. Los worktrees y los entornos de test aislados solucionan esto.
  • Silos de conocimiento. Si solo un miembro del equipo tiene alta diversidad de herramientas (porque es el único que sabe cómo usar subagentes o herramientas MCP), el potencial agregado del equipo está limitado. Las sesiones en pareja y las configuraciones compartidas de CLAUDE.md distribuyen el conocimiento.

Perfiles de Métricas del Mundo Real

Los rangos abstractos son útiles pero los ejemplos concretos son mejores. Estos son capturas de métricas reales de sesiones en la plataforma EntendIA.

Una Sesión de Depuración

Tarea: Rastrear una condición de carrera en la gestión del ciclo de vida de sesiones. El error solo se reproducía bajo carga concurrente.

Métrica Valor Notas
APM 14,2 Iteración rápida: leer logs, hipotetizar, probar, repetir
EAPM 11,8 Proporción del 83%. Varios patrones grep fallidos antes de encontrar las entradas de log correctas
Concurrencia 1 Secuencial por necesidad. El error estaba en el manejo de concurrencia, así que ejecutar sesiones concurrentes habría confundido la investigación
Throughput 1,4 MB Moderado. Principalmente lecturas de archivos de log e inspección de código
Diversidad de Herramientas 5 Read, Grep, Bash, Edit, Glob. No se necesitaron subagentes
Multitarea 0 Sesión única, sin delegación
Duración 38 minutos

Lo que revelan las métricas: Sesión de depuración limpia. La proporción de EAPM del 83% muestra algo de esfuerzo desperdiciado (los patrones grep fallidos) pero está dentro del rango saludable. APM alto con diversidad de herramientas de 5 es característico del perfil Depurador. La corrección fue un cambio de 3 líneas para añadir un mutex guard.

Una Sesión de Refactorización Grande

Tarea: Extraer un módulo compartido de tres extensiones Rust a una biblioteca común. Se tocaron 23 archivos en 4 directorios.

Métrica Valor Notas
APM 18,7 Alto. Muchas lecturas de archivos, ediciones y comprobaciones de compilación
EAPM 17,1 Proporción del 91%. Ejecución muy limpia porque el patrón estaba bien entendido
Concurrencia 2 Sesión principal para refactorización, segunda sesión ejecutando tests continuamente
Throughput 8,3 MB Alto. 23 archivos leídos y modificados, múltiples compilaciones completas
Diversidad de Herramientas 7 Todas las herramientas usadas incluyendo Agent para exploración en paralelo
Multitarea 45 2 sesiones concurrentes + delegación a subagentes para encontrar todas las rutas de importación
Duración 1 hora 12 minutos

Lo que revelan las métricas: Perfil de Refactorizador de manual. La proporción de EAPM del 91% es excelente para una tarea de esta envergadura e indica una comprensión clara de la arquitectura objetivo antes de empezar. La concurrencia de 2 (refactorización + testing continuo) es el patrón óptimo para este tipo de trabajo: detectar roturas inmediatamente en lugar de descubrirlas al final. El throughput de 8,3 MB refleja la escala del cambio.

Antes y Después: Corrección del Entorno

Antes (suite de tests rota, una semana):

  • APM medio: 12,4
  • EAPM medio: 6,1 (proporción del 49%)
  • Errores medios por sesión: 8,3
  • Causa raíz: Test de integración inestable que fallaba el 40% de las veces. Claude reintentaba la suite de tests en cada fallo.

Después (suite de tests corregida, semana siguiente):

  • APM medio: 10,8 (ligeramente menor, menos frenético)
  • EAPM medio: 9,9 (proporción del 92%)
  • Errores medios por sesión: 1,1
  • La corrección: Aislar el test inestable en su propio objetivo de test para que no bloqueara la suite principal.

Lo que revelan las métricas: El APM en realidad disminuyó tras la corrección, lo que podría parecer un descenso de productividad. Pero el EAPM casi se duplicó. El desarrollador estaba dedicando menos tiempo total pero logrando más. Este es un caso donde la proporción EAPM/APM contaba la historia real mientras que el APM bruto era engañoso.

Cómo Se Recogen los Datos

Todas las métricas se derivan de eventos de hooks que Claude Code envía a EntendIA. Cada ejecución de herramienta, envío de prompt, error y evento del ciclo de vida de la sesión (inicio, parada) se captura como un evento determinista con timestamps precisos y recuentos de bytes. No hay estimación ni muestreo involucrado — cada métrica se calcula a partir de eventos realmente observados.

Cuando instalas los hooks de EntendIA en tu configuración de Claude Code, estos disparan peticiones HTTP a la plataforma en cada evento del ciclo de vida. Estos eventos se almacenan como registros brutos y luego se agregan en las métricas que ves en el Centro de Control.

Tipos de Eventos

Los siguientes tipos de eventos alimentan los cálculos de las métricas:

  • PostToolUse — Una herramienta se ejecutó con éxito (Read, Edit, Bash, Grep, Glob, Write, Agent). Este es el evento principal para los cálculos de APM, EAPM y diversidad de herramientas.
  • PostToolUseFailure — Una ejecución de herramienta falló. Se usa para calcular el recuento de errores que separa EAPM de APM.
  • UserPromptSubmit — Enviaste un prompt a Claude. Se cuenta tanto en APM como en EAPM.
  • SessionStart / SessionEnd / Stop — Eventos del ciclo de vida de la sesión. Se usan para calcular la duración de la sesión, la concurrencia y delimitar los límites de las sesiones.
  • SubagentStart / SubagentStop — Eventos del ciclo de vida de subagentes. Se usan en el cálculo de la puntuación de multitarea para rastrear cuántos subagentes se crearon.

Informes Diarios

Estas métricas se agregan en resúmenes diarios a las 23:00 UTC. El proceso de agregación calcula totales, medias y picos a lo largo de todas las sesiones del día. Un análisis generado por IA acompaña a cada resumen diario, proporcionando información sobre patrones, identificando carencias de habilidades y ofreciendo recomendaciones para mejorar tu flujo de trabajo.

Los datos históricos se preservan indefinidamente, permitiéndote rastrear tendencias a lo largo de semanas y meses. El Centro de Control muestra tanto las métricas en vivo del día actual como los resúmenes diarios históricos para comparación.

Rastreando el Progreso a lo Largo del Tiempo

El Centro de Control preserva los resúmenes diarios indefinidamente. Este historial es donde reside el valor real. Las métricas de un solo día son una instantánea. Una semana de resúmenes diarios muestra una tendencia.

Qué buscar semanalmente

Revisa tus métricas al final de cada semana. Céntrate en tres preguntas:

  1. ¿Está mejorando mi proporción EAPM/APM? Una proporción en aumento significa menos errores por sesión. Esta es la tendencia más directamente accionable porque responde a mejor calidad de prompts e higiene del entorno.
  2. ¿Mi concurrencia es estable o está creciendo? Si estás atascado en concurrencia 1 semana tras semana, no has adoptado flujos de trabajo paralelos. Incluso pasar a 2 sesiones concurrentes duplica tu capacidad efectiva.
  3. ¿Ha cambiado mi diversidad de herramientas? Si añadiste una nueva herramienta a tu flujo de trabajo (por ejemplo, empezar a usar Agent para delegación a subagentes), debería aparecer como un aumento en la diversidad de herramientas. Si no aparece, la herramienta no se está activando.

Estableciendo líneas base personales

Después de dos semanas de datos, calcula tus medias para cada métrica. Estas se convierten en tus líneas base personales. Las desviaciones respecto a la línea base son más significativas que los números absolutos.

Por ejemplo, si tu línea base de EAPM es 12 y ves un día con 5, algo cambió. Quizás trabajaste en una base de código desconocida, o tu suite de tests estaba rota, o pasaste el día en una tarea que requería más lectura que escritura. La métrica señala la desviación; tú proporcionas el contexto.

Comparando entre proyectos

Diferentes proyectos producen diferentes perfiles de métricas. Un proyecto desde cero típicamente muestra mayor throughput y mayor diversidad de herramientas (mucha creación de archivos y búsqueda). Un proyecto de mantenimiento muestra menor throughput pero potencialmente mayor EAPM (ediciones enfocadas y precisas). No compares métricas entre tipos de proyecto fundamentalmente diferentes.

Documentación Detallada de Métricas

Cada métrica tiene una página de referencia dedicada con ejemplos adicionales, casos límite y detalles técnicos:

La Conclusión

Las seis métricas del Centro de Control te dan una imagen completa y determinista de cómo interactúas con Claude Code. APM y EAPM miden tu velocidad y precisión. Concurrencia y puntuación de multitarea miden tu capacidad de paralelizar. Throughput mide el volumen de trabajo que fluye a través de tus sesiones. Diversidad de herramientas mide la amplitud de uso de tu kit de herramientas.

Ninguna de estas métricas tiene un valor universalmente "correcto". Una sesión de depuración enfocada naturalmente tendrá perfiles de métricas diferentes a una sesión de refactorización grande. El valor está en rastrear tus propios patrones a lo largo del tiempo, identificar sesiones donde las métricas se desvían de tu norma, y entender por qué.

Léelas en combinación, no de forma aislada. Un APM alto con EAPM bajo significa que los errores están consumiendo tu velocidad. Alta concurrencia con baja diversidad de herramientas significa que estás ejecutando sesiones paralelas pero cada una hace trabajo simple. Alto throughput con bajo EAPM significa que grandes volúmenes de datos están fluyendo pero gran parte del trabajo se está reintentando.

Usa las perspectivas generadas por IA diariamente como punto de partida, luego profundiza en las métricas que más importan para tu flujo de trabajo. Si ves consistentemente una brecha entre APM y EAPM, céntrate en reducir errores. Si tu concurrencia es siempre 1, considera si algunas tareas podrían ejecutarse en paralelo. Si tu diversidad de herramientas es baja, explora si Grep o Glob podrían reemplazar la navegación manual de archivos.

Los datos están ahí. Las métricas los hacen legibles.