Después de los story points: qué medir en AI-DLC

Un story point es una suposición sobre qué tan difícil es una tarea para un humano. Cuando un agente escribe el código, ya nadie es ese humano.

En AI-DLC, mide cuatro cosas en lugar de puntos y velocity: cuánto tarda pasar de un intent aprobado a código probado y listo para desplegar, con qué frecuencia las personas devuelven el trabajo del agente en los gates, cuánto tarda pasar de un problema a un intent aprobado, y qué llegó de verdad a los usuarios. Y nunca leas el throughput solo. Léelo junto al cycle time, siempre.

Esa es la respuesta. El resto de esta guía es por qué se rompen las métricas viejas, qué pares mantienen honestas a las nuevas y dónde AI-DLC 2 ya anota los datos por ti. Si recién llegas al método, empieza por qué es AI-DLC.

Aprendí la mayor parte de esto viendo a squads piloto adoptar AI-DLC dentro de una gran organización de ingeniería. Lo más útil que vi fue un par de gráficos que no coincidían. El throughput subió desde la primera semana. El cycle time empeoró. Un equipo que reportara solo el primer gráfico habría declarado victoria, y uno que reportara solo el segundo habría matado el piloto. Los dos se habrían equivocado.

Los story points miden lo equivocado ahora

El whitepaper de AI-DLC hace la pregunta en voz alta: ¿la estimación de esfuerzo, como los story points, seguiría siendo tan crítica si la IA borra la línea entre tareas simples, medianas y difíciles? ¿Y la velocity seguiría siendo relevante, o los equipos deberían empezar a reemplazarla por valor de negocio?

La respuesta honesta es no, y la razón es mecánica. Un story point es un proxy del esfuerzo humano: cuánto necesita una persona para entender, escribir y probar un cambio. La velocity suma esos proxies por sprint. Cuando un agente genera el código en minutos, las partes caras se mueven. Escribir se vuelve barato. Decidir, revisar e integrar no. Una tarea que el equipo habría llamado un 8 puede tomarle diez minutos al agente y dos días a quien revisa, y los puntos no pueden decirte cuál de las dos mitades estás pagando.

AI-DLC también elimina el contenedor donde vivían los puntos. Los sprints se vuelven bolts, porciones de entrega medidas en horas o días. Estimar un sprint de dos semanas en puntos tenía sentido. Estimar un bolt de tres horas en puntos es teatro.

Cuatro métricas para reemplazar puntos y velocity

El whitepaper solo propone valor de negocio. La guía de Augment Code llega al mismo punto desde el lado de la adopción: la productividad individual sube mientras la entrega casi no se mueve. Los equipos que seguí convergieron en un conjunto más completo, y cada métrica reemplaza un número viejo específico por una razón específica.

Qué reemplaza a qué

La construcción se vuelve rápida. Lo que queda por medir es la parte humana a cada lado.

Métrica vieja	Métrica de AI-DLC	Qué mide de verdad
Story points	Construction Lead Time	Tiempo transcurrido desde un intent aprobado hasta una Unit probada y lista para desplegar. La velocidad del agente y el tiempo de review de las personas, juntos.
Velocity	Valor de negocio entregado	Lo que llegó a los usuarios y movió la métrica que nombró el intent. Quemar puntos nunca hizo eso.
Cantidad de bugs	Tasa de retrabajo	Con qué frecuencia las personas responden Request Changes en un gate, por stage. Dónde el agente sigue equivocándose.
Tiempo en el sprint	Discovery Lead Time	Tiempo transcurrido desde que se identifica un problema hasta un intent aprobado. Todo lo que viene antes del agente.

La última fila es la que los equipos olvidan. Cuando la construcción se comprime de semanas a días, la parte más lenta de la entrega muchas veces es todo lo que viene antes: las reuniones, los documentos, las aprobaciones que convierten “los clientes se quejan de X” en un intent claro. En el rollout que seguí, el discovery tomaba mucho más tiempo que la construcción, y nadie lo medía porque el trabajo de producto y de diseño nunca se había rastreado como los tickets. Si solo mides la mitad del agente, optimizas la mitad que ya es rápida. Escribí sobre ese hueco antes del agente en el punto ciego de AI-DLC.

