Cómo medir la productividad del desarrollo con IA

No mediría la productividad del desarrollo con IA contando código generado ni preguntando si el asistente parece rápido. Relacionaría el resultado estable que entrega un equipo con el esfuerzo y la capacidad que consume, sin ocultar la calidad, el retrabajo ni el flujo completo. El tiempo hasta terminar es una medida necesaria, pero por sí solo mide latencia, no productividad.

Dos trabajos rigurosos pueden llegar a resultados opuestos. Uno puede medir una tarea acotada en una base de código nueva, mientras el otro observa a especialistas resolviendo incidencias reales en repositorios que conocen desde hace años. Ambos hablan de «productividad», pero no están midiendo el mismo trabajo.

Los porcentajes discrepan porque no miden el mismo trabajo

La evidencia publicada por METR, DORA, varios experimentos de campo y un estudio de Anthropic sobre aprendizaje no permite fijar un porcentaje universal de aceleración o ralentización. Cada diseño estudia poblaciones, herramientas, tareas y horizontes distintos.

La tabla describe trabajos diferentes, no una contradicción que haya que resolver escogiendo un ganador. La experiencia previa determina cuánto contexto puede aportar la persona y cuánto tarda en detectar un resultado plausible pero incorrecto. Por su parte, la madurez del repositorio condiciona el coste de integración y la herramienta limita lo que puede delegarse en la fecha del estudio. Al elegir la métrica, el equipo decide qué parte del esfuerzo queda fuera.

Terminar antes solo demuestra rapidez. Para hablar de productividad hay que medir también defectos, horas de retrabajo y resultados entregados.

Antes de usar un porcentaje en una decisión de equipo preguntaría cuatro cosas: quién hizo el trabajo, qué tarea resolvió, cuándo se probó la herramienta y qué significaba «terminado». Sin esas respuestas, el número informa sobre un experimento y muy poco sobre nuestra organización.

Generar código mide una actividad local

Un asistente puede producir en segundos una función que una persona habría escrito en veinte minutos. Esa comparación es válida y, al mismo tiempo, insuficiente. La función todavía debe encajar en el modelo del sistema, pasar las pruebas, respetar los contratos existentes, revisarse, desplegarse y mantenerse.

La diferencia se ve con un cambio pequeño. Añadir un campo a una respuesta de API puede exigir una sola línea en el serializador. Aun así, puede obligar a revisar permisos, compatibilidad con consumidores antiguos, documentación del contrato, datos personales, pruebas y telemetría. La cantidad de código generado apenas describe el trabajo.

Contar sugerencias aceptadas tampoco ayuda. Una persona puede aceptar mucho código bien porque el asistente resuelve trabajo repetitivo y correcto, bien porque ella revisa de forma superficial. La misma cifra representa una ganancia o un riesgo según lo que ocurra después.

La unidad de análisis es el cambio validado y estable, no el código que apareció primero. Para hablar de productividad hay que relacionarlo además con el resultado o el valor que debía producir, el esfuerzo consumido y el coste de calidad. Así, la atención se desplaza desde la actividad individual hacia el sistema de entrega y hacia lo que ese sistema consigue.

La unidad útil es el cambio validado y estable

Considero validado un cambio cuando cumple sus criterios, ha superado la revisión y puede desplegarse con la evidencia acordada. Lo considero estable cuando ha atravesado el periodo en el que el equipo espera detectar regresiones inmediatas, alertas o retrabajo atribuible a ese cambio.

La ventana de estabilidad se fija antes de observar los resultados y se adapta a cada familia de trabajo. Puede abarcar, por ejemplo, 72 horas para un servicio con señales continuas o un ciclo completo para un proceso periódico. Un cambio que aún no la ha completado queda marcado como observación incompleta; no se cuenta como estable ni se elimina. Los defectos tardíos se conservan como una medida aparte porque ninguna ventana breve puede capturarlos todos.

El recorrido completo tiene más tramos que la escritura:

requisito entendido
    → cambio propuesto
    → revisión
    → integración
    → despliegue
    → observación
    → cambio estable

