La muerte del LOC

Mira, el Manifiesto Ágil tiene una frase bonita: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Pero nadie la siguió. Terminamos midiendo la “velocidad” del equipo con lo que teníamos a mano: puntos de estimación al final del sprint, PRs acumulados, features entregados por semana. Y he escuchado a más de un líder técnico jurar que mide ”commits por día” y quejarse de que su equipo es “lento”. Lento. Con un CI que tarda quince minutos y revisiones que se dejan para el viernes por la tarde.

La intención es noble, no me malinterpretes. Queremos ritmo, queremos previsibilidad, queremos una señal de que las cosas avanzan. El problema es que ninguna de estas medidas te dice lo que creemos que nos dice. Lo que terminamos midiendo rara vez tiene que ver con valor entregado y casi siempre tiene que ver con actividad observable. Y actividad observable, en 2026, con modelos de lenguaje capaces de generar 800 líneas en treinta segundos, está a punto de convertirse en una métrica completamente vacía.

#.El espejismo de la productividad

La ingeniería de software tiene una relación enfermiza con las vanity metrics. Las llamamos así porque se sienten bien, se ven bien en una diapositiva, pero no te dicen nada sobre la salud real del sistema. LOC fue la primera. Después los commits por día, los story points, el velocity… cada década inventa la suya y, al rato, la deja gamificada y vacía.

Lo interesante es que llegó la IA y, en vez de abandonar la costumbre, le pusimos ropa nueva. Ahora medimos “Copilot acceptance rate”, “AI-generated LOC”, “prompts per developer”, “time saved by AI” estimado por la propia herramienta que estamos evaluando — hasta tokens consumidos. Es la misma mecánica: un número que sube es un número que tranquiliza.

Hay una ley que deberíamos enmarcar en la pared de cada oficina: la ley de Goodhart. En su formulación original, del economista Charles Goodhart en 1975, dice algo como “cualquier regularidad estadística observada tiende a colapsar una vez que se ejerce presión sobre ella con fines de control” ^fn-1. La versión popular, más mordaz, se la debemos a la antropóloga Marilyn Strathern en 1997: “When a measure becomes a target, it ceases to be a good measure” ^fn-2. Cuando la medida se convierte en el objetivo, deja de ser una buena medida. Punto.

Fred Brooks, mucho antes, ya había puesto el dedo en la misma llaga al hablar del man-month en The Mythical Man-Month: “The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth” ^fn-3. Un mito peligroso y engañoso. No escribió eso pensando en LOC, pero el espíritu es el mismo: reducir el trabajo de ingeniería a una unidad mecánica de conteo es confundir el mapa con el territorio.

#.Lo que DORA ya nos había dicho

Si hay un libro que debería haber matado el debate sobre qué medir, es Accelerate, de Nicole Forsgren, Jez Humble y Gene Kim, publicado en 2018 ^fn-4. Años de investigación sobre miles de equipos, analizados con rigor estadístico, condensados en un puñado de métricas que sí correlacionan con desempeño organizacional.

Las famosas DORA. Originalmente eran cuatro: change lead time, deployment frequency, change failure rate y time to restore service. Ese cuarteto se volvió canónico. Lo que mucha gente no ha notado es que las DORA evolucionaron. La guía actual que publica dora.dev ^fn-5 refina los nombres del cuarteto clásico y suma una métrica adicional centrada en el rework de despliegues: la proporción de despliegues que terminan requiriendo corrección o repetición. El cuerpo de conocimiento sigue vivo, y eso es sano.

Lo que no cambió es la idea central: estas métricas no miden cuánto escribes, miden cuán bien entrega el sistema completo. Y hay una propiedad de DORA que me parece especialmente valiosa hoy: son resistentes a la inflación por throughput. Puedes duplicar los commits por día sin mover una sola de estas métricas en la dirección correcta. De hecho, lo más probable es que las empeores.

