11. Consumo de la IA

La opción Consumo del selector de vista de la barra superior muestra cómo trabaja el equipo en el proyecto. Sirve para ver dónde se va el esfuerzo del equipo y para mejorarlo, no solo para medir.

Qué significa cada señal

Aparte y Revisiones de gate no se suman al resto de la pestaña. Cada revisión de gate muestra la fecha y la hora, el paso, el rol revisor (o «Revisor»), el agente y el modelo, los tokens y el resultado («2 ✓ · 1 ✗ · 0 ?», o «sin resultado» si falló, caducó o se canceló). Los archivos releídos cuentan también los que el agente lee con cat, sed o grep en un comando. Guardar resumen para la retrospectiva escribe un documento en docs/metrics/ con estos datos y las señales destacables, desde el último resumen o con todo el registro.

Revisores en segundo plano. Si un turno lanza un agente revisor en segundo plano (por ejemplo, un code review), su tiempo es el de reloj hasta que el revisor termina, no solo el que informa el agente, que no cuenta el trabajo del revisor. Al pasar el ratón sobre ese tiempo, una pista dice «Incluye {tiempo} de revisor en segundo plano.»; los turnos sin revisor no cambian. Las tareas de Bash en segundo plano (como un servidor) no cuentan. Si cierras la app antes de que el revisor termine, ese tiempo no se suma.

Es un indicador, no una factura. Solo cuenta lo hecho desde la app y solo lo tuyo: el registro es personal y no se comparte por git.

Un ejemplo de lectura

Ejemplo ilustrativo. Las cifras son inventadas para explicar cómo leer el panel; las tuyas serán otras.

Un sprint de Lyra con una ronda de corrección (la prueba encontró un problema y el sprint volvió a la entrevista). Arriba, el panel muestra Tokens 2,4 M (160 k de entrada nueva · 130 k de salida), Turnos 47, Retrabajo 21 % (10 turnos que volvieron a un paso ya pasado) y Contexto releído 78 %.

Por rol:

Por paso del flujo (los cuatro con más gasto):

Por chat:

Cómo se lee:

• Full Stack Developer, 54 % en 22 turnos: es donde más se gasta, lo normal en un sprint que construye; si sube de un sprint a otro, mira si el diseño llegó con huecos.
• Product Owner, 26 % en 14 turnos: entrevista, revisiones y pruebas; parte de esos turnos son la prueba repetida (ver por paso).
• UI/UX Designer, 11 % en 5 turnos: el diseño salió en pocos turnos y no hubo que rehacerlo.
• Documentador, 9 % en 6 turnos: trabajo corto; nada que mejorar aquí.
• Implementación, 46 % y 1 vuelta: la corrección se llevó una parte grande; mira en la aceptación qué la causó.
• Prueba del usuario, 1 vuelta: la prueba se repitió; es candidata a la retrospectiva.
• Especificación de diseño, sin vueltas: la corrección no tocó el diseño.
• Entrevista, 1 vuelta: la ronda nueva empezó por la entrevista del problema, como pide el flujo.
• Chat «Construir», contexto 88 %: por encima del 85 %, cada turno paga sobre todo el historial; la próxima corrección, en un chat nuevo.
• Chat «Diseñar», contexto 52 %: sin problema.
• Retrabajo 21 %: cerca del aviso del 25 %; lo explican las vueltas de Implementación y de Prueba del usuario.

Qué mirar en la retrospectiva

• ¿Qué rol gasta más, y por qué? — Por rol. Que gaste más quien construye es normal; que lo haga quien coordina, no tanto.
• ¿A qué pasos volvimos más veces? — Retrabajo y las vueltas de Por paso del flujo.
• ¿Algún chat pasó del 85 % de contexto releído? — Por chat. Si pasa a menudo, usa un chat por fase (capítulo 8).
• ¿Se releyeron los mismos archivos muchas veces? — Archivos releídos. Un documento de contexto o un resumen puede evitarlo.
• ¿Cuánto cuestan las revisiones de gate? — Revisiones de gate. Si cuestan más de lo que aportan, revisa los criterios del gate (capítulo 5).

Después pulsa Guardar resumen para la retrospectiva: deja en docs/metrics/ estos datos y las señales destacables, para tenerlos a mano al cerrar el sprint.

Por sprint, tabla del cierre y Comparar modelos

