Más allá del ciclo de exageración: Impulsando un ROI real con AI en su organización

Tu programa de ingeniería asistida por IA está funcionando maravillosamente. Los paneles de control están en verde, el uso de co-pilot está en aumento, el liderazgo está encantado. Y no está produciendo nada. No porque tus ingenieros no usen las herramientas, las usan. No porque los modelos no sean lo suficientemente buenos. Lo son. No está produciendo nada por la misma razón que la transformación ágil no produjo nada. Y la iniciativa DevOps antes de eso, estamos midiendo el ritual, no el resultado.

Soy HD. Pasé los últimos dos años liderando equipos de ingeniería, construyendo los equipos detrás de la cadena de suministro global de IKEA, una de las operaciones logísticas físicas más grandes del planeta. Y cuando implementamos GitHub Co-Pilot en esos equipos, construí uno de esos hermosos paneles de control inútiles yo mismo. Esta charla trata sobre por qué fue un fracaso total.

Así que un pequeño calentamiento. Levante la mano, ¿quién aquí tiene un panel de control de IA en algún lugar de su empresa? Bien, mucho menos de lo que esperaba. Mantenga la mano levantada si ese panel de control tiene uso, adopción, usuarios activos, sugerencias de aceptación o tokens consumidos. Bien. Aún así, muy bajo, mucho más bajo de lo que esperaba. Ahora, mantenga la mano levantada si ese mismo panel de control puede responder claramente qué se envió más rápido. Vaya, cero.

Entonces, les mostraré un panel de control que realmente nos engañó. Implementamos Co-Pilot a unos pocos cientos de ingenieros tres meses después. El panel de control dice 94%, uso activo semanal. Wow. Decenas de miles de sugerencias de aceptación al día. Casi todos los ingenieros están usando activamente Co-Pilot en su trabajo diario. Presentamos, la gente asiente, qué momento de celebración, ¿verdad? Oh, no, para nada. Hombre, solo estamos quemando tokens. Sí, la salida es más rápida, los PRs se abren más rápidamente. Todo se siente más rápido, eso es más eficiente. Los ingenieros comparten cómo usan y desarrollan habilidades, cuán más rápidos son ahora, pero siento que algo falta, algo está mal. Cuando comenzamos a hacer las preguntas correctas, la verdad comienza a revelarse. ¿Está la IA ayudándonos a ahorrar en costos de la nube? ¿Ayudó a hacer nuestros entornos más seguros? ¿Estamos probando mejor ahora? ¿Tenemos menos defectos de escape? Nos preguntamos, silencio de nuevo, genuinamente, largo silencio. Así que el tiempo de ciclo sin cambios, la cadencia de lanzamiento, el mismo ritmo de sprint de dos semanas que hemos tenido desde antes de GPT 3.5. Y hemos tenido equipaje que necesitábamos sacudirnos. Nuestros flujos de trabajo no cambiaron. La mentalidad sigue siendo la misma. Así que 94% de adopción, cero cambio en la entrega. Así que recuerden esta pregunta, ¿llegaremos a eso más tarde? ¿Qué se envía más rápido? Volveremos a eso. Así que fue solo una ilusión, estamos enviando rápido, pero ¿qué? Así que la mayoría de los paneles de control que construimos o pedimos a la IA que construya no son excepciones, son estándares de la industria. La encuesta de McKinsey sobre el estado de la IA dice que el 88% de las organizaciones ahora usan IA en al menos una función. Solo 39 pueden atribuir algún impacto en las ganancias a ello. Así que básicamente más de la mitad de las empresas en realidad no se benefician significativamente de usar IA. No están ganando dinero. Peor aún, tampoco están ahorrando dinero. Entonces, ¿por qué no se convierte en valor? Esa es una pregunta más grande. Entonces, ¿dónde va a morir el ROI? Usamos IA donde es fácil, escribir código, escribir documentos, escribir pruebas, esos documentos que nadie lee. Más del 60% de los equipos no lo usan para las partes complicadas, planificación, revisiones, tal vez retros de equipo, despliegues, monitoreo y aún mejor, no planean hacerlo.

