Hace unos meses, un CTO que conozco impulsó un cambio masivo directamente en producción. Había usado una herramienta de programación con IA para generar todo el proceso durante un fin de semana, saltándose la revisión de código, saltándose el staging y desplegándolo él mismo. Para la mañana del lunes, el sistema estaba roto. El ingeniero de QA que pasó dos días desentrañando los daños dimitió la semana siguiente.
Cuando escuché la historia, mi primera reacción no fue por el fallo técnico. Los incidentes de producción ocurren. Mi reacción fue sobre lo que revelaba: un CTO que había confundido productividad personal con liderazgo organizacional. Tenía la autoridad para saltarse todos los procesos en los que dependía su equipo, y la usaba porque la IA le hacía sentir rápido.
Esa historia refleja algo que sucede en las organizaciones que adoptan IA: el puesto de CTO está bajo más presión para cambiar que cualquier otro puesto en la organización de ingeniería, y la mayoría de los CTO responden haciendo las cosas equivocadas más rápido.
Cinco anti-patrones que merece ser nombrados
Los hilos de Reddit, las conversaciones en los pasillos de conferencias, las llamadas de aviso, todos relucen los mismos modos de fallo. He empezado a ponerles nombre porque nombrar un problema es el primer paso para dejar de serlo.
El programador de vibración
El CTO que utiliza herramientas de IA personalmente pero nunca construye el marco organizativo para que los demás las utilicen bien. Codifican prototipos con vibración, los llevan a producción y crean un sistema de dos niveles: el CTO opera sin restricciones mientras el equipo opera bajo procesos que el CTO ya no sigue. El mensaje es corrosivo. Si la persona que definió los estándares de calidad no los cumple, nadie más lo hará tampoco.
El emisor del mandato
El CTO que presenta la adopción de la IA como urgente y existencial. «Adopta IA o te quedas atrás.» «Necesitamos un 80% de uso de IA para el tercer trimestre.» Amazon estableció objetivos para que el 80% de los desarrolladores usaran IA semanalmente y registró su consumo en las clasificaciones. Los empleados respondieron realizando tareas innecesarias para inflar las puntuaciones. El comportamiento ahora tiene un nombre: tokenmaxxing. Informes del Financial Times y filtraciones internas describen paneles de uso similares en Meta, Disney y JPMorgan.
Los equipos que reciben la IA como «solo otra herramienta más en el conjunto de herramientas» la adoptan. Los equipos que lo reciben como «haz esto o tu trabajo está en riesgo» se resisten, lo manipulan o se van. El encuadre es una decisión de liderazgo, y la mayoría de los CTOs eligen el encuadre que produce los peores resultados.
El evitador métrico
El CTO que no puede explicar el ROI de la IA al consejo. La infraestructura de IA es ahora la mayor línea de ingeniería en muchas empresas, y cuando el consejo pregunta qué produce, la respuesta es vaga. «Productividad de los desarrolladores.» «Envío más rápido.» Sin números, sin marco, sin un registro honesto de lo que cambió y lo que no.
Una encuesta reciente de Gartner a 350 empresas con más de 1.000 millones de dólares en ingresos reveló que el ochenta por ciento había reducido personal como parte de la adopción de la IA. Los recortes no mostraron correlación con una mejora del ROI. Si no puedes medir el retorno, no puedes gobernar la inversión y, desde luego, no puedes justificar la disrupción organizativa.
El optimizador de conteo de cabeza
El CTO que trata la adopción de la IA como un ejercicio de reducción de plantillas. Corta al equipo, da herramientas de IA a los supervivientes, espera el mismo rendimiento con menos gente. Las matemáticas quedan bien en una hoja de cálculo. En la práctica, pierdes conocimientos institucionales que ninguna herramienta de IA puede reemplazar, sobrecargas al equipo restante hasta que se agotan o se van, y descubres seis meses después que las herramientas de IA necesitan exactamente el tipo de juicio experimentado que acabas de eliminar.
Un exingeniero de Microsoft Azure Core describió el patrón desde dentro: precipicio de compensación, congelación de contrataciones, colapso de la moral, trabajar al 70% de su capacidad porque «mejor que nadie». El bucle de ironía es predecible. Las empresas despiden a personas con experiencia para financiar la IA, pierden a quienes entienden los sistemas que la IA necesita mejorar, ven cómo la IA fracasa por carecer de conocimiento institucional y luego contratan consultores para reconstruir lo que se perdió.
El delegador pasivo
El CTO que permite que la dependencia del proveedor crezca sin control. Cuando tu proveedor de herramientas de codificación con IA cambia los precios, limita el uso o degrada la calidad, y todo tu flujo de trabajo de ingeniería depende de ello, ese es un único punto de fallo que decides no gobernar. Un titular de un contrato de Microsoft de 50 millones de dólares describió un apoyo que se había convertido en «simplemente un tipo tomando nuestras preguntas y poniéndolas en Copilot.» La dependencia del proveedor es un riesgo estratégico, y la mayoría de los CTOs no la tratan como tal.
De qué es realmente el trabajo
Estos fallos parecen diferentes a simple vista, pero surgen del mismo malentendido: la adopción de la IA es un problema de rediseño organizativo, y el CTO es la única persona que está en posición de tratarlo como tal.
Cuatro responsabilidades destacan y la mayoría de los CTOs las ignoran o las delegan a personas que no pueden hacerlas.
Patrocina de forma visible, no solo económicamente
Aprobar el presupuesto para herramientas de IA no es patrocinio. Asistir a la primera sesión de desarrollo estructurado de IA sí lo es. Cuando el CTO está presente durante una sesión de mob elaboration, ocurren dos cosas: el equipo entiende que esto no es un experimento paralelo, y el CTO entiende lo que la metodología realmente exige de la organización.
El patrocinio visible también significa proteger la iniciativa de anticuerpos organizativos durante los dos primeros trimestres. Cada nueva metodología se enfrenta a la resistencia de personas cuya autoridad o comodidad depende de la antigua forma. El CTO es la única persona con suficiente poder organizativo para proteger a un piloto de la presión de «pero siempre lo hemos hecho así».
Transfiere lo que reportas a la junta
La velocidad y los puntos de la historia fueron diseñados para un mundo donde los humanos escribieron cada línea de código. Cuando la IA genera código y los humanos lo validan, medir la velocidad es medir lo incorrecto. Estás contando la velocidad de la pieza que ya era rápida.
Las métricas de reemplazo existen: tiempo de ciclo por unidad entregable, calidad del artefacto, tasa de finalización de intenciones, ratio de efectividad de la IA, satisfacción del desarrollador. El verdadero cambio está en la propia conversación. La junta necesita escuchar: «Antes medíamos la velocidad a la que tecleábamos. Ahora medimos lo bien que pensamos, porque pensar es el cuello de botella que la IA no resolvió.» Si no puedes tener esa conversación, estás gestionando la adopción de la IA sin gobernarla.
Proteger el conocimiento institucional durante la transición
El momento más peligroso en la adopción de la IA es cuando la organización decide que las personas con experiencia son caras y la IA es barata. Las personas con experiencia tienen el contexto que hace útil la salida de la IA: por qué se construyó el sistema de esta manera, qué falló antes, qué restricciones son de carga y cuáles son legados. Sin ese contexto, la IA genera código plausible que se interrumpe en producción bajo condiciones que nadie pensó en especificar.
Proteger el conocimiento institucional significa tres cosas concretas. Primero, no descartes a quienes entienden los sistemas hasta que el flujo de trabajo de IA haya demostrado que puede funcionar sin su juicio. Segundo, integrar la transferencia de conocimiento en el propio proceso de desarrollo de IA, mediante rituales estructurados donde ingenieros experimentados validan la producción de IA y explican su razonamiento al equipo. Tercero, reconoce que la atrofia de la habilidad es real. Los desarrolladores que dejen de practicar los fundamentos porque la IA los maneja perderán esas habilidades en cuestión de meses. La metodología debe incluir la práctica deliberada, no solo la producción asistida por IA. Varios equipos con los que he trabajado introdujeron rotaciones de depuración sin IA, guías de revisión de arquitectura y explicaciones estructuradas post-revisión específicamente para evitar esta decadencia.
Rediseñar trayectorias profesionales que no dependan del crecimiento de plantilla
Un responsable de ingeniería describió el problema con precisión: la IA automatizó la mayoría de sus tareas mecánicas, sus 1:1 mejoraron, pero se sentía «aburrido». La congelación de contrataciones acabó con su camino de ascenso. Su perspectiva: «la construcción de imperios era la única forma de ascender.»
Cuando la IA se encarga de más trabajo mecánico, la escalera profesional tradicional se rompe. La progresión que dependía de gestionar equipos más grandes, lanzar más funcionalidades o demostrar una especialización técnica más profunda en un ámbito muy limitado, todo eso se comprime. El trabajo del CTO es construir nuevas escaleras antes de que las antiguas se derrumben. Progresión basada en la calidad del juicio, el pensamiento sistémico, la integración entre dominios y la capacidad de validar y dirigir la salida de la IA en lugar de producir resultados manualmente.
Las organizaciones que se saltan este trabajo pierden a sus pensadores de sistemas y expertos en el sector en menos de nueve meses, exactamente las personas que más necesitan para que la transición tenga éxito.
La conversación sobre la medición no se puede evitar
Todos los CTO a los que aconsejo acaban topándose con el mismo obstáculo: la junta quiere saber qué produce la IA, y la respuesta honesta es «No estoy seguro.»
El problema es que no faltan paneles de control. El problema es que la mayoría de las organizaciones adoptaron herramientas de IA sin definir cómo es el éxito más allá de «los desarrolladores lo usan». El uso no es valor. El consumo de tokens no es productividad. Las líneas de código generadas no son entregadas por software.
La conversación sobre medidas con la junta requiere honestidad sobre tres cosas. Primero, qué cambió: tiempos de ciclo, tasas de defectos, satisfacción del desarrollador, tiempo hasta producción para nuevas capacidades. Algunas organizaciones están viendo avances reales aquí, y reconocerlos con honestidad forma parte de la conversación. Segundo, qué no cambió: la complejidad organizativa, la coordinación de la sobrecarga, el tiempo dedicado a comprender los requisitos y a tomar decisiones de diseño. Tercero, lo que empeoró: la carga de revisión cambió, la deuda de comprensión se acumuló en bases de código que nadie entiende del todo, y aumentó la dependencia de los proveedores.
Si no puedes tener esa conversación en tres partes, no estás gobernando la adopción de la IA. Esperas que todo salga bien.
La ruptura de identidad no se puede delegar
Existe una dimensión en la adopción de la IA que ningún marco, metodología ni estructura de gobernanza aborda completamente: la experiencia humana de ver cómo tu identidad profesional cambia bajo tus pies.
A los desarrolladores cuyas carreras se basaron en escribir código se les dice que su valor ahora está en revisar código. Los responsables de ingeniería cuya autoridad provenía de la profundidad técnica están viendo cómo la IA aplana el gradiente de conocimiento que los hacía esenciales. Los ingenieros senior que mentorizaron a los juniors mediante emparejamientos en la implementación están descubriendo que la IA se encarga de la implementación y menos personas piden orientación al ingeniero senior.
Esto es un problema de identidad. Y el CTO marca el tono de cómo la organización lo gestiona.
Los CTOs que gestionan bien esto hacen tres cosas. Nombran la disrupción con honestidad en lugar de fingir que la IA es «solo una herramienta». Celebran públicamente las nuevas habilidades, haciendo que la validación, la experiencia y la facilitación sean tan prestigiosas como antes era el código de envío. Y dan tiempo a la gente, porque la transición de «escribo código» a «dirijo y valido código generado por IA» requiere una reconstrucción profesional de identidad que lleva meses, no semanas.
Los CTOs que gestionan mal esto o lo ignoran por completo («simplemente adaptan») o sobrecorrigen con objetivos obligatorios de uso de IA que hacen que la interrupción de la identidad parezca una amenaza de rendimiento en lugar de una transición soportada.
El verdadero trabajo, dicho de forma clara
El verdadero trabajo del CTO cuando la IA cambia la forma en que se construye el software es desarrollar la capacidad organizativa para usar bien la IA. No para adoptar más rápido que la competencia, no para reducir plantillas, para no alcanzar objetivos de uso ni para impresionar al consejo con el gasto en IA.
Eso significa una metodología que estructure cómo trabajan juntos los humanos y la IA, métricas que midan los resultados más que la actividad, trayectorias profesionales que recompensen las habilidades que la IA no puede reemplazar y una comunicación honesta sobre lo que está cambiando y lo que no.
El CTO que programó la vibración para producción y rompió todo no estaba fallando en tecnología. Estaba fallando en el liderazgo. Tenía las herramientas más potentes disponibles y ningún marco para usarlas de forma responsable. Su equipo tenía procesos que no seguía, métricas que no seguía y una escalera profesional que estaba activamente socavando al demostrar que la velocidad individual impulsada por IA importa más que la disciplina organizativa.
Cada CTO que lee esto está en algún punto entre esa historia y la alternativa. La alternativa es más deliberada, desarrolla capacidad en lugar de consumirla y trata la adopción de la IA como una transformación organizativa más que como un despliegue de herramientas.
La pregunta que merece la pena hacer: si tu equipo de ingeniería describiera tu liderazgo en la adopción de IA a un desconocido, ¿describiría el patrocinio o los mandatos? ¿Metodología o teatro de métricas? ¿Inversión en carrera o optimización de plantilla?
Las organizaciones que tengan éxito con la IA serán las que preserven el juicio mientras cambian la forma en que se realiza el trabajo. La respuesta a esa pregunta es tu verdadero trabajo.
Ricardo