• Elegir un sprint. La barra Sprint, encima del panel, elige Todo el proyecto o un sprint. Con un sprint elegido, todas las fichas y tarjetas cuentan solo sus turnos, y aparece la línea «Sprint N · turnos · tokens». Aparte y Revisiones de gate no dependen del sprint y lo dicen. El sprint sale del nombre del chat («Sprint N - …»): los chats sin ese nombre solo cuentan en «Todo el proyecto».
• Tabla «Consumo del sprint» en el cierre. Al cerrar el sprint, la app añade al final del documento de cierre una sección con una fila por rol y paso, con su entregable, y un total con turnos, tokens, equivalente API y retrabajo. Si el sprint no tiene datos registrados, el cierre lleva una línea de nota en su lugar. La tabla se escribe al cerrar: los turnos posteriores (subida a git, fin del sprint) no entran, salvo que pulses Actualizar consumo del cierre con ese sprint elegido. Esa acción sustituye la sección; no la duplica.
• Línea de corte. Con un sprint elegido que ya tiene su tabla, la barra dice hasta qué momento incluye el cierre el consumo, y cuántos turnos se registraron después. El total de la tabla coincide con el del filtro en ese momento.
• Resumen para la retrospectiva. Con un sprint elegido, Guardar resumen para la retrospectiva escribe en docs/metrics/ el resumen de todo ese sprint, con el mismo total que el filtro.
• Comparar modelos. La tarjeta aparece después de «Por modelo» y «Por día». Elige el paso en Paso; el desplegable indica cuántos modelos lo ejecutaron. Con dos o más, muestra por cada modelo las ejecuciones, los turnos, los tokens, los tokens por ejecución, el equivalente API y el retrabajo, sin marcar ningún mejor. Si el paso solo tiene un modelo, lo indica y no compara. La vista no lanza ninguna ejecución ni crea chats o documentos: solo lee lo registrado. Los turnos sin modelo informado (por ejemplo, de Codex) no se comparan, y la tarjeta dice cuántos son.

Los sprints no son idénticos: usa la comparación para ver coste y esfuerzo, no para juzgar la calidad de cada modelo.

Esperas e intervenciones

Arriba de Consumo hay dos pestañas: Tokens (todo lo anterior, la que se abre siempre) y Esperas e intervenciones. La segunda muestra cuánto esperó el flujo a que respondieras y cuántas veces intervino tu criterio. La barra Sprint sirve a las dos y la elección se conserva al cambiar de pestaña; en esta pestaña no salen Actualizar consumo del cierre ni la línea de corte, que hablan de tokens.

• Fichas. Espera total (con el número de esperas), Espera media (por espera), Aprobaciones (gates y preguntas), Permisos (concedidos y denegados) y Correcciones (textos escritos antes de aprobar).
• Por paso y rol. Una fila por paso del flujo y rol, con las esperas, la espera media y total, las aprobaciones, los permisos (con «· N denegados» si los hubo) y las correcciones, y una fila Total. Van en el orden del flujo; los pasos sin espera ni intervención no salen.
• Gates que nunca devolvieron el trabajo. Los gates que aprobaste sin corregir nada y sin enviar el trabajo a un paso anterior, con cuántas veces se aprobaron. Si todos tuvieron alguna corrección o devolución, lo dice.

Qué cuenta:

Funciona igual con Claude Code y con Codex. Las preguntas que el agente escribe en el texto del chat, sin la ventana de preguntas, no abren una espera. La app registra también, sin mostrarlas aún, las decisiones que tomó el rol delegado (capítulo 9). El registro es personal: va en .team-ai-console/waits.jsonl, aparte del de tokens, y no viaja por git (la app lo añade al .gitignore de esa carpeta). Los sprints anteriores a la 0.4.13 no tienen esperas registradas.

Guardar resumen para la retrospectiva añade la sección Esperas e intervenciones, tras las señales: la misma tabla y la lista de gates sin devolución, del mismo periodo o sprint; sin datos, una línea que lo dice.

Mejora continua

Consumo es el primer paso de un ciclo que mejora el propio equipo, sprint a sprint:

1. Retrospectiva. Al cerrar un sprint, mira el panel con las preguntas de arriba, junto a lo que ya registró el cierre (rondas, pendientes y decisiones tomadas en tu nombre).
2. Resumen de Consumo. Guardar resumen para la retrospectiva deja en docs/metrics/ los datos y las señales destacables del sprint.
3. Propuestas en Mejoras. Un rol (o tú) propone un cambio al propio equipo, por ejemplo una regla nueva en la ficha de un rol; las propuestas se ven en la pestaña Mejoras del proyecto.
4. El equipo del catálogo. Con Aplicar al equipo del catálogo, la mejora llega a tu equipo propio de Equipos y roles y, con él, a los proyectos futuros.

El detalle de las propuestas y de cómo llegan al catálogo está en el capítulo 13 (Mejoras del equipo: de la retrospectiva al catálogo).