2k+ delegaciones al mes: cómo mido mi flujo de trabajo con agentes IA

Más de dos mil delegaciones mensuales. Ese es el ritmo al que opera mi sistema de agentes hoy. No fue planeado. No hubo un momento donde dije "voy a llegar a esa escala". Fue orgánico — el sistema de agentes se convirtió en mi forma natural de trabajar, y cuando finalmente medí, los números me sorprendieron. Este mes van más de dos mil, y la tendencia sube.

La pregunta interesante no es el número en sí. Es lo que cambia cuando tu flujo de trabajo opera a esa escala. Porque hay una diferencia cualitativa entre delegar 5 tareas al día y delegar 70+. No es lo mismo multiplicado por catorce — es otra cosa.

Qué es una delegación y por qué importa el volumen

Una delegación, en mi caso, es cuando el agente orquestador — el que coordina todo — le asigna una tarea concreta a un agente especializado. Uno escribe código, otro diseña arquitectura, otro ejecuta tests, otro documenta. Cada agente tiene su especialidad y opera dentro de su propio contexto.

No todas las delegaciones son iguales. Algunas duran 54 segundos — una revisión rápida de código, una validación menor. Otras toman 13 minutos — un refactor complejo, una suite de tests que necesita ejecutarse completa. El punto es que el flujo es continuo. No hay pausas donde yo me siento a programar algo durante dos horas. La mentalidad cambia: dejo de pensar "voy a programar esto" y empiezo a pensar "voy a orquestar esto". Mi trabajo es definir qué hacer y en qué orden, no cómo hacerlo línea por línea.

Es un cambio sutil pero profundo. Cuando tu rol principal es decidir qué tarea va primero, cuál depende de cuál, y qué agente está mejor preparado para cada cosa, tu cerebro opera en otro nivel. Menos ejecución mecánica, más pensamiento estratégico.

Los patrones que emergen cuando mides

Acá es donde se pone interesante. Porque sin datos, yo tenía una idea vaga de cómo usaba los agentes. Después de medir, descubrí cosas que no esperaba.

El agente que escribe código domina: aproximadamente 58% de todas las delegaciones. Tiene sentido — escribir código sigue siendo el grueso del trabajo. Pero lo reveladores el resto. Documentación ocupa cerca del 12%. Arquitectura un 11%. Testing un 5%. Auditoría de documentación otro 5%. Revisión de código un 4%. Revisión de calidad otro 4%.

Lees esos números y la conclusión salta sola: por cada 6 delegaciones de código, hay 1 de documentación, 1 de arquitectura, y 1 de testing o revisión. Ese ratio no es accidental. Es la calidad que emerge cuando tienes agentes especializados para cada aspecto del trabajo — no solo para escribir código, sino para asegurar que el código tiene sentido, está documentado, y funciona como se espera.

Hay otro dato que me resultó fascinante: el consumo de contexto varía mucho por tipo de agente. El que escribe código usa en promedio un 35% de su ventana de contexto. El de arquitectura sube a 50%. El de testing llega a 45%. Piensa en esto: diseñar la estructura de algo y validar que funcione correctamente requiere más "espacio mental" que ejecutar la implementación. El dato confirma algo que intuitivamente sabía pero nunca había podido cuantificar.

Las duraciones también cuentan una historia. El agente de código promedia 5 minutos por tarea. El de arquitectura 6 minutos. Pero el de testing — ese es el más lento: 12minutos. Porque ejecuta tests reales, valida cobertura, y genera reportes. No es un chequeo superficial; es validación completa.

El hook que captura todo

En el post anterior hablé de hooks como "la pata silenciosa" de Claude Code. Este dashboard es un ejemplo concreto de lo que puedes construir con ellos.

El concepto es simple: cada vez que el orquestador delega a un agente, un hook registra el momento exacto. Cuando el agente termina, otro hook calcula cuánto duró, extrae cuánto contexto consumió, y lo guarda en un archivo de log estructurado — JSONL, un formato donde cada línea es un registro independiente en JSON.

Los campos que captura: qué agente fue, qué modelo usó, en qué proyecto trabajó, si la tarea fue exitosa, cuánto duró, y cuánto contexto consumió como porcentaje de la ventana total. El hook además lee la bitácora del agente para extraer el pico real de uso de contexto — no lo que se estimó al inicio, sino lo que realmente pasó durante la ejecución.

Todo esto es determinista. No dependo de que el modelo recuerde logear. No dependo de que yo recuerde activar nada. El hook es código bash que se ejecuta siempre, en cada delegación, sin falla, sin olvido. Es exactamente el principio que describí antes: las reglas que importan se implementan como código, no como instrucciones que el modelo puede o no seguir.

De datos crudos a patrones visibles

Con los JSONL acumulándose día tras día, necesitas una forma de verlos. Ahí entra el dashboard: un TUI — interfaz de terminal — hecho en Python con curses.

Lo que muestra en una sola pantalla: el total de delegaciones del mes, de la semana, del día, y la tasa de éxito. Abajo, la actividad del día: qué agentes trabajaron, cuántas veces, uso promedio de contexto. Después, un ranking de agentes por cantidad de delegaciones, con porcentaje del total, duración promedio, y contexto promedio. Las últimas 15 delegaciones con timestamp, proyecto, agente, duración y modelo. Y al fondo, los proyectos que más delegaciones consumen y de qué tipo.

