Durante el último año, he tenido la misma conversación con al menos treinta CTOs y vicepresidentes de Ingeniería. El escenario cambia: un pasillo de conferencias, una videollamada, una cena después de un taller. Las palabras cambian. Pero la conversación siempre es la misma.

Empieza por un número. «Nuestros desarrolladores son un 40% más productivos.» O un 30%. O un 50%. El número varía, pero la confianza que hay detrás no. Lo han medido. Tienen paneles de control. La junta ha visto las diapositivas del juego.

Luego llega la pausa. La parte en la que la voz baja medio registro y surge la verdadera pregunta.

«¿Entonces por qué parece que estamos enviando menos?»

Esa pregunta, la brecha entre lo que dicen las métricas y lo que experimentan los equipos, es de lo que realmente trata Reimagine, Don’t Retrofit . No es una metodología. No es un marco. Una conversación sobre liderazgo que la mayoría de las organizaciones aún no han tenido.

La pregunta detrás de la pregunta

Cuando un CTO me dice que sus equipos son más rápidos pero no mejores, no está describiendo un problema de herramientas. Están describiendo un problema de proceso que se manifiesta como un problema de liderazgo.

Las herramientas funcionan. Los asistentes de programación con IA realmente reducen la carga mecánica de escribir código. Los desarrolladores dedican menos tiempo a la lista estándar, menos tiempo a la búsqueda de sintaxis, menos tiempo al trabajo repetitivo que consumía horas pero no aportaba valor intelectual. Esa parte es real, y se refleja de forma constante en todos los sectores en los que trabajo.

Lo que también es real es lo que ocurre después. Las revisiones de código se convierten en cuellos de botella porque los revisores no pueden seguir el ritmo del volumen. Los fallos de integración se multiplican porque los servicios generados por IA hacen suposiciones diferentes sobre los mismos contratos de API. Existen brechas de seguridad porque la IA nunca recibió el contexto organizativo que un desarrollador senior lleva en la cabeza. Los gráficos de velocidad de sprint tienden a subir, mientras que los defectos de atención al cliente también tienden a subir, y nadie conecta ambos porque viven en paneles diferentes.

Escribí sobre este patrón en The Mismatch Between AI Code Assistants and Enterprise Software Development hace varios meses. Lo que no entendí del todo entonces fue que la diferencia no es solo técnica. Es organizacional. El proceso en sí, las ceremonias, las métricas, los mecanismos de coordinación, fueron diseñados para un mundo donde la IA no existiera. Verter una capacidad fundamentalmente diferente en ese recipiente no hace que funcione mejor. Hace que el contenedor se agriete.

Los CTOs con los que hablo lo notan. Pueden sentir las grietas. Pero los paneles dicen que todo está bien, y desafiar un panel que dice «40% más productivo» requiere un tipo de argumento diferente al que la mayoría de los líderes de ingeniería están acostumbrados.

Ese argumento es lo que ofrece el libro.

El núcleo es una única inversión: el desarrollo tradicional asume que los humanos generan y las máquinas asisten. El desarrollo impulsado por IA invierte eso. Las máquinas generan, los humanos validan. Una vez que ocurre esa reversión, todas las estructuras construidas alrededor de la producción solo humana comienzan a fracturarse.

Por qué esto es un problema de liderazgo

Hay una razón por la que no escribí un manual técnico. Las organizaciones que luchan por la adopción de la IA no tienen dificultades porque sus ingenieros carezcan de habilidad. Están luchando porque sus líderes hacen la pregunta equivocada.

La pregunta equivocada es: «¿Cómo hacemos que la IA funcione mejor en nuestros sprints?»

La pregunta correcta es: «¿Siguen siendo nuestros sprints la forma correcta de trabajar?»

Esa segunda pregunta resulta incómoda porque pone en desafín inversiones que tardaron años en construirse. Transformaciones ágiles. Certificaciones de Scrum Master. Infraestructura de seguimiento de velocidad. Estructuras de rol. Carreras basadas en dominar una forma específica de trabajar. Cuando alguien sugiere que el proceso en sí podría ser el problema, la resistencia no es solo intelectual. Es emotivo.

He estado en esas habitaciones. He visto la cara de un Scrum Master cuando se da la impresión de que las ceremonias que ha perfeccionado durante una década podrían necesitar evolucionar. He visto a un arquitecto procesar la idea de que su junta de revisión de diseño, la que construyó desde cero y de la que está justificadamente orgulloso, podría estar ralentizando las cosas en lugar de proteger la calidad. Son personas hábiles y dedicadas. La conversación no trata de decirles que sus habilidades no importan. Se trata de decirles que el contexto ha cambiado y que sus habilidades deben aplicarse de forma diferente.

Eso es una conversación de liderazgo, no técnica. Y requiere algo que ningún marco ni metodología puede ofrecer: coraje.

El paralelo de la nube

He visto este patrón antes. No con IA, sino con la nube.

En los primeros días de la adopción de la nube, la mayoría de las organizaciones intentaron adaptar la plataforma. Aplicaron sus procesos locales existentes, sus modelos de gobernanza existentes, sus prácticas operativas actuales y los aplicaron a la infraestructura en la nube. Trataban la nube como un lugar diferente para gestionar las mismas cosas de la misma manera.