En mi post anterior, Piano piano si va lontano, hablaba de la velocidad sostenible: ese ritmo constante, indefinidamente, del que hablaba el octavo principio del Manifiesto Ágil. DORA es, en cierto sentido, el instrumental que te dice si estás yendo a ese ritmo o si estás acelerando a fondo para frenar en seco tres meses después.

#.Por qué la IA hace que DORA importe diez veces más

Aquí viene la parte incómoda. La IA sube el throughput. Mucho. La generación de código, que solía ser el cuello de botella, ya casi no lo es. Pero los otros pasos del flujo —integración, revisión, despliegue, recuperación— no escalan al mismo ritmo. No escalan, de hecho, casi nada. Revisar un PR bien hecho toma el mismo tiempo que hace cinco años. De hecho, quizás demore aún más, porque hay que tener más cuidado con lo que la IA escribió: en algunos casos lo que parece una solución razonable es en realidad un desvío, una ruta alternativa que funciona para el caso feliz y falla silenciosamente en todos los demás. Entender un incidente en producción a las 3 AM toma el mismo tiempo que hace quince.

El patrón es el que uno esperaría: la velocidad aparente sube, las métricas de actividad mejoran, y todo se ve bien en la reunión trimestral. Lo que pasa en paralelo, de forma silenciosa, es que las métricas que sí importan — estabilidad, tasa de fallos, tiempo de recuperación — empiezan a moverse en la dirección incorrecta. No de manera catastrófica, sino poco a poco. Y cuando algo se rompe, la arqueología del PR que lo introdujo suele revelar lo mismo: un revisor, pocos minutos, cero comentarios.

El patrón preocupante se podría resumir como “el PR de 800 líneas aprobado en tres minutos”. La mecánica es sencilla: alguien usa un asistente de IA, obtiene un diff que toca muchos archivos, los tests están en verde (el asistente también los escribió, contra el mismo modelo mental), CI pasa, el revisor pasa los ojos por encima, aprueba. El lazo se cierra: la implementación y los tests codifican las mismas manchas ciegas. Las rutas de error que el modelo no consideró no están ni implementadas ni probadas. La regresión aparece como un “error en producción” una semana después.

El change failure rate es la métrica que mejor captura esto. La fórmula es simple: CFR = (despliegues que causaron incidente / rollback / hotfix) dividido entre (total de despliegues), en una ventana móvil de 30 o 90 días. Las bandas direccionales de DORA: Elite por debajo del 5%, High alrededor del 10%, Medium entre 10% y 15%, Low por encima del 15%. Esta métrica es hermosa porque no mejora si envías más: solo mejora si envías mejor.

El reporte DORA 2025, con miles de respondientes, tiene una frase que le voy a robar hasta que se me gaste ^fn-6:

AI doesn’t fix a team; it amplifies what’s already there.

La IA no arregla un equipo; amplifica lo que ya existe. Si el equipo tenía disciplina de revisión, buenas pruebas, una arquitectura razonable, la IA le va a dar superpoderes. Si tenía atajos crónicos, revisiones performativas y pruebas de humo disfrazadas de suite, la IA le va a dar superpoderes también, pero en la dirección opuesta.

Y aquí conviene ser honesto con la evidencia. El estudio ese de GitHub Copilot del que todo el mundo habla, el del “55.8% faster” ^fn-7 — sí, el publicado por GitHub — midió una sola tarea, un servidor HTTP en JavaScript, con 95 participantes y un intervalo de confianza del 95% entre 21% y 89%. Es una tarea, no un trabajo. Como contrapeso, el estudio de METR de 2025 ^fn-8 hizo un RCT sobre 16 mantenedores experimentados de código abierto, 246 tareas reales sobre repositorios grandes que los participantes ya conocían. El resultado fue incómodo: 19% más lentos con las herramientas de IA, mientras percibían ser 20% más rápidos. La diferencia entre la productividad medida y la productividad percibida es parte del problema que intentamos resolver.

