Por qué no medimos la productividad del desarrollador (y qué medimos en su lugar)

La Rebelión Está Aquí

En enero de 2024, la autoridad de protección de datos de Francia multó a Amazon con 32 millones de euros por vigilancia de empleados "excesivamente intrusiva"¹. La compañía había estado rastreando pulsaciones de teclado, actividad del escáner y cada momento de "inactividad" en sus almacenes.

Amazon no está sola. Un estudio reciente encontró que el 50% de los trabajadores bajo vigilancia preferirían renunciar antes que soportar la vigilancia constante². Mientras tanto, los "mouse jigglers"—dispositivos que simulan actividad para engañar al software de monitoreo—ahora son bestsellers de Amazon. La ironía se escribe sola.

Esto no solo está pasando en almacenes. Está pasando en ingeniería.

Un ecosistema creciente de herramientas de "productividad del desarrollador" promete ayudar a los líderes de ingeniería a entender qué están haciendo sus equipos. Rastrean líneas de código, commits por día, horas frente al teclado y, cada vez más—con IA—incluso el contenido de lo que los desarrolladores escriben.

Aquí está la verdad incómoda: estas herramientas son vigilancia disfrazada de gestión. Y están empeorando los equipos de ingeniería, no mejorándolos.

El Problema: Por Qué las Métricas de Productividad Son Tóxicas

Examinemos qué miden realmente estas herramientas:

Líneas de Código

Como dice el dicho, medir la productividad de programación por líneas de código es como medir el progreso de aeronaves por peso. Bill Gates supuestamente lo expresó sin rodeos: "Medir el progreso de programación por líneas de código es como medir el progreso de construcción de aeronaves por peso."

Una discusión de Stack Overflow lo capturó perfectamente: "Medir la producción del desarrollador por líneas de código es como medir la efectividad de una planta de energía por los desechos que produce."

Más líneas a menudo significa peor código. La refactorización que reduce 500 líneas a 50 es progreso. La automatización que elimina un proceso manual es progreso. Una abstracción bien diseñada que previene trabajo futuro es progreso. Nada de esto aparece positivamente en las métricas de LOC.

Commits por Día

Trivialmente fácil de manipular. ¿Quieres aumentar tu conteo de commits? Divide un solo cambio lógico en quince commits pequeños. Agrega cambios de espacios en blanco. Haz commit en tu hora de almuerzo.

Más importante aún, los commits miden actividad, no impacto. Un desarrollador que pasa una semana diseñando una arquitectura que ahorra meses de trabajo al equipo tendrá menos commits que alguien enviando frenéticamente funcionalidades que crean deuda técnica.

Horas Trabajadas

Esta es particularmente insidiosa. La investigación muestra consistentemente que trabajar más de 50 horas por semana en realidad reduce la producción total³. Los desarrolladores que se quedan hasta tarde logran menos, no más, porque el agotamiento conduce a errores, malas decisiones y código que requiere rehacer.

Un estudio encontró que los desarrolladores que trabajaban horas excesivas literalmente producían trabajo negativo—creaban más problemas de los que resolvían.

Sin embargo, "horas en línea" sigue siendo una piedra angular de las herramientas de vigilancia.

El Problema de Goodhart

El economista británico Charles Goodhart observó que "cuando una medida se convierte en objetivo, deja de ser una buena medida."⁴

Cada métrica mencionada arriba es trivialmente manipulable:

• ¿Quieres más commits? Divide los cambios en fragmentos.
• ¿Quieres más líneas? Escribe código verboso.
• ¿Quieres más horas? Mantén tu laptop abierta.
• ¿Quieres más PRs? Envía cambios más pequeños y frecuentes.

En el momento en que empiezas a medir estas cosas, ya no estás midiendo lo que querías medir. Estás midiendo qué tan bien las personas manipulan tus métricas.

La Paradoja de la IA: Por Qué Está Empeorando

Si pensabas que las métricas tradicionales estaban rotas, la IA está a punto de empeorar todo.

La Ilusión de Productividad

El reporte DORA (DevOps Research and Assessment) de 2024—el estudio anual más completo sobre el rendimiento de entrega de software—encontró algo sorprendente: los equipos que usan asistentes de codificación con IA mostraron una disminución del 1.5% en rendimiento y una disminución del 7.2% en estabilidad⁵.

