He estado desarrollando software desde que tenía catorce años, cuando vendí mi primer producto de software. Casi tres décadas después, tras ascender en roles de consultoría y arquitectura, cofundar empresas y, finalmente, convertirse en CTO responsable de la estrategia de entrega de cientos de proyectos en la nube en toda América Latina, un patrón se ha mantenido constante. Cada gran cambio de plataforma que he vivido siguió el mismo arco: surgió una nueva capacidad, las organizaciones la incorporaron a sus procesos existentes, y las que prosperaron fueron las que finalmente dejaron de cerrar y empezaron a rediseñar.

El desarrollo de software impulsado por IA es el último cambio. Y es el más rápido.

Durante el último año, he estado escribiendo sobre este cambio en este blog. Sobre la desconexión entre los asistentes de código con IA y el desarrollo de software empresarial. Sobre por qué la IA necesita un nuevo ciclo de desarrollo. Sobre el papel evolutivo del desarrollador y por qué la IA falla en bases de código existentes. Cada publicación exploraba una pieza del rompecabezas. Pero las piezas no son suficientes. El argumento necesitaba una forma completa y conectada.

Así que escribí un libro: Reimagine, Don’t Retrofit: A Leadership Guide to AI-Driven Software Development ya está disponible en Leanpub y Amazon Books.

Por qué un libro y por qué ahora

Las entradas de blog son buenas para provocar reflexión. No sirven para construir un argumento completo. Y el argumento que necesitaba hacer requería más que una serie de observaciones independientes.

El argumento es este: 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.

Eso no es una entrada de blog. Eso es un libro.

También lo escribí porque seguía teniendo la misma conversación. Con CTOs que veían a sus equipos producir más código que nunca pero enviar menos valor. Con jefes de ingeniería cuyos gráficos de velocidad de sprint se veían geniales mientras sus fallos de integración se multiplicaban. Con desarrolladores que se sentían a la vez más productivos y más desconectados de la calidad de lo que estaban construyendo. El patrón estaba en todas partes, y la explicación siempre era la misma: estaban pasando IA por procesos diseñados para un mundo donde la IA no existía.

Cada una de esas conversaciones merecía más de una entrada de 2.000 palabras. Merecían un diagnóstico estructurado, un conjunto de principios, una metodología y un camino práctico a seguir. Eso es lo que ofrece el libro.

¿Qué hay dentro?

El libro está organizado en torno a una progresión que refleja cómo he visto a las organizaciones pasar de la confusión a la claridad.

Parte I: El diagnóstico. Los primeros cuatro capítulos explican lo que realmente ocurre cuando las organizaciones adoptan asistentes de codificación con IA sin replantearse sus procesos. La paradoja de la productividad, donde los equipos producen más código pero aportan menos valor. La trampa del «caballo más rápido» de adaptar la IA a ceremonias ágiles diseñadas solo para equipos humanos. La brecha de gobernanza que se abre cuando el código generado por IA evita los controles que mantenían seguro el código escrito por humanos. Y el fenómeno del vibe coding, donde la velocidad sin estructura crea deuda técnica a un ritmo que ninguna organización puede sostener.

Si has leído mis recientes entradas en el blog, algunas de estas cosas te resultarán familiares. Pero el libro va más allá. La compañía de seguros del blog se convierte en un caso de estudio de varios capítulos. La operadora, la empresa SaaS sanitaria, la firma de servicios financieros: sus historias se entrelazan a lo largo de todo el libro, mostrando cómo los mismos patrones se repiten de forma diferente entre sectores pero conducen a los mismos problemas estructurales.

Parte II: Los principios y la metodología. Este es el núcleo del libro. Cinco capítulos que presentan el Ciclo de Vida del Desarrollo Impulsado por IA: una metodología creada por Raja SP y su equipo en AWS, que he traducido a la práctica empresarial y ampliado a través de mi propia experiencia aplicando y evolucionando estas ideas a través de múltiples proyectos.