Si miras estas encuestas de tech overflow, entonces en realidad podría haberlo hecho, compartiré esta diapositiva más tarde, pero el 60% ni siquiera planea hacerlo. Así que básicamente estamos diciendo que la IA está transformando la ingeniería mientras cuidadosamente la mantenemos alejada del propio sistema de ingeniería. Eso no es transformación. Es autocompletar con un presupuesto de marketing. Quiero hacer una nota aquí, la encuesta de Deloitte dice que en 2026, volveré una vez más, las empresas todavía están enfocadas en la fluidez de IA en lugar de rediseñar el trabajo en torno a la IA. Esto es aterrador. Sé que a nadie le gustará lo que diré ahora, pero si tu equipo ha tenido acceso a estas herramientas durante meses y el flujo de trabajo es exactamente el mismo, no empieces cuestionando el modelo, las herramientas que usas. La IA resulta ser una prueba de fuego coincidente aquí. Se trata de la disposición a cambiar en tu organización, en tus equipos, en tu gente.

Así que nos encontramos en una sala de espera, ¿de acuerdo? Hemos llegado aquí, hemos llegado a la IA, pero estamos en una sala de espera. Así que hay tres mentiras o métricas que cuentan. ¿Por qué estamos atrapados en esa sala de espera? Las métricas que perseguimos nos están diciendo tres mentiras. Cada una lo suficientemente reconfortante como para detener la investigación, estamos quemando muchos tokens, estamos usando IA, estamos enviando más rápido, la producción es mayor, yay. Así que mentira número uno, uso equivale a adopción. Esta ha sido la mayor mentira que nos engañó. Tuvimos tres meses con un 73% de adopción, el 73% de todos nuestros usuarios de GitHub en la organización están usando Copilot. Lo estamos utilizando. Luego hemos visto 93, 94, pero el uso no equivale a adopción. El 94% era uso, inicios de sesión, finalizaciones, tasas de aceptación. El uso te dice que los ingenieros presionan tab, enter para solicitar. No te dice nada sobre si el flujo de trabajo cambió.

Así que no preguntes si la gente está usando IA. Haz una pregunta más difícil. ¿Dónde se rompería el flujo de trabajo si dejamos de usar IA de esta manera? No porque debamos apagar la IA. Por favor, no lo hagas. Eso sería ridículo. Por supuesto, los desarrolladores se ralentizarían. Pero esa no es la parte interesante. La parte interesante es si la IA desapareciera mañana, ¿cambiaría tu proceso de lanzamiento? ¿Cambiaría tu proceso de revisión? ¿Cambiaría tu estrategia de pruebas? Si lo único que cambia es que la gente escribe código más lentamente, entonces la IA todavía está sentada al borde del flujo de trabajo. Tu flujo de trabajo sigue siendo el mismo. ¿Útil? Sí. ¿Adoptado? Tal vez. ¿Transformador? No. Debería y deja huellas en el sistema.

Y mentira dos. No estamos usando solo IA. Tenemos una gran adopción. Pero eso no significa integración. Tienes adopción a nivel individual. Todos lo están usando. Y todos realmente se están beneficiando de la IA. Sí. Pero aún no estás integrado. Supongamos que tus ingenieros dependen de la herramienta. ¿Están dependiendo de ella dentro del trabajo? Eso importa. Los nuestros adoptaron genuinamente Co-Pilot para plantillas, pruebas unitarias, andamiaje, mensajes de confirmación. Las partes del trabajo que ya eran fáciles. Simplemente se volvió más rápido. La parte difícil, diseño del sistema. Depuración de integraciones de almacenes de 20 años. Revisión de código.