Espera, ¿qué?

Un estudio de 2025 de METR fue más allá. Encontraron que los desarrolladores experimentados usando asistentes de IA eran en realidad 19% más lentos en tareas del mundo real. Pero aquí está el truco: esos mismos desarrolladores creían que eran 20% más rápidos⁶.

La IA crea una brecha entre percepción y realidad. Los desarrolladores se sienten más productivos mientras en realidad logran menos.

Velocidad Individual, Desaceleración Organizacional

La IA amplifica la productividad individual en ciertas tareas—generar código repetitivo, escribir pruebas, explicar código. Pero esta aceleración individual a menudo se traduce en desaceleración organizacional.

El análisis de datos de ingeniería encontró que los equipos asistidos por IA completaron 21% más tareas, pero sus revisiones de código tomaron 91% más tiempo, e introdujeron 9% más errores⁷.

Más producción + revisiones más largas + más errores = entrega más lenta.

¿Cuál es la Diferencia Entre Productividad y Efectividad?

La productividad del desarrollador mide actividad: commits, líneas de código, horas frente al teclado. La efectividad del desarrollador mide resultados: si el trabajo se entregó, si se mantuvo y si ayudó al equipo. Aquí es donde nos desviamos del enfoque de capitalismo de vigilancia hacia las métricas de ingeniería.

"La productividad del desarrollador" es un concepto roto. Pero la efectividad del desarrollador es medible—si te enfocas en resultados, no en actividad.

Nuestros cinco principios centrales guían todo lo que construimos:

1. Orientado a resultados: Mide valor entregado, no actividad
2. Neutral a la IA: No rastrea el uso de herramientas, infiere de los resultados
3. Primero el desarrollador: Perfiles individuales privados por defecto
4. Coaching sobre juicio: Tendencias y orientación, no clasificaciones
5. Anti-manipulación: Puntuación multidimensional resiste la manipulación

Qué Significa Esto en la Práctica

No medimos commits, líneas de código ni horas trabajadas. Medimos:

• ¿Se entregó el trabajo? (Entrega)
• ¿Fluyó de manera sostenible? (Flujo)
• ¿Se mantuvo? (Calidad)
• ¿Ayudó al equipo? (Colaboración)

Un desarrollador logrando resultados excelentes con IA = efectivo. Un desarrollador logrando resultados excelentes sin IA = efectivo. Alta actividad + bajos resultados = preocupación, independientemente de las herramientas.

Las 6 Dimensiones de Efectividad

Medimos la efectividad a través de seis dimensiones. Cada dimensión tiene múltiples componentes que intencionalmente crean tensión entre sí.

Cada dimensión cuenta parte de la historia. La magia está en cómo interactúan.

El Diseño Anti-Manipulación (La Salsa Secreta)

Esto es lo que hace diferente a este sistema: optimizar cualquier dimensión individual típicamente perjudica al menos a otra.

El Punto Óptimo del Tamaño de Lote

Considera los tamaños de PR. No recompensamos "más PRs" o "PRs más grandes". Recompensamos el tamaño óptimo:

• 100-400 líneas: Óptimo. Puntuación de 100.
• Menos de 50 líneas: Sobre-fragmentado. La puntuación cae.
• Más de 800 líneas: Demasiado grande para una revisión efectiva. La puntuación cae.

No puedes manipular esto haciendo los PRs más pequeños O más grandes. Hay un rango óptimo, y las desviaciones en cualquier dirección te perjudican.

Proporción de Corrección de Bugs

De manera similar para la calidad, no solo penalizamos los bugs. Medimos la contribución neta:

• Corregiste más bugs de los que introdujiste: Puntos de bonificación.
• Introdujiste más de los que corregiste: Penalización.

No puedes manipular esto evitando código (sin bugs, pero tampoco correcciones). El sistema recompensa la contribución neta positiva a la calidad.

Privacidad como Arquitectura, No como Política

Muchas herramientas afirman ser "enfocadas en la privacidad" mientras aún permiten la vigilancia. Agregan una casilla de verificación en la configuración. Prometen que los gerentes no verán datos individuales. Crean políticas.