La IA puede acortar el segundo tramo y alargar el tercero, o facilitar una prueba y hacer más difícil entender la implementación que la pasa. También puede reducir el tiempo hasta la primera propuesta a costa de más iteraciones antes de integrar. La medida completa conserva esas compensaciones.

No usaría el despliegue como final automático. Un cambio que entra en producción y provoca una corrección urgente al día siguiente no tiene el mismo valor que otro que permanece estable. La ventana acordada debe adaptarse al producto, pero permanecer fija durante la comparación para que dos cambios de la misma familia sean comparables.

Esta definición tampoco convierte toda contribución en un ticket. El diseño, la investigación, el soporte y la reducción de riesgo tienen otras salidas. La definición sirve para comparar cambios de software semejantes, que es donde los indicadores de generación suelen utilizarse peor.

La supervisión también consume tiempo y atención

Trabajar con IA desplaza parte del esfuerzo desde escribir hacia dirigir, evaluar y corregir. Ese trabajo puede ser más valioso que teclear código, pero no es gratuito.

Una petición precisa exige comprender el problema y sus límites, mientras que revisar la respuesta obliga a reconstruir qué hizo el agente, qué omitió y qué supuestos introdujo. Si el resultado falla, la persona decide si corrige, devuelve el trabajo o cambia de enfoque. Cada ciclo consume atención y retiene contexto que no puede dedicarse a otra tarea.

La carga aumenta cuando el cambio atraviesa muchos módulos o cuando la base de código contiene conocimiento tácito. Aunque el asistente lea miles de líneas, puede seguir sin conocer por qué existe una condición aparentemente redundante. Una persona experta reconoce esa historia porque recuerda el incidente o la restricción, mientras que alguien recién llegado puede aceptar la simplificación y descubrir el motivo en producción.

La supervisión útil deja rastros: número de ciclos antes de revisión, tiempo de revisión, cambios solicitados, pruebas añadidas y correcciones posteriores. No mediría el número de mensajes. Una conversación corta puede resolver una tarea simple o esconder una revisión pobre.

Siete medidas para no premiar actividad

Usaría siete medidas juntas porque ninguna basta de forma aislada. Todas pueden obtenerse sin contar líneas ni convertir la comparación en una clasificación de personas.

No agregaría las medidas en una puntuación. Una cifra única oculta la razón de la mejora. Si baja el tiempo y sube mucho el retrabajo, el equipo necesita ver ambos movimientos. Si aumenta la revisión y disminuyen las incidencias, puede haber una inversión razonable en calidad.

La comprensión es la medida menos cómoda y una de las más importantes, pero no requiere exámenes. Puede comprobarse durante la revisión: quien no escribió el cambio explica el flujo, localiza los invariantes y propone cómo modificaría un caso relacionado. Si el equipo no puede hacerlo, ha ganado velocidad local y ha creado una dependencia.

Cuándo cabe esperar una mejora y cuándo no

Mi hipótesis de partida es que la IA tiene más margen en tareas acotadas cuyo resultado puede comprobarse enseguida y que tienen criterios verificables. Migraciones mecánicas, generación de pruebas a partir de contratos claros, adaptadores repetitivos y cambios dentro de patrones bien establecidos permiten comprobar pronto si el resultado encaja.

El margen disminuye cuando el trabajo consiste en descubrir el problema, recuperar conocimiento tácito o decidir una arquitectura, y también en bases maduras donde una modificación pequeña puede romper contratos que no están documentados. En esos casos el agente produce una propuesta antes, pero la revisión concentra el coste.

Aprender merece una consideración aparte. Si el objetivo es entregar una tarea puntual, delegar la exploración puede ahorrar tiempo. Si el objetivo es que una persona domine una biblioteca o un dominio, aceptar una solución antes de construir el modelo mental puede perjudicar la siguiente tarea. El equipo tiene que decidir qué está optimizando en cada momento.

Una especificación útil mejora las condiciones porque reduce supuestos y hace observables los criterios. No sustituye la comprensión ni la decisión de arquitectura.

Un piloto observacional de cuatro semanas