El proceso de lanzamiento en sí. Nunca lo tocamos. Aquí está el principio subyacente. Escribir nunca fue el cuello de botella una vez que tuvimos IA. De acuerdo. Tenemos excelentes autocompletados. Somos más rápidos. La adopción de la periferia es lo más fácil del mundo. Porque la periferia no resiste. La carrera de nadie depende de cómo se escriben sus mensajes de confirmación. O de cómo documentan las cosas.

Así que el flujo de trabajo central resiste. El flujo de trabajo central tiene propietarios, política, registros de auditoría y 20 años de memoria muscular. Que es exactamente por eso que el flujo de trabajo central es donde está el dinero. Y ahora estamos llegando al dinero. Tenemos adopción. Comenzamos a integrar. De hecho, en mi organización, digamos, somos lo suficientemente afortunados y maduros como para estar integrados también. Estamos usando IA de la mejor manera hasta el final. Somos usuarios avanzados.

Además, a nivel de equipo, lo hemos adoptado. Yay. Pero integración no equivale a valor. La mentira número tres es esta. Así que incluso cuando la IA está conectada al trabajo de ingeniería real, puedes acelerar un proceso que nunca fue la restricción. Nuestros ingenieros realmente escribieron código más rápido. Ese código más rápido fluyó en la misma cola de revisión. Los mismos entornos de prueba. Los mismos sprints de dos semanas.

Todavía estamos lanzando cada cuatro semanas. Estamos escribiendo código más rápido. Pero, ¿todos los equipos son así? No. Por supuesto, tenemos equipos que han integrado CoPilot profundamente. Y usan el tiempo ahorrado para generar documentación hermosa alrededor de eso. Pero finalmente establecimos que ningún humano la había leído en dos años.

Más código. Más documentación. Mismo producto. Mismos ciclos de lanzamiento. Así que estábamos produciendo más código, pero no más producto. Eso no es un fallo de tecnología. Esa es la vieja verdad con un nuevo disfraz. La mayoría de los problemas de IA son problemas organizacionales que aprenden a escribir. A veces reuniones, entrenamientos, etcétera, simplemente no puedes resolverlo de las maneras convencionales.

La mayoría de los problemas, esto no es nuevo que vino con IA. Este no es un problema de tres años. Este es un problema de edad, un problema milenario. A veces — no a veces, sino la mayoría de las veces, casi siempre — los problemas que tenemos son en realidad problemas de personas disfrazados de problemas técnicos. Mejor CI, mejores pruebas, mejores modelos, mejores herramientas, mejores agentes no van a resolver tu problema. A veces los problemas de personas están en realidad disfrazados de problemas técnicos que tú crees que puedes resolver. No.

Tengo una mentira adicional. Estamos integrados. Estamos aportando valor. Yay. Pero las horas ahorradas no significan también dólares ahorrados. No, no lo hacen. Horas ahorradas como el champú de hotel, ¿de acuerdo? Así que todos lo toman, lo llevan a casa, pero nadie realmente lo usa. Así que este es mi favorito porque suena tan amigable para el CFO. Eso nos ahorró 10,000 horas de desarrollador. Increíble. Pero, ¿dónde están? Quiero decir, ¿están en el banco? ¿Los pusimos en un almacén? Ya sabes, terminología de IKEA. ¿Están sentados en un pequeño frasco etiquetado como ahorros de IA? Por supuesto que no. El tiempo ahorrado no es valor. El tiempo ahorrado es energía potencial. Si no decides a dónde va, la organización decidirá por ti. Y la organización usualmente elige reuniones.

Así que la IA nos ahorró tiempo, así que programamos una reunión. Entonces, si el uso, la adopción y la integración mienten, ¿qué mides? Mides en tres niveles. Y si te niegas a dejar que uno sustituya a otro, nivel individual, de equipo, de negocio u organizacional. Nivel individual. ¿Realmente cambió la calidad del rendimiento de este ingeniero? No si les gusta la herramienta, mide la producción, el rendimiento de PR, las tasas de defectos, el tiempo de revisión, antes y después. Misma persona, misma base de código. Dos, nivel de equipo. ¿El sistema se volvió más rápido? Tiempo de nivel, velocidad de revisión, tiempo desde el commit hasta la producción. Este nivel importa porque las ganancias individuales rutinariamente tienen un precio aquí. Un ingeniero que codifica un 30% más rápido se convierte en un ingeniero 10x ahora. Alimentar un proceso de lanzamiento con una cola de seis semanas no ha cambiado nada excepto la longitud de la cola. Todavía estás enviando cada dos semanas. Hicimos que los contribuyentes individuales fueran más rápidos, los ICs más rápidos, y al sistema no le importó. Nivel tres, nivel de negocio, que es el más importante aquí.