El throughput miente cuando lo lees solo

Este es el patrón que vi en todos los squads piloto. En la primera semana, el agente produce código al instante, así que los cambios mergeados por dev se disparan. Nadie rediseñó el code review para el volumen nuevo, entonces los cambios se acumulan esperando a una persona, y el tiempo entre el primer commit y el despliegue sube antes de bajar.

El throughput dice que el piloto es un éxito. El cycle time dice que está fallando. Ninguno es la verdad por sí solo. El estudio de Microsoft sobre su propio rollout de Claude Code y Copilot CLI encontró que quienes lo adoptaron mergearon cerca de un 24% más de pull requests, y los autores tuvieron el cuidado de decir que un pull request mergeado “no es lo mismo que el valor que entrega” (arXiv 2607.01418). Esa advertencia es todo el punto de esta sección.

Lee throughput y cycle time juntos

largo·cycle time·corto

Estancado

Sale poco y lo que sale tarda. El método todavía no funciona, o el repositorio no es legible para un agente.

Atasco de review

El agente produce mucho, las personas no alcanzan a absorberlo. La caída de la curva en J. Achica las Units y rediseña el review, no mates el piloto.

Cauteloso u ocioso

Rápido cuando sale, pero sale poco. O el equipo es cauteloso a propósito, o el agente casi no se usa.

Donde quieres estar

Sale más y sale más rápido. Normalmente se llega después de la caída, nunca el primer día.

bajothroughputalto

Un equipo que pasa de abajo a la izquierda a arriba a la derecha no está fallando. Está en la caída, camino a abajo a la derecha.

La solución para el atasco de review no es un revisor más rápido. Son piezas más chicas desde el origen. Pídele al agente que estime el tamaño de cada Unit antes de que empiece la Construction, parte todo lo que produciría un merge request enorme (por endpoint, las migraciones aparte) y acuerda con el equipo un tamaño que quien revisa pueda leer de verdad. La curva en J completa, y cuándo tratarla como un problema estructural en lugar de una curva de aprendizaje, está en por qué AI-DLC te hace más lento primero.

AI-DLC 2 ya registra la mayor parte de esto

La buena noticia de AI-DLC 2 es que no necesitas una herramienta nueva de analytics para empezar. Cada pieza de trabajo recibe una carpeta de registro con un log de auditoría append-only que conoce 108 tipos de evento, y el motor compila un grafo de runtime a partir de él después de cada transición de stage.

Preguntas que responde el registro

Nombres de evento de la guía de estado y auditoría de AI-DLC 2.10.0. El resumen de runtime es de solo lectura y se puede correr en cualquier momento.

La pregunta	Dónde lo anota AI-DLC 2
¿Dónde sigue equivocándose el agente?	GATE_APPROVED y GATE_REJECTED por stage, más el conteo de revisiones en el archivo de estado. Los rechazos sobre el total de decisiones son tu tasa de retrabajo por stage.
¿Cuánto tiempo dejan las personas el trabajo esperando?	De STAGE_AWAITING_APPROVAL a GATE_APPROVED. /aidlc --status muestra cuánto lleva esperando el gate abierto; el doctor marca los gates que esperan más de 24 horas.
¿Los chequeos determinísticos están atrapando algo?	SENSOR_FIRED, SENSOR_PASSED, SENSOR_FAILED, sumados en el resumen de runtime.
¿El equipo le está enseñando al agente?	Aprendizajes capturados en los gates, contados en el resumen de runtime, y las reglas que agregaron a la memoria del proyecto y del equipo.
¿El código mergeado coincide con lo que se revisó?	aidlc attest clasifica cada ruta modificada como verified, drifted, unattested o unverifiable frente a los recibos de review.

