Cuando apareció DORA, fue una verdadera revelación.

Por fin existían cuatro métricas capaces de responder una pregunta sencilla: ¿tu equipo realmente entrega software o solo parece estar ocupado? Lead Time, Deployment Frequency, Change Failure Rate y Time to Restore. Simples. Claras. Revolucionarias para su época.

Después llegó SPACE, aportando una mirada más amplia. Nos recordó que la productividad no depende únicamente del volumen de código entregado, sino también de la satisfacción, la colaboración, la comunicación y la eficiencia.

También fue un gran avance. El problema es que ambos modelos fueron diseñados sobre una premisa tan evidente que nadie sintió la necesidad de explicitarla:

El ser humano es quien ejecuta el trabajo. Es la persona quien escribe el código. Es la persona quien hace el commit. Si mides a la persona, estás midiendo el trabajo.

Hoy esa premisa dejó de ser cierta. Y cualquier dashboard que siga operando bajo ella te está contando una historia equivocada.

‍

01 · Las tres eras del desarrollo de software

• Era I · La era artesanal: Un desarrollador, un editor, una terminal. Tú eras la CPU. Las métricas se limitaban a líneas de código o puntos de función. Eran poco útiles, pero al menos medían exactamente aquello que pretendían medir.
• Era II · La era DevOps: Llegaron los equipos, los pipelines y CI/CD. Nacen DORA y SPACE. La atención deja de centrarse en el código y pasa al flujo de entrega. Fue una mejora enorme respecto de todo lo anterior.
• Era III (Actual) · La era del ejecutor: Claude Code, Codex, Copilot, OpenCode, Pi. Ahora quien ejecuta es el agente. El desarrollador dirige. Todos los marcos de métricas anteriores se rompen en silencio.

La transición ocurrió casi sin que nos diéramos cuenta.

Un día medías la frecuencia de commits como un indicador de velocidad del equipo. Al siguiente, un desarrollador realiza 40 prompts durante una tarde y termina generando 200 commits. ¿Qué dice entonces tu dashboard de DORA? Que eres un equipo diez veces más productivo.

Lo que no te dice es que uno de esos 200 commits introdujo un error de concurrencia que tardará tres días en descubrirse.

02 · Por qué DORA deja de funcionar

• Deployment Frequency: Antes era un buen indicador de actividad del equipo. Hoy puede ser simplemente un indicador de la velocidad del agente. Un desarrollador inactivo con un agente muy activo puede parecer un colaborador de élite.
• Lead Time for Changes: Con agentes, el tiempo entre una idea y un cambio puede reducirse a minutos. Paradójicamente, justo cuando más necesitas distinguir diferencias, la métrica pierde resolución.
• Change Failure Rate: Sigue siendo útil. Pero ahora ya no mide el criterio humano. Mide el criterio del agente. Son fallas distintas, aunque el número sea el mismo.
• Time to Restore: Los agentes también restauran sistemas. Y lo hacen más rápido. Pero la pregunta importante ya no es cuánto tardaron. Es quién tomó las decisiones y si la solución fue realmente correcta o simplemente rápida.

El problema de fondo es simple: Las métricas DORA eran buenos indicadores indirectos del esfuerzo humano y de la coordinación del equipo. Los agentes rompieron esa relación. Los números siguen cambiando. Solo que ya no significan lo que creemos.

03 · SPACE tiene un problema aún mayor

SPACE fue diseñado explícitamente para medir a las personas. Satisfacción. Rendimiento. Actividad. Comunicación. Eficiencia.

Todas esas dimensiones asumen que el desarrollador es quien hace el trabajo. Pero ¿cómo luce la actividad de un desarrollador cuyo trabajo consiste en escribir un buen prompt, revisar resultados y redirigir a un agente?

Pocas pulsaciones de teclado. Pocos commits escritos directamente. Largos periodos esperando mientras el agente trabaja. Según SPACE, probablemente parecería el miembro menos productivo del equipo. Y, sin embargo, podría ser el más valioso.

‍