Propondría un piloto observacional de cuatro semanas para calibrar las medidas y aprender dónde encaja la IA. No lo usaría para atribuirle causalidad ni evaluar a cada desarrollador. Si una familia no reúne una muestra suficiente o no cubre su ciclo normal, se amplía la ventana antes de decidir.

En la primera semana, el equipo elige dos o tres familias comparables. Las distingue por tipo de cambio, tamaño acordado antes de empezar, riesgo, módulos afectados y familiaridad con el código. También fija la ventana de estabilidad, el inicio y el final de cada tiempo y la política para atribuir retrabajo. Los criterios de inclusión y exclusión se escriben antes, y el equipo publica cuántos casos excluye y por qué. Una incidencia causada por el cambio nunca sale de la muestra.

Durante las semanas segunda y tercera el equipo usa la IA cuando considera que encaja y anota esa decisión antes de empezar. Registra los resultados anteriores junto con familia, riesgo, tamaño, familiaridad, herramienta, modelo, versión, tipo de uso, coste, tiempo activo y motivo de usar o no IA. Esta autoselección representa mejor el trabajo cotidiano, pero impide afirmar que la IA causó la diferencia.

Los datos se agregan por equipo con un mínimo de casos que evite identificar a una persona, acceso limitado y retención corta, y no se usan para clasificar individuos. El piloto también fija qué código o datos no pueden enviarse a una herramienta, cómo se protegen secretos y cómo se revisan licencias, dependencias y vulnerabilidades.

La cuarta semana se dedica a revisar casos, no solo promedios. ¿Dónde bajó el tiempo completo? ¿Qué cambios exigieron más revisión? ¿Apareció retrabajo? ¿La persona que mantuvo después el código pudo explicarlo? Se comparan familias de tareas y se conservan las excepciones que contradicen la tendencia.

Cuatro semanas no demuestran causalidad ni suelen ofrecer base para una inferencia estadística. Sí pueden revelar una medida inútil, una familia prometedora o un coste que el equipo estaba ignorando. Si la pregunta es causal, hace falta otro diseño: asignación aleatoria, implantación por fases o tareas emparejadas con controles previos.

El resultado del piloto puede ser una política acotada: usar la IA para transformaciones mecánicas y pruebas, exigir revisión adicional en interfaces públicas y reservar las tareas de aprendizaje para un modo en el que la herramienta formule preguntas, explique opciones y pida a la persona anticipar el siguiente paso antes de proponer la solución.

La decisión no sale de un umbral universal, pero tampoco se improvisa después de ver los datos. Antes del piloto el equipo acuerda qué mejora considera material y qué degradación de riesgo, retrabajo o comprensión sería inaceptable. Ampliaría el uso cuando mejore el resultado o el flujo sin aumentar el esfuerzo total ni empeorar la revisión, los incidentes o la comprensión. Lo mantendría acotado cuando el ahorro solo aparezca en familias concretas o exija una supervisión asumible. Lo detendría si el retrabajo, el riesgo o la pérdida de comprensión compensan el tiempo ahorrado.

La decisión se revisa cuando cambia la herramienta o el trabajo

Una medición fechada describe una combinación concreta de equipo, base de código, herramientas y tareas. Si cambia el modelo, el flujo de revisión o el tipo de trabajo, la conclusión puede dejar de servir.

Mantendría un conjunto pequeño de indicadores y revisaría la decisión cada trimestre. Con ellos buscaría dónde aumenta el rendimiento del sistema y dónde traslada trabajo hacia la revisión, la estabilización o el mantenimiento, no una justificación retrospectiva de la inversión.

La misma regla se aplica a la automatización fuera del desarrollo. El ahorro se calcula después de comprobar el resultado e incluir excepciones. La pieza sobre cómo verificar una automatización de IA desarrolla ese contrato.

Medir bien cambia la conversación. El equipo deja de discutir si «la IA va más rápido» y puede decidir en qué tareas entrega cambios mejores con un coste total menor. Esa es la productividad que merece la pena optimizar.

Última revisión: 27 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de software, inteligencia artificial aplicada y plataformas de aprendizaje.