La forma más rápida de empezar es /aidlc-session-cost, que imprime la duración, el resultado de cada stage, los resultados de los sensores y los aprendizajes del workflow actual, o el comando que lee, que también devuelve JSON:

aidlc engine runtime summary --json

Una señal que yo agregaría encima: el tiempo entre que se abre un gate y la aprobación. Un documento de requisitos aprobado cuarenta segundos después de aparecer no se leyó. Es una medida tosca, pero un equipo en el que ese número sigue bajando a lo largo de la tarde es un equipo que se está cansando, y los gates cansados son por donde pasan las malas decisiones. Más sobre eso en los gates son una función de pérdida.

Métricas de harness: ¿el agente está mejorando?

Las cuatro métricas de arriba te dicen si la entrega mejoró. Un segundo conjunto te dice si tu setup alrededor del agente está mejorando: el contexto, las reglas, los chequeos. Ese setup es el harness, y es la parte que controlas.

Cuatro métricas de harness

1. 01

   Tasa de escalamiento

   La proporción de tareas que terminan necesitando que una persona intervenga más allá de los gates previstos. Debería bajar a medida que el harness madura. Si no baja, las reglas y el contexto no están aprendiendo.

   +
2. 02

   Tasa de espiral del agente

   La proporción de tareas en las que el agente entra en loop sin progresar: la misma corrección intentada tres veces, la misma pregunta hecha de nuevo. Léela en los logs de sesión. Una tasa de espiral en aumento suele indicar context rot o una spec vaga.

   +
3. 03

   Tasa de retención de código

   La proporción del código escrito por el agente que sigue presente N días después, directo del historial de git. No necesita instrumentación.

   +
4. 04

   Asignación de atención

   La proporción del tiempo de los ingenieros dedicada a decisiones (especificar, revisar, elegir) frente a operar. Es autorreportada, así que trátala como una conversación, no como un número.

La retención es la que parece más simple y la más fácil de malinterpretar. Un estudio grande sobre 201 proyectos open source encontró que el código escrito por agentes sobrevive más que el código humano, con un riesgo 16% menor de ser modificado (Will It Survive?). Eso puede significar que el código es bueno. También puede significar que nadie se siente dueño de él, así que nadie lo toca. Otro estudio encontró que los archivos generados por IA reciben mantenimiento con menos frecuencia, y cuando lo reciben, son humanos quienes hacen la gran mayoría del trabajo (arXiv 2605.06464). La conclusión del propio primer paper es la correcta: el cuello de botella puede no ser la calidad de la generación, sino las prácticas de la organización alrededor del código. Lee la retención junto con quién modifica el código y por qué. Retención alta más nadie tocando un módulo que debería estar cambiando no es calidad. Es código huérfano.

Tres formas de arruinar tus métricas

Toda métrica se vuelve un objetivo en el momento en que la pones en una evaluación de desempeño. Estas son las tres que vi pasar, o casi pasar.

Errores de medición en rollouts de AI-DLC

• ✗Anti-pattern:
  Convertir un puntaje de preparación en un KPI.Las herramientas que puntúan qué tan legible es un repositorio para un agente sirven como diagnóstico. Convierte el puntaje en objetivo y los equipos crean un CLAUDE.md vacío para subirlo.
• ✗Anti-pattern:
  Confiar en qué tan rápido se siente la gente.En el estudio controlado de METR, devs con experiencia fueron 19% más lentos con herramientas de IA mientras creían ser 20% más rápidos. La velocidad autorreportada no es una métrica.
• ✗Anti-pattern:
  Contar cambios mergeados como producción.El throughput sube en la primera semana pase lo que pase. Sin cycle time y retrabajo al lado, estás midiendo cuánto tecleó el agente.
• ✓Obligatorio:
  Medir los pares, por stage, desde el registro.Lead time con throughput, retrabajo por stage, tiempo de discovery antes del agente. Todo eso ya está en el log de auditoría.

El resultado de METR merece una línea más, porque es la evidencia más limpia de que la percepción falla aquí (METR). Los devs no eran descuidados. Eran personas con experiencia trabajando en sus propios repositorios, y su sensación de velocidad estaba equivocada en la dirección opuesta a la verdad. Si la percepción falla para ellos, falla para tu equipo. Mide.

