Este post dentro de 6 meses (si no antes) estará obsoleto. El desarrollo de software asistido por inteligencia artificial avanza tan rápido que, la forma de medirlo e incluso el qué queremos medir, cambiará según el momento en el que nos encontremos. O mejor dicho, evolucionará en todos los niveles. Entonces, ahora, ¿qué nos interesa medir?
Desde mi experiencia trabajando la adopción de IA en el ciclo de desarrollo en diferentes organizaciones y equipos, creo que estamos en un punto donde lo que nos interesa es confirmar nuestras hipótesis de cómo debería impactar el uso de IA en el desarrollo. Este post servirá como ejercicio para, dentro de 6 meses quizás, escribir una siguiente fase y ver cómo van evolucionando el qué medimos según avanzamos en el uso.
Qué vas as ver en esta entrada
¿En qué nos vamos a basar para medir?
Fiel a mis principios, la base de qué medir será un híbrido entre los siguientes marcos (¿todavía se usa el término cherrypicking?):
- Métricas DORA: debe ser la luz que nos guía. Son métricas muy trabajadas sin el uso de IA. Nos ayudarán a entender si al añadir IA al proceso estamos impactando como se espera.
- SPACE/DevEx: nos quedaremos la parte del factor humano, cómo impacta.
- Sin marco (ideas propias): métricas que creo aportan a la foto general que queremos medir
¿Qué he evitado medir?
He intentado huir de cualquier vanity metric. Una vanity metric es una métrica que a simple vista puede parecer impresionante, pero realmente no informa de un impacto real. Por eso no vamos a medir puntos como líneas de código generadas (la IA puede generar todas las que quieras) o, de forma aislada, cuántas sugerencias son aceptadas.
Adopción
Vamos a medir la adopción del uso de la IA porque es la base para el resto de métricas. ¿Un mayor uso de la IA garantiza más eficiencia? ¿más velocidad? No lo sabemos. Pero necesitamos saber en qué punto estamos para entender el resto de métricas. Esto lo haremos combinando dos métricas: AI Code Acceptance Rate + AI Code Throughput.
Creo que se complementan para poder medir la adopción de la mejor forma: software en producción generado (asistido) por IA. Si una PR ha terminado en producción, ¿ha sido asistido por IA o no? ¿Y cuánto? Una métrica como «el 90% de las PR que han llegado a producción tienen un 80% de código generado por IA» marcará el umbral de si estamos en un momento maduro para poder medir el impacto del uso de IA con fiabilidad.
Delivery
La pregunta del millón: ¿cómo afecta el uso de IA a la entrega?
- Lead Time for Changes (DORA): la métrica por excelencia. ¿Hemos conseguido reducir el tiempo en que una funcionalidad se define, implementa y entrega a usuario final? Por ende, ¿estamos impactando en negocio? ¿Hemos reducido el time-to-market? Además, podemos comparar, ante tareas de tamaño parecido, con y sin IA, si acelera el proceso. ¿Realmente estamos entregando más rápido?
- Deployment Frequency (DORA): si reducimos el tiempo de desarrollo ¿no deberíamos estar desplegando más a menudo? Si medimos y vemos que estamos desplegando menos, no hemos mejorado el proceso, simplemente hemos desplazado el cuello de botella.
Calidad
Imaginemos que sí, que gracias al uso de IA estamos entregando más rápido pero… ¿a qué coste? ¿lo que entregamos es de calidad? ¿o estamos penalizando la calidad por la velocidad? Para ello, tomaremos las siguientes métricas:
- Change Failure Rate (DORA): fallos en despliegues de código generado por IA. Nuestro sistema ¿es más o menos estable con código generado por IA? Muy importante de medir para saber si lo que entregamos no está rompiendo.
- MTTR (DORA): ¿el equipo restaura más rápido un fallo en código que entiende menos por haberlo generado con IA? Esto también será un red flag para indicar que el proceso de revisión de código generado por IA no está funcionando o no se está ejecutando correctamente.
- Defect Escape Rate (DER, propia): DER es una métrica de calidad que complementa a Change Failure Rate. Mide el porcentaje de bugs que han conseguido escapar de nuestros tests en entornos pre-productivos y han llegado a producción. Es complementaria a CFR porque pueden ser bugs que, aunque no rompan, han llegado a producción. Podemos comparar si esta métrica ha empeorado respecto al uso de IA. La hipótesis es que debería bajar, ya que un buen modelo entrenado, con buenas skills y el contexto adecuado, no debería dejar escapar ni una.
- Rework (propia): si este retrabajo está enfocado a arreglar incidentes, sí, sería del marco DevEx/SPACE. La forma en que yo quiero enfocarlo es, en general, a cambios post-release. No necesariamente errores. Por ejemplo: código que la IA haya alucinado y metido condiciones de negocio que nadie ha indicado o incluso cambios de literales por suponer que se pueden mejorar. No rompen, pero no son cambios solicitados. De nuevo el proceso de revisión es muy importante.
Factor humano
Developer Experience Index (DXI, del marco SPACE/DevEx). Debemos medir cómo está afectando a los equipos y a las personas el uso de estas herramientas en su día a dia (la presión añadida de usarlas, el FOMO, expectativas de la organización, etc).
Hay asociado un coste humano de optimizar la entrega. Para medirlo, propongo encuestas mensuales (al inicio, después trimestrales) sobre el estado y la percepción de los equipos de productividad, foco y satisfacción atribuidas al uso de la IA. Por ejemplo, ¿cómo de fatigado está el equipo ahora que hay que revisar más que desarrollar?
Conclusiones
Estamos en un momento de rápida evolución de todo el ecosistema que rodea el desarrollo de software con IA. Por ello, para aplicar estas métricas, es necesario saber en qué punto de madurez estamos, antes de tomar decisiones (por ello es muy importante el bloque de métricas de adopción). Es muy importante tener datos de estas métricas de antes de la incorporación de la IA, para así poder comparar. Y, ahí sí, tomar decisiones.
Nos leemos en seis meses para ver qué de esto sigue en pie.
¿Quieres seguir aprendiendo todo sobre mundo tech? ¡Síguenos en redes sociales y en nuestro canal de YouTube!