Existen los diez principios que fundamentan la metodología. La nueva arquitectura de trabajo se basaba en Intenciones, Unidades y Pernos en lugar de carreras y puntos de la historia. La «conversación invertida» donde la IA propone y los humanos evalúan, invirtiendo la dinámica tradicional. La realidad de terreno abandonado de aplicar estas ideas a bases de código existentes, no solo a proyectos nuevos. Y la redefinición del papel del desarrollador, de productor de código a proveedor de juicios.

Parte III: Hacerlo real. Los últimos cuatro capítulos abordan lo que considero la parte más difícil: pasar de la comprensión a la práctica. Cómo la gobernanza se convierte en un facilitador en lugar de un obstáculo cuando se integra en el flujo en lugar de añadirse después. Cómo dirigir un piloto que genere evidencia, no solo entusiasmo. Cómo medir qué es lo que realmente importa cuando las métricas antiguas pierden su significado. Y hacia dónde se dirige todo esto a medida que las capacidades de IA continúan aumentando.

El libro también incluye nueve apéndices con herramientas prácticas: un glosario, una referencia de principios de una página, una hoja de evaluación de preparación, un marco de métricas, un marco de evaluación de herramientas y orientación específica para CTOs, responsables de ingeniería, arquitectos, desarrolladores, Scrum Masters y responsables de QA.

Para quién es este libro

Escribí esto para el líder tecnológico que sabe que algo necesita cambiar pero no está seguro de qué.

Si eres CTO, vicepresidente de ingeniería o director de ingeniería y ves cómo tus equipos adoptan herramientas de IA mientras tus procesos permanecen iguales, este libro te ofrece un diagnóstico, un marco y un manual de jugadas. Si eres un responsable de ingeniería atrapado entre las expectativas de los directivos y la realidad de tu equipo, este libro te da un lenguaje para la conversación que necesitas tener. Si eres desarrollador y te preguntas cuál es tu papel cuando la IA escribe el primer borrador, el Capítulo 9 es para ti.

Esto no es un tutorial. No es una guía de herramientas. Es un argumento de un profesional, basado en la experiencia de campo, que la forma en que construimos software debe evolucionar tan fundamentalmente como las herramientas que usamos para hacerlo.

La parte personal

Seré sincero: escribir un libro mientras dirigía una práctica de CTO en varios países y zonas horarias fue más difícil de lo que esperaba. Hubo semanas en las que el manuscrito no se movió. Hubo capítulos que reescribí tres veces porque el argumento no era lo suficientemente agudo. Hubo momentos en los que me pregunté si el mundo necesitaba otro libro sobre IA y desarrollo de software.

Lo que me mantuvo en pie fue la convicción de que la conversación que la mayoría de las organizaciones tienen sobre la IA es la conversación equivocada. Preguntan «¿qué herramienta de IA deberíamos usar?» cuando deberían preguntarse «¿cómo cambia la IA la forma en que trabajamos?» Están midiendo líneas de código generadas cuando deberían medir el valor entregado. Están optimizando la productividad individual cuando el cuello de botella es la coordinación sistémica.

Esos no son problemas de herramientas. Son problemas de liderazgo. Y los problemas de liderazgo merecen un trato a nivel de liderazgo.

Lo que viene después

El libro ya está disponible en Leanpub y AmazonBooks. Elegí Leanpub porque se alinea con mi forma de pensar sobre el contenido: publicar, recibir feedback, iterar. Si lo lees y tienes opiniones, quiero escucharlas.

En las próximas semanas, escribiré más sobre temas específicos del libro, profundizando en temas que merecen su propia exploración. También incorporaré las ideas del libro en talleres y charlas, así que si te interesa llevar esta conversación a tu organización o evento, contacta con nosotros.

Pero por ahora, cerraré con lo mismo que escribí en el epílogo:

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.

No esperes al momento perfecto. Elige un equipo. Elige una intención. Ejecuta el piloto. Mide lo que ocurre. Dejemos que los resultados hagan el argumento.

Ricardo