Tiempo al mercado, costo, impacto de incidentes, ingresos, el nivel en el que vive tu CFO. El nivel del que pregunta mi colega de finanzas. Lento, ruidoso, confuso. La mayoría de las organizaciones reportan el nivel uno con el vocabulario del nivel tres. Así que decimos $10,000. Aún no te ahorró dinero. Al menos aún. Ese es todo el engaño. Usualmente uno inocente. Los co-pilotos dicen que 10,000 horas de desarrollador es una afirmación de nivel uno en un traje de nivel tres. ¿Guardado en qué? Si esas horas se convirtieron en más reuniones, no compraste nada.

Así que tres trampas que devoran tus datos mientras mides. Ahora, incluso midiendo las cosas correctas, esas tres trampas devorarán tus datos. Pisé en las tres para que tú no tengas que hacerlo. Probablemente tú también lo hayas hecho. Una es el sesgo de supervivencia. Tus estudios de caso provienen de equipos que se ofrecen como voluntarios, tuvieron éxito y les encanta contar la historia. El equipo que silenciosamente apagó el co-piloto en una semana, en la semana tres, no presenta en la exhibición de ingeniería.

Encuestamos a nuestros campeones de IA sobre el valor de la IA. Puedes adivinar la puntuación de la metodología en esa. Error de atribución. Celebramos una caída del 10% en el tiempo de fusión de PR durante un trimestre. Hasta que alguien señaló que habíamos simplificado la política de ramas y actualizado los corredores de CI en el mismo trimestre. ¿Fue la IA o la fontanería? No teníamos idea. Porque cambiamos todo a la vez. Si no puedes responder comparado con qué, no tienes una medición. Tienes un comunicado de prensa. Y el efecto Hawthorne, esto puede ser un poco familiar para algunos, los ingenieros se desempeñan de manera diferente cuando saben que el piloto está siendo observado. Y los pilotos siempre están siendo observados. Los resultados de tu piloto son los mejores números que jamás verás.

Incluso para la regresión, no para el pico. Entonces, ¿qué llevarse de esto? El lunes por la mañana, rastrea una métrica a una cosa que se envió de manera diferente. ¿Qué enviamos más rápido? Eso es lo más importante. Realiza una prueba de dependencia del flujo de trabajo. Elige un cambio real que vaya a producción esta semana. Mide cuántas sugerencias han producido. Rastrea el trabajo de principio a fin. Diseño, implementación, revisión de pruebas, lanzamiento y soporte. En cada paso, pregunta si la IA cambió materialmente la decisión, la velocidad, la calidad o el traspaso al siguiente paso. Si la respuesta es solo que escribimos el código más rápido, tienes una aceleración local. Eso está bien, pero no es transformación, de nuevo.

La prueba no es si los desarrolladores pueden vivir sin IA. Ese barco ya zarpó. Eso fue en 2025. Tercero, escribe tu lista de eliminación antes de la próxima reunión de dirección, no durante ella. Decide ahora qué evidencia cierra un piloto. Si no hay evidencia, bien. No es un piloto. Es una creencia con un presupuesto. Así que necesitas estar eliminando cosas. No comenzar más, pero también deberías estar eliminando cosas. No necesitas un mejor modelo primero. No necesitas una mejor pregunta. Así que, cuando regreses el lunes, toma tu métrica de IA más orgullosa y pregunta, ¿qué se envía más rápido? Y si la sala se queda bastante bien, eso no es un fracaso.