No te digo que el código generado por IA sea objetivamente peor. La evidencia es mixta y sigue emergiendo. Lo que sí te digo es que, en un mundo donde el throughput es trivialmente amplificable, las métricas que importan son las que miden todo lo demás.

#.La capa que falta: métricas de entendimiento

DORA es imprescindible, pero no basta. DORA mide la entrega del sistema; no mide si el equipo entiende lo que entrega. Y ese, creo, es el nuevo frente.

En 2021, Forsgren volvió a la carga con Storey, Maddila, Zimmermann, Houck y Butler, y publicaron “The SPACE of Developer Productivity” en ACM Queue ^fn-9. La tesis central del paper es que la productividad no se captura con una sola dimensión, y menos con una métrica de actividad. Proponen cinco: Satisfaction y bienestar, Performance, Activity, Communication y colaboración, y Efficiency y flow. La idea no es medir las cinco exhaustivamente, sino elegir al menos una por dimensión y resistir la tentación de reducirlo todo a activity, que es la dimensión que se parece más al viejo LOC.

Más recientemente, en diciembre de 2024, Abi Noda publicó DX Core 4 ^fn-10, un marco que intenta unificar DORA, SPACE y DevEx en cuatro dimensiones prácticas: Speed, Effectiveness, Quality e Impact. SPACE y DORA no se reemplazan: se complementan. DX Core 4 es un intento honesto de dar a los líderes un dashboard razonable sin que tengan que elegir entre frameworks rivales.

Sobre ese fondo, estas son las señales de entendimiento que yo miro últimamente. No es un catálogo cerrado — casi seguro me estoy olvidando de alguna y algunas las estoy terminando de cocinar en mi cabeza:

1. Código de corta vida y churn. ¿Qué porcentaje del código se elimina o se reescribe en los primeros N días después de haber sido merged? En repositorios sanos, con N = 30 días, un 10-20% de churn temprano es normal. Lo que empieza a ser sintomático es cuando el churn se dispara. El reporte de GitClear de 2025 ^fn-11 (con la salvedad de que es un vendor comercial y hay que leerlo con pinzas) muestra que el código revisado dentro de dos semanas pasó del 5.5% en 2020 al 7.9% en 2024, y las líneas copiadas/pegadas del 8.3% al 12.3%. Anecdóticamente, yo lo he visto: el código generado por IA tiende a churnear porque la primera versión resuelve el prompt, la segunda resuelve el requerimiento real cuando la realidad golpea, y la tercera refactoriza porque las dos anteriores divergieron de estilo. Tres reescrituras de la misma función en seis semanas, sin que el código vaya cobrando “forma”.

2. Profundidad de revisión. ¿Se están revisando los PRs, o simplemente se están aprobando? Las señales de alarma son claras: PRs de más de 500 LOC aprobados en menos de cinco minutos, comentarios por PR tendiendo a cero, tasa de aprobación con un solo revisor subiendo, time-to-first-review bajando mientras el tamaño del PR sube. Ese último patrón es el más delator: cuando el sistema aprueba cada vez más rápido código cada vez más grande, algo se rompió.

3. Distribución del conocimiento. ¿Cuántas personas en el equipo podrían responder, sin ayuda, una pregunta sobre este módulo? El bus factor de toda la vida, pero aplicado a pedazos concretos del sistema. Los equipos con métricas DORA impecables pueden tener un bus factor de uno en áreas críticas, y nadie lo nota hasta que esa persona se va de vacaciones.

4. Confianza en la recuperación. No solo MTTR, sino una pregunta cualitativa: ¿entendimos la causa raíz lo suficientemente bien como para explicarla en una frase, sin adornos? Este fue un cambio que propuse hace un tiempo en un equipo: después de cada incidente, el post-mortem empieza con una oración que explica qué pasó. Si no cabe en una oración clara, no entendimos. Los equipos con DORA impecable pueden tener tiempos de diagnóstico triplicándose sin que nadie note, porque nadie entiende del todo el código que están enviando.