Puedes navegar entre meses, alternar entre ver todos los agentes o solo los de desarrollo, y tiene auto-refresh cada 30 segundos. También corre en modo estático para cuando necesitas piping o integración con otros scripts.

Un detalle importante: el dashboard solo trackea un subset de agentes — los de desarrollo. Developer, architect, tester, code-reviewer, document-writer, document-auditor, qa-reviewer. Son los que participan en el ciclo de construcción de software. Pero hay otros que no se cuentan: agentes de exploración, de planificación, utilitarios varios. Las 2000+ delegaciones mensuales son solo la parte que me interesa medir, no el total real. El número verdadero es mayor.

No es nada visualmente sofisticado — es una terminal con texto y bordes. Pero la información que concentra en una pantalla te cambia la perspectiva de cómo estás trabajando.

Lo que los datos revelaron sobre cómo trabajo

Antes del dashboard, operaba con intuición. Sabía que usaba mucho al agente de código, que documentaba "bastante", que los tests "andaban bien". Después del dashboard, la intuición se convirtió en datos. Y algunos contradijeron lo que creía.

El agente de código domina en volumen, pero no es el que más contexto consume por tarea. Arquitectura y testing usan más contexto por delegación, lo cual tiene sentido pero no era algo que hubiera articulado antes. Pensar la estructura y validar la calidad requiere más espacio que ejecutar.

Los proyectos cuentan historias diferentes. Uno tiene 393 delegaciones de código, otro tiene 45. No porque uno sea más importante — están en fases distintas. El primero está en desarrollo activo, el segundo en mantenimiento. Sin el dashboard, ambos "se sienten" activos cuando trabajas en ellos. Con el dashboard, la diferencia es obvia.

El ratio documentación-código se mantiene consistente: aproximadamente 1 de cada 5 delegaciones es documentación o auditoría. Eso no pasó solo. Es el resultado de tener calidad como principio integrado en el flujo, no como algo que haces "cuando hay tiempo".

Y la tasa de éxito: 100% este mes. No siempre fue así. Al principio, antes de tener hooks que validan y corrigen en tiempo real, había más fallos. Los hooks de enforcement que mencioné en el post anterior — los que atrapan al modelo cuando se equivoca y le explican cómo corregirse — son la razón directa de que la tasa subió. No es magia.Es código determinista que no se olvida de las reglas.

Observabilidad de tu propio flujo de trabajo

Todo el mundo habla de observabilidad para sistemas de producción. Logs, métricas, dashboards, alertas. Herramientas como Datadog, Grafana, Prometheus. Es práctica estándar para cualquier servicio que corre en servidores.

Pero casi nadie aplica eso a su propio flujo de trabajo con IA.

Y eso me parece un punto ciego enorme. Porque cuando mides cómo usas los agentes, puedes optimizar. Descubrí que ciertas tareas que le delegaba al agente de código eran mejor para el de arquitectura — necesitaban más pensamiento de diseño que ejecución. Descubrí que ciertos proyectos estaban acumulando deuda técnica porque no les pasaba el agente de testing con suficiente frecuencia. Descubrí que mi uso de contexto subía innecesariamente en ciertos flujos porque los agentes arrastraban información que yano era relevante.

Sin el dashboard, esas cosas son invisibles. Vives con la sensación de que "todo funciona bien" porque no tienes contra qué comparar. Con el dashboard, los patrones son obvios. Y una vez que los ves, no puedes dejar de actuar sobre ellos.

Es lo mismo que pasa cuando empiezas a medir cualquier cosa en tu vida — gastos, ejercicio, sueño. El acto de medir cambia tu comportamiento, porque hace visibles patrones que antes eran solo ruido de fondo.

La escala cambia la naturaleza del trabajo

Más de 2000 delegaciones al mes. Un solo técnico. Más de 10 proyectos activos. No es un número para impresionar a nadie — es simplemente lo que pasa cuando el sistema deagentes se convierte en tu forma primaria de trabajar.

La clave no fue buscar la configuración perfecta desde el día uno. Fue armar la infraestructura de medición primero, y después dejar que los datos guíen las mejoras. El dashboard no fue lo primero que construí — fue algo que surgió de la necesidad de entender qué estaba pasando después de semanas de uso intensivo.

Si estás empezando con agentes de IA, mi consejo es simple: mide desde el principio. Aunque sea un log básico. Un archivo de texto donde registras qué le pediste, cuántotardó, si funcionó. Porque cuando llegues a las 100, 500, 1000 delegaciones, vas a querer entender qué está pasando. Y sin datos, es solo intuición. La intuición sirve para arrancar. Los datos sirven para escalar.

Al final, la observabilidad de tu propio flujo de trabajo no es muy diferente de la observabilidad de un sistema de producción. En ambos casos, lo que no mides no lo puedes mejorar. Y lo que no mejoras, eventualmente te frena.

Si te sirvió, vuelve cuando publique algo nuevo. Sin calendario fijo, sin pretensiones. Solo lo que voy aprendiendo mientras construyo.