Esa es la primera medición honesta que has tenido. Gracias. Soy HD. Dejé tres historias reales, si tuviera más tiempo. Solo estoy 45 segundos fuera de tiempo, así que rápidamente las repasaré. Una, estábamos enviando más rápido.

Enviamos características que nadie pidió. Gracias a Google Analytics nos lo dijo, pero llegamos tres meses tarde.

Dos, identificamos ahorros en costos de la nube. Usé cloud code para utilizar mi gcloud CLI y así identificar nuestros recursos obsoletos. Máquinas virtuales que estaban abiertas, discos que no hemos tocado desde 2024. Cuadernos de Python de un líder de análisis de datos que dejó la organización en 2025. Detectó máquinas virtuales obsoletas, discos, clústeres, etcétera, que no podría listar y averiguar como humano porque simplemente hay demasiados. Y sí, genial.

Y gcloud dijo, puedes eliminar estos porque están obsoletos. No los has usado durante meses y años. Y ahorrarás 1000 euros al mes. 1000 a 2000. Yay.

Pero nuevamente fue inútil porque no los arreglamos. Identifiqué los ahorros, pero Tim no estaba lo suficientemente seguro. Tim no estaba lo suficientemente seguro para eliminar esas VMs o apagar esos discos. Así que esos fueron dos fracasos que tuvimos. Todavía podemos salvar el segundo. Pero tres, eliminamos dependencias costosas de terceros. Lo estábamos usando todo. Era muy caro. Construimos una versión interna de ello porque podíamos hacerlo en tan poco tiempo llenando los vacíos para que pudiéramos implementar con confianza ahorrando millones de euros al año. Muchas gracias.

Sí. Hasta ahora, solo tenemos una pregunta, pero estoy bastante seguro de que es solo porque ustedes miran, no querían pasar tiempo escribiendo porque el contenido que compartiste es oro. Espero que, por cierto, trabajes de cerca con mis colegas del departamento de ingeniería de soluciones de software en Microsoft Suecia. Si no, te presentaré a ellos porque lo que compartiste, queremos compartirlo con nuestros clientes también.

Pero, sí, tomemos esta pregunta que tenemos hasta ahora. Y sí, creo que destacaste todos los problemas, todos los desafíos, todos los problemas, pero solo comenzaste a dar solución. Provocaste un poco a la gente, y creo que muchos de ustedes sienten los mismos dolores, el mismo tipo de... Esto realmente está en el aire, pero no nos diste demasiados detalles sobre cuál es la solución. Y creo que la pregunta es exactamente sobre eso. ¿Puedes dar un ejemplo de cómo cambiaste los flujos de trabajo en tus proyectos que hicieron impacto de la IA generativa, como para codificación, para desarrollo, seamos más específicos.

¿Y cuál fue la métrica, preferiblemente un ejemplo de un proyecto brownfield? ¿Qué puedes compartir sin compartir demasiado sobre tus proyectos reales? En realidad, no lo hemos hecho. Seré honesto aquí, porque especialmente cuando se trata de proyectos brownfield, los ingenieros no están muy seguros. Y para aquellos que están seguros, solo se decepcionarán al ser rechazados por el negocio. Así que mirando la pregunta nuevamente, Janaya, ¿cuál fue la métrica? En este momento, todavía estamos a nivel individual a nivel de equipo. No hemos podido llegar al tercer nivel de aportar valor real al negocio al menos. Así que tengo que dar una respuesta honesta aquí, aún no estamos allí. Pero hemos descubierto, puedo decir, hemos descubierto llegar al segundo nivel de individual a equipo, y eso fue todo. Gracias por tu respuesta muy honesta y abierta. Marquemos esto como respondido.