Y ahora, la advertencia obligatoria: Goodhart aplica a todas estas también. Deployment frequency se juega fragmentando PRs artificialmente. CFR se juega reclasificando incidentes como “degradaciones”. MTTR se juega auto-resolviendo alertas flappy. El churn se juega dejando código muerto en vez de borrarlo. Los comentarios de revisión se juegan con nits performativos. Si los vuelves objetivo individual, los matas.

#.Cómo instrumentar esto sin volver al infierno de los dashboards

Una de las cosas que me hicieron odiar los reportes de LOC hace quince años fue la cultura que construyeron alrededor. El gerente miraba el dashboard el viernes, el ingeniero miraba el dashboard el jueves para asegurarse de que el viernes se viera bien. Era un mecanismo de vigilancia, no de aprendizaje. No quiero volver ahí. Sospecho que tú tampoco.

El principio rector es simple: instrumenta el flujo, no al individuo. Las métricas son del equipo y del sistema. No hay tablero de líderes. No hay ranking. No hay número por ingeniero al lado de su foto en el canal de Slack. Si tu instrumentación termina convirtiéndose en eso, cometiste el mismo error que en 2010.

El libro Software Engineering at Google, en su capítulo 7 ^fn-12, describe muy bien un marco útil: GSM — Goals, Signals, Metrics. Empiezas definiendo el goal (por ejemplo: “queremos entregar con baja tasa de regresiones”). Luego identificas las signals, que son las cosas observables que indicarían progreso hacia ese goal (CFR bajo, churn bajo, comentarios de revisión sustantivos). Luego, y solo luego, eliges las metrics concretas que aproximan esas signals. La clave es que las métricas están al servicio del goal, no al revés. Si la métrica se vuelve inútil o perversa, la cambias.

Para lo técnico, no hace falta reinventar nada. Un pipeline modesto de Postgres + Metabase o Grafana alimentado desde la API de GitHub, tu CI y tu incident tracker te da el 80% de lo que necesitas en un fin de semana. Si prefieres no construirlo, herramientas como LinearB, DX, Swarmia o Jellyfish hacen esto listo para usar. Cualquier camino funciona; el que no funciona es no instrumentar nada y gobernar por intuición.

Y el ritual mínimo viable: una retrospectiva quincenal del equipo donde se miran estas métricas en conjunto, se hacen preguntas sobre lo que se ve, y se cambian cosas chicas. No un dashboard ejecutivo mensual que mira a la gente desde arriba. El primero crea conversación; el segundo crea miedo.

#.Cierre — ¿rápido hacia dónde?

En Piano piano si va lontano cerraba con el proverbio italiano: despacio se llega lejos. No era una invitación a ir lentos, era un recordatorio de que la velocidad sostenible requiere bases sólidas.

Hoy quiero añadirle una vuelta de tuerca. La IA nos dio una cosa, y solo una: velocidad de generación. No nos dio dirección. No nos dio criterio. No nos dio entendimiento. Esas siguen siendo nuestras, las humanas, y son precisamente las que las viejas métricas no saben medir y las nuevas, si no tenemos cuidado, tampoco.

La pregunta “¿cuánto código produjimos?” nunca fue interesante. La pregunta interesante siempre fue “¿entendemos lo que construimos? ¿podemos cambiarlo mañana sin miedo? ¿podemos explicárselo a alguien que llegue nuevo?” Lo único que cambió es que ahora, con la IA, la primera pregunta se responde sola — y esa respuesta, convertida en métrica, no vale nada.

Las métricas que elijamos en los próximos dos o tres años van a decidir, silenciosamente, qué tipo de ingenieros vamos a ser dentro de diez. Si medimos generación, tendremos generadores. Si medimos entrega sostenible y entendimiento, quizás tengamos ingenieros. No es obvio cuál camino va a ganar. Pero sí es obvio que el LOC, por fin, murió.

Que descanse en paz. Lo mínimo que le debemos es no resucitarlo con otro nombre. Y sin embargo, mira alrededor: ya lo estamos haciendo.