Un dashboard para el primer trimestre

Qué poner en la pared

• ✓Obligatorio:
  Cycle time (mediana y percentil 75) junto al throughput, cada semana.Nunca uno sin el otro.
• ✓Obligatorio:
  Tasa de retrabajo por stage.Requisitos, diseño y planes de código por separado. El stage con la tasa más alta es donde tu contexto o tu intent está más débil.
• ✓Obligatorio:
  Discovery Lead Time.Del problema identificado al intent aprobado. Empieza a medirlo aunque te dé vergüenza.
• ✓Obligatorio:
  Tiempo de espera en el gate y tiempo hasta aprobar.Las esperas largas indican un cuello de botella de review. Las aprobaciones instantáneas indican cansancio.
• •Opcional:
  Retención de código a 30 y 90 días, con quién la modificó.Del historial de git. Léela junto con el ownership, no sola.
• ✓Obligatorio:
  Un punto de decisión a las cuatro semanas.Si el cycle time no empezó a bajar después de unas cuatro semanas, averigua si es la curva en J o un problema estructural antes de decidir nada.

Nada de esto necesita un equipo de datos. El log de auditoría, el historial de git y una hoja de cálculo te llevan por el primer trimestre. Lo que necesita es la disciplina de reportar el par que no coincide, sobre todo cuando una de las mitades se ve genial. Y cambia lo que premias, que es un problema aparte: cuando el trabajo pasa a ser especificar y revisar, la matriz de competencias tiene que acompañar. Eso está en del squad al pod.

Preguntas frecuentes

¿Los story points todavía tienen sentido con agentes de IA?+

Poco. Los puntos estiman esfuerzo humano, y cuando un agente escribe el código el esfuerzo se mueve de teclear a decidir y revisar. Una tarea puede tomarle minutos al agente y días a quien revisa.

El propio whitepaper de AI-DLC pregunta si la estimación y la velocity todavía importan, y sugiere valor de negocio en su lugar.

¿Qué reemplaza a la velocity en AI-DLC?+

El valor de negocio entregado, leído junto con el Construction Lead Time (del intent aprobado al código probado), la tasa de retrabajo en los gates y el Discovery Lead Time antes del agente. El throughput sigue siendo útil solo cuando se lee junto al cycle time.

¿Cómo mido el retrabajo en AI-DLC?+

Cuenta los Request Changes contra el total de decisiones en los gates, por stage. AI-DLC 2 registra ambos como GATE_REJECTED y GATE_APPROVED en el log de auditoría, más un conteo de revisiones por stage en el archivo de estado.

¿Las métricas DORA siguen sirviendo con agentes de IA?+

Sí, sobre todo el lead time for changes, que es lo más cercano a lo que afectan los agentes. Lo que cambia es que necesitas agregar lo que viene antes (tiempo de discovery) y los gates (retrabajo, tiempo de espera), porque ahí es adonde AI-DLC mueve el cuello de botella.

¿Por qué empeoró nuestro cycle time después de adoptar AI-DLC?+

Porque el agente produce más cambios de los que tu proceso de review estaba hecho para absorber. Es el patrón más predecible en los rollouts de AI-DLC. Achica las Units, rediseña el review y dale unas cuatro semanas antes de decidir.

¿Dónde guarda AI-DLC 2 los datos del workflow?+

En una carpeta de registro por pieza de trabajo en aidlc/spaces/<space>/intents/, con un archivo de estado, cada artefacto y un log de auditoría append-only. aidlc engine runtime summary --json lo agrega todo.

A dónde ir ahora

Mide la parte humana. La velocidad del agente se resuelve sola en la primera semana, y se ve hermosa en un gráfico. Lo que decide si AI-DLC funciona es cuánto tardan las personas en decidir, con qué frecuencia tienen que devolver trabajo, y si lo que llega a producción es lo que alguien quiso decir.