Tomemos... Sí, básicamente, creo que mencionaste más o menos sobre cómo mides el impacto de la IA. Diste un ejemplo, y por supuesto, toda tu sesión trata sobre métricas, así que todas las preguntas giran en torno a eso. Además de las métricas de experiencia del desarrollador, ¿qué recomendarías medir al evaluar la salida de la IA? Eso depende de qué salida estemos hablando. Pero lo que puedo decir, uno de los... Así que podemos hablar sobre los equipos, podemos hablar sobre el negocio. Tomaré esa pregunta nuevamente en dos niveles. Para los equipos, puedes resolver los puntos de dolor que tienen los equipos. Pienso en CI, pero CI tarda una hora en ejecutarse. ¿Puedes usar IA para reducir el tiempo de ejecución de CI de 60 minutos a 25 minutos a 50 minutos? Entonces eso es una victoria. No porque estemos ahorrando computación durante 45 minutos, sino porque estamos ahorrando tanta frustración y tiempo interrumpido del valioso tiempo de los ingenieros senior en ese asunto. Y cuando se trata de negocios, como gerente de ingeniería, tengo un presupuesto, pero también soy responsable de él. Así que necesito hacer la pregunta, está bien, ¿por qué es tan alto nuestro costo en la nube? Así que di ese ejemplo de revisar nuestros recursos de G cloud. Por ejemplo, como humano, necesitas listar todas las VMs, listar todos los discos, los cuadernos de Python tus clústeres, etcétera. Como humano, este es un proceso muy difícil. Así que puedes responder ya sea, ¿me ayuda a ahorrar dinero o me ayuda a ganar más dinero? Creo que esa será la pregunta definitiva que podemos responder. Sí. Justo. Sí, creo que aquí en la mayoría de los casos hablamos sobre desarrollo de software empresarial, cuando el objetivo final es algún ingreso, algunas ganancias. Gracias. Y si tomamos este, ¿cómo mides el impacto de la IA si comienzas a medir cuando los equipos ya están usando IA? Así que tal vez este sea un temor de alguien, que estás un poco tarde.

No hiciste una instantánea de la línea base antes de la IA, porque ya estamos con IA desde hace algunos años. Danos esperanza de que no es demasiado tarde para comenzar a medir el impacto de la IA, incluso para los equipos que ya usan IA. Esa fue una pregunta sobre ingenieros junior y cómo los líderes pueden ayudarlos. Quiero ofrecer una perspectiva muy diferente sobre esto, porque no quiero dar una respuesta aquí que puedas encontrar fácilmente en Reddit, LinkedIn o Google. Así que otra perspectiva diferente que daría es, no el impacto de la IA en tus lanzamientos, procesos, métricas de negocio, tus métricas Dora, etc. Pero puedes verlo desde una perspectiva de crecimiento de personas. Así que hubo una pregunta sobre juniors, por ejemplo. Después de usar IA, ¿mis ingenieros se volvieron más competentes? ¿Les ayudó a aprender nuevos frameworks, nuevas librerías, nuevas tecnologías? ¿Mi ingeniero de front-end ya comenzó a contribuir a nuestro código de infraestructura para que mi ingeniero senior de back-end no se vea molestado y pueda concentrarse? Y también mi ingeniero junior también adquirirá nuevas habilidades. ¿Resultó en nuevas promociones en el último año? Entonces, ¿cómo está mejorando las habilidades de nuestra gente y cómo está transformando la forma en que trabajan? Esto es una de las cosas que mediría además de qué tan rápido estamos lanzando, la tasa de defectos de escape, los costos de la nube, el impacto en el negocio, etc. Así que si ya estás en esa lista, cuando lo busques en Google, vas y preguntas a tu GPT, ya tendrás esta respuesta. Así que no quiero darte esta respuesta. Pero puedes verlo desde una perspectiva completamente diferente al ver cómo las personas usan su flujo de trabajo diario para que ayude a tu gente, a tu equipo, a mejorar sus habilidades. Así que esa sería una de las cosas diferentes que creo que podrías medir. Muchas gracias, Ht, por tu sesión y por tus respuestas. Un placer. Y sí, seguimos con nuestro programa. Demos un gran aplauso a Ht.