Las políticas pueden cambiarse. La configuración puede modificarse. Las promesas pueden romperse.

Nuestro enfoque es diferente. La privacidad está integrada en la arquitectura:

1. Los perfiles individuales están aislados — No hay endpoint para recuperar "todas las puntuaciones de desarrolladores"
2. No existen tablas de clasificación — El concepto no está construido
3. Los gerentes ven agregados — Patrones a nivel de equipo, no clasificaciones individuales
4. Los insights de coaching tienen alcance limitado — Solo visibles para el desarrollador (y opcionalmente, su gerente directo)
5. Limitaciones de exportación — Los datos individuales solo pueden ser exportados por el individuo

Esto no se trata solo de respetar a los desarrolladores (aunque lo es). Se trata de obtener datos precisos. En el momento en que las personas saben que están siendo clasificadas, la Ley de Goodhart entra en acción. En el momento en que comienza la vigilancia, los datos se vuelven poco confiables.

La confianza permite precisión. La vigilancia destruye ambas.

La Visión: De la Actividad a los Resultados

La industria está en un punto de inflexión.

El enfoque antiguo—métricas de vigilancia, seguimiento de actividad, teatro de productividad—se está desmoronando. La IA está acelerando el colapso. Los números son más grandes, pero significan menos.

El nuevo enfoque se centra en lo que importa:

• De "cuánto código" → "¿ayuda a los usuarios?"
• De vigilancia → confianza
• De métricas de vanidad → impacto en el negocio
• De teatro de productividad → mejora real

Los equipos que descifren esto tendrán una ventaja masiva. Retendrán mejores desarrolladores (que no tolerarán la vigilancia). Tomarán mejores decisiones (basadas en datos significativos). Realmente mejorarán (en lugar de manipular métricas).

El Sueño del CTO

Lo que los líderes de ingeniería realmente quieren:

1. Prueba de que la ingeniería está mejorando — No solo instantáneas, sino trayectorias
2. Métricas defendibles — Algo que puedan mostrar a la junta directiva que no pueda ser fácilmente descartado
3. Sin manipulación — Métricas que resistan la manipulación
4. Preservación de la confianza — Medición que no destruya la cultura del equipo
5. Medición lista para IA — Métricas que funcionen independientemente de las herramientas que usen las personas

Las métricas tradicionales de productividad fallan en los cinco requisitos. Son instantáneas, fácilmente manipulables, destructoras de confianza y completamente rotas por la IA.

Las métricas de efectividad—enfocadas en resultados, diseñadas para anti-manipulación, construidas sobre confianza—cumplen las cinco.

Qué Significa Esto para Tu Equipo

Si eres un líder de ingeniería considerando herramientas de "productividad de desarrolladores", haz estas preguntas:

1. ¿Qué estamos midiendo exactamente? Si la respuesta es actividad (commits, LOC, horas), huye.
2. ¿Puede manipularse? Si optimizar la métrica es más fácil que hacer buen trabajo, la métrica es inútil.
3. ¿Qué pasa con los datos? Si los individuos pueden ser comparados y clasificados, la confianza se erosionará.
4. ¿Cómo maneja la IA? Si intenta rastrear el uso de herramientas, ya está obsoleta.
5. ¿Ayuda a los desarrolladores a mejorar? Si es solo medición sin coaching, es vigilancia con pasos adicionales.

Si eres un desarrollador siendo sometido a estas herramientas, debes saber que no estás loco. Las métricas son sin sentido. La vigilancia sí hace daño. Los mejores equipos—aquellos para los que probablemente quieras trabajar—están rechazando este enfoque.

Únete a la Rebelión

Estamos construyendo algo diferente.

No vigilancia. No teatro de productividad. No métricas de vanidad que se ven bien en presentaciones de junta directiva pero impulsan mal comportamiento.

Estamos construyendo prueba de que tu equipo está realmente mejorando.

Comienza con medir lo que importa: resultados, no actividad. Tendencias, no instantáneas. Efectividad, no productividad.

Si estás cansado de métricas que miden las cosas equivocadas, vigilancia que destruye la confianza y herramientas que se vuelven obsoletas en el momento en que alguien abre un asistente de IA—deberíamos hablar.

Fuentes