SPACE nació para humanizar la medición de la productividad. En la era del ejecutor termina penalizando precisamente a quienes mejor saben dirigir agentes.

04 · ¿Qué deberíamos medir ahora?

Si el ser humano dirige la intención y el agente ejecuta el trabajo, entonces la capa de medición debe capturar ambos elementos y comprender la relación entre ellos.

Las nuevas unidades fundamentales son cuatro:

• Prompt: La intención humana enviada a un ejecutor. Es la verdadera unidad del trabajo creativo.
• Commit: El resultado de la ejecución. No basta con contarlo. Debe atribuirse al repositorio, la rama y el agente que lo produjo.
• LLM Call: Tokens de entrada. Tokens de salida. Ratio de caché. Es el costo real de la ejecución según el modelo utilizado.
• Spec: La intención formalizada. La señal que aparece antes incluso de que comience el desarrollo.

Estas cuatro piezas forman un grafo. Y ese grafo permite responder preguntas que DORA jamás pudo responder.

Spec written → Prompts issued → Tokens consumed → Commits landed

Ya no estamos frente a un pipeline. Estamos frente a una trazabilidad completa entre la intención y la ejecución.

Ahora podemos preguntarnos:

• ¿Cuántos prompts fueron necesarios para llevar una especificación a producción?
• ¿Qué tan eficiente es un desarrollador en consumo de tokens respecto de la semana pasada?
• ¿Qué agente genera commits que sobreviven más tiempo sin rollback?
• ¿Qué repositorio tiene la peor relación entre prompts y commits? ¿Por qué?

Ninguna de esas preguntas existe en DORA. Tampoco en SPACE. Son preguntas completamente nuevas. Y son las que realmente importan en la era del ejecutor.

05 · El regreso de las streaks

Las GitHub Streaks se volvieron un fenómeno porque reflejaban algo real: el hábito de crear todos los días. Después se transformaron en un chiste.

Muchos hacían un commit con un simple typo a las 11:58 de la noche solo para mantener viva la racha.

En la era del ejecutor, una streak debería medir otra cosa. No si hubo un commit. Sino si hubo intención. ¿Escribiste un prompt hoy? ¿Definiste una especificación? ¿Aportaste contexto que terminó generando valor?

Ese es el verdadero indicador. El commit es solo la consecuencia.

06 · Local-first, por defecto

Los modelos tradicionales también asumían otra cosa: Que los datos importantes vivían en un lugar central. Un dashboard. Jira. Una organización de GitHub. Hoy eso tampoco es cierto.

El trabajo más importante ocurre en sesiones locales de terminal. Entre distintos agentes. Distintos repositorios. Distintas ramas.

En esa media hora que queda entre la última reunión del día y la hora de cenar. Por eso, la próxima generación de métricas debe ser local-first. Capturada directamente durante la ejecución. No otro SaaS que haya que configurar. No una GitHub Action que solo se activa cuando haces push. Sino una herramienta que observe el trabajo donde realmente ocurre y construya el historial desde su origen.

Las métricas del futuro del desarrollo se construirán a nivel del PTY, no de las APIs.

07 ·  Lo que viene

DORA tuvo un enorme impacto. SPACE nos ayudó a comprender mejor qué significa la productividad humana. Pero ninguno de los dos sobrevivió a la llegada de la era del ejecutor.

Necesitamos una nueva capa de métricas. Una que entienda al ser humano como director de la intención. Al agente como ejecutor. Y que mida aquello que realmente importa:

La calidad de los prompts. La eficiencia en el uso de tokens. La relación entre especificaciones y commits. Ese es el marco que vale la pena construir. Ese es el sistema de métricas en el que vale la pena confiar.

Ya se está construyendo. Se llama Covenant.
‍

‍

Covenant es una plataforma de telemetría terminal-first para la era del ejecutor.

Funciona con una base de datos local SQLite, sin depender de la nube. Captura prompts, commits, llamadas a LLM y especificaciones, atribuyéndolos al repositorio, la rama y el contexto de trabajo para ofrecer una visión completa de cómo se desarrolla realmente el software asistido por agentes de IA.

‍