El resultado era predecible: mayores costes, peor rendimiento, más complejidad. Gestionaban dos modelos operativos en lugar de uno, y ninguno funcionaba bien.

Las organizaciones que tuvieron éxito reconocieron que la nube no era solo un lugar nuevo para gestionar cargas de trabajo. Era un nuevo modelo operativo. Rediseñaron la gobernanza para una infraestructura dinámica. Adoptaron la infraestructura como código. Reconsideraron la seguridad para la responsabilidad compartida. Cambiaron la forma en que medían el coste.

Escribí sobre esto al hablar del poder silencioso de la gobernanza en la nube: las organizaciones que resistían la gobernanza porque sentían que las ralentizaría acababan siendo más lentas que las que invirtieron en ella al principio. La gobernanza no limitaba la adopción en la nube. Lo habilitó.

El paralelismo con el desarrollo impulsado por IA es directo, y creo que las apuestas son mayores. La nube cambió dónde y cómo ejecutas el software. La IA cambia cómo la construyes. Las organizaciones que tratan la IA como «una forma más rápida de hacer lo que ya hacemos» experimentarán la misma decepción que las organizaciones que trataron la nube como «un lugar diferente para ejecutar lo que ya ejecutamos».

Lo que realmente argumenta el libro

El libro presenta un argumento único y sostenido a lo largo de trece capítulos: el propio ciclo de vida del desarrollo de software necesita ser rediseñado para un mundo donde la IA sea un participante central en cómo se construye el software.

No las herramientas. No la infraestructura. El proceso. La forma en que los equipos planifican, elaboran, construyen, validan y miden su trabajo.

Los primeros cuatro capítulos diagnostican lo que está ocurriendo: la paradoja de la productividad, la trampa del «caballo más rápido» de adaptar la IA a ceremonias ágiles, la brecha de gobernanza cuando el código generado por IA elude los controles humanos, y el fenómeno de la codificación de vibración donde la velocidad sin estructura crea deuda técnica a un ritmo que ninguna organización puede sostener.

Si has seguido este blog, parte de ese diagnóstico te resultará familiar. Exploré partes de ello en publicaciones sobre por qué la IA necesita un nuevo ciclo de desarrollo de desarrollo, el papel cambiante del desarrollador y por qué la IA falla en bases de código existentes. Pero las entradas del blog son bocetos. El libro es la imagen completa: las mismas historias seguidas a lo largo de los capítulos, las mismas organizaciones que van desde la confusión hasta la claridad, las conexiones entre problemas que solo se hacen visibles cuando las expones de principio a fin.

Los cinco capítulos centrales presentan la metodología: el Ciclo de Vida del Desarrollo Impulsado por IA, creado por Raja SP y su equipo en AWS, que he traducido a la práctica empresarial. Una nueva arquitectura de trabajo basada en Intenciones, Unidades y Pernos. La realidad de brownfield. La redefinición del papel del desarrollador de productor de código a proveedor de juzgamientos.

Los últimos cuatro capítulos son los que creo que más importan para la audiencia de CTO: la gobernanza como facilitadora, pilotos que generan evidencia en lugar de entusiasmo, métricas que miden el valor en lugar de la velocidad, y hacia dónde se dirige todo esto a medida que las capacidades de IA se acumulan.

La conversación que necesitas tener

Esto es lo que he aprendido de los CTOs que han superado el panel de control y han pasado al trabajo real: la parte más difícil no es la metodología. Es la conversación.

La conversación en la que le dices a tu equipo directivo: «La forma en que hemos estado trabajando no está mal. Era la adecuada para el mundo para el que estaba diseñada. Pero ese mundo ha cambiado, y necesitamos cambiar con él.»

La conversación en la que le dices a tus responsables de ingeniería que la velocidad ya no es la métrica que importa y que necesitas encontrar nuevas formas de medir el valor.

La conversación en la que le dices a tu mejor Scrum Master que sus habilidades de facilitación son más valiosas que nunca, pero que las ceremonias que está facilitando necesitan evolucionar.

La conversación en la que le dices a tu junta que la «mejora del 40% en productividad» que celebraron el trimestre pasado es real a nivel individual y engañosa a nivel organizativo, y que necesitas invertir en el rediseño de procesos, no solo en licencias de herramientas.

Esas conversaciones requieren pruebas. Las pruebas requieren un piloto. Un piloto requiere a alguien dispuesto a empezar.

La línea de salida

Terminaré con lo mismo que escribí en el epílogo del libro, porque no he encontrado una mejor manera de decirlo:

Un libro en una estantería no cambia nada. Un piloto con un solo equipo, una Intención, una cuarta parte de la medición honesta, eso lo cambia todo. Te da pruebas. Las pruebas te dan convicción. La convicción te da el mandato para escalar.

El libro está disponible en reimaginedontretrofit.com. Si eres CTO, vicepresidente de ingeniería o director de ingeniería intentando entender cómo la IA cambia la forma en que trabajan tus equipos, este es el argumento que haría si tuviéramos tres horas juntos en lugar de en un pasillo de conferencias.

Y si ya has tenido la conversación, si ya has notado la brecha entre el panel de control y la realidad, me gustaría saber cómo fue. La metodología evoluciona con cada organización que la aplica.

Ricardo