Hace unos meses, asistí a una retrospectiva con un equipo de desarrollo de una empresa de servicios financieros de tamaño medio. Habían adoptado asistentes de programación con IA seis meses antes. El ambiente era… complicado.

Por un lado, los desarrolladores individuales escribían código más rápido que nunca. Por otro, la métrica de velocidad de sprint del equipo había perdido sentido. Algunas historias que antes tardaban días se hacían en horas. Otros, los que requerían juicio arquitectónico, pensamiento de integración o alineación de cumplimiento, seguían tardando igual. Los puntos de la historia habían perdido su calibración. Planificar el sprint se sentía como teatro. El Scrum Master, medio en broma, preguntó: «¿Seguimos haciendo esto porque funciona, o porque no sabemos qué más hacer?»

Esa pregunta no para de resonar en mi cabeza desde entonces.

Porque la respuesta honesta, para la mayoría de los equipos empresariales con los que trabajo, es la segunda. Estamos ejecutando la IA a través de procesos diseñados para un mundo donde la IA no existiera. Y las grietas se ven por todas partes.

El problema del caballo más rápido

En publicaciones anteriores, he escrito sobre la diferencia entre los asistentes de código de IA y el desarrollo de software empresarial , y sobre la brecha de gobernanza que provoca que las iniciativas de IA empresarial fracasen a gran escala. Ambas publicaciones diagnosticaron la misma tensión subyacente: las organizaciones están incorporando IA a procesos que nunca fueron diseñados para ella.

Pero ahora quiero ir más allá. El problema no es solo la gobernanza o la alineación. El problema es el propio proceso.

Scrum, Kanban, SAFe: estos frameworks fueron diseñados para equipos exclusivamente humanos que trabajaban en ciclos de una semana o un mes. Asumían que la planificación lleva tiempo, que la estimación es necesaria porque la ejecución es impredecible y que las transferencias entre roles son inevitables. Las reuniones diarias de pie existen porque la coordinación es difícil. Las retrospectivas existen porque los bucles de retroalimentación son lentos. Los puntos de la historia existen porque la brecha entre tareas simples y complejas es lo suficientemente grande como para importar.

La IA derrumba todas esas suposiciones. Cuando la IA puede descomponer y elaborar los requisitos en minutos, la planificación ya no necesita una ceremonia dedicada. Cuando genera código, pruebas e infraestructura en cuestión de horas, la brecha entre una tarea simple y una compleja se reduce hasta el punto de que los puntos de la historia pierden su calibración. Cuando la IA mantiene el contexto a lo largo de toda la pila, las transferencias entre roles especializados se convierten en fricción en lugar de necesidad. Y cuando se puede generar retroalimentación continuamente mediante validación impulsada por IA, esperar a que una retrospectiva revele qué salió mal es simplemente esperar.

Cuando la IA puede descomponer requisitos, generar modelos de dominio, producir código y crear pruebas, todo en cuestión de horas, ¿qué ocurre con un sprint de dos semanas? Cuando la frontera entre una «historia de 3 puntos» y una «historia de 8 puntos» se difumina porque la IA maneja la complejidad mecánica, ¿qué mide siquiera la velocidad?

La respuesta a la que han llegado la mayoría de las organizaciones es: mantener el proceso, añadir la IA como herramienta. Retrofit.

Creo que esa no es la respuesta correcta. Es el caballo más rápido.

Por qué falla la adaptación

He visto el patrón de retrofitting repetirse decenas de veces. Normalmente sigue un arco predecible.

Fase 1: Emoción. Los equipos adoptan asistentes de codificación con IA. Picos de salida individuales. Todos celebran.

Fase 2: Fricción. El proceso actual no puede absorber la velocidad. Las revisiones de código se convierten en cuellos de botella. Las ceremonias de sprint parecen desconectadas de la realidad. Las puertas de calidad diseñadas para entregas a ritmo humano no pueden seguir el ritmo.

Fase 3: Soluciones alternativas. Los equipos empiezan a doblar el proceso. Algunos saltan las reseñas. Otros inflan los puntos de la historia para que la velocidad parezca estable. El uso de la IA de las sombras se extiende; Los desarrolladores usan herramientas que no están autorizadas porque el proceso oficial es demasiado lento.

Fase 4: Desilusión. El liderazgo ve resultados inconsistentes. Surgen problemas de calidad. Los equipos de gobernanza dan las alarmas. La organización o bien reduce la adopción de la IA o redobla los controles que ralentizan aún más todo.

La causa raíz no es la IA. Es el recipiente en el que intentamos verterlo.

Los métodos tradicionales de SDLC se basaban en una limitación fundamental: el ancho de banda cognitivo humano. Ceremonias de planificación, rituales de estimación, especializaciones de roles: todo esto existe porque los humanos solo pueden contener cierta cantidad de contexto, procesar cierta cantidad de información y coordinarse a través de ciertos límites a la vez.

La IA no tiene esas limitaciones. Pero cuando forzamos a la IA a un proceso diseñado en torno a ellas, obtenemos lo peor de ambos mundos: la sobrecarga de ceremonias de la era humana sin ninguno de los beneficios de la velocidad de la era de la IA.

Cómo es reimaginar

Si aceptamos que la adaptación es un callejón sin salida, la pregunta es: ¿cómo sería un ciclo de vida de desarrollo si lo diseñáramos desde cero para la era de la IA?

He estado trabajando y estudiando una metodología llamada Ciclo de Vida del Desarrollo Impulsado por IA (AI-DLC), y su tesis central resuena profundamente con lo que he observado en el campo. En lugar de parchear los frameworks existentes, el DLC de IA parte de principios básicos y pregunta: dado lo que la IA puede hacer hoy, ¿cuál es el proceso mínimo viable que mantenga la calidad, la gobernanza y la supervisión humana mientras maximiza el flujo?

El cambio central es este: el DLC de IA traslada la unidad de coordinación del esfuerzo limitado en tiempo a un flujo impulsado por la intención.

En los métodos tradicionales, todo orbita alrededor de la caja temporal. Un sprint de dos semanas define cuándo planificas, a qué te comprometes y cómo mides el progreso. La caja temporal es el latido. Pero cuando la IA comprime la ejecución de semanas a horas, ese latido se convierte en una restricción, no en una cadencia. Acabas esperando a que termine el sprint para poder empezar lo siguiente, o metiendo la producción generada por IA en ceremonias diseñadas para un ritmo más lento.

Las organizaciones de los DLC de IA funcionan de forma diferente. Empieza con Intenciones, declaraciones de propósito de alto nivel que capturan lo que hay que lograr, ya sea un objetivo de negocio, una característica o un resultado técnico. La IA descompone esas Intenciones en Unidades: elementos de trabajo cohesionados y autosuficientes diseñados para ofrecer un valor medible de forma independiente. Y las Unidades se ejecutan mediante Bolts, ciclos de iteración rápidos e intensos medidos en horas o días, no en semanas.

La diferencia no es solo vocabulario. Es un principio organizativo fundamentalmente diferente. El trabajo no fluye porque empezó una caja de tiempo. El trabajo fluye porque existe una intención, la IA la ha descompuesto en piezas accionables, y el equipo valida y guía a medida que esas piezas avanzan en el diseño, la implementación y las pruebas de forma continua, no en lotes.

Esto cambia hacia dónde va la energía humana. En lugar de pasar horas en reuniones de planificación debatiendo el tamaño de las historias y la capacidad de sprint, los equipos se centran en lo que realmente importa: ¿Es la descomposición correcta? ¿Están limpios los límites entre unidades? ¿Se mantiene la intención comercial? ¿Se cumplen los criterios de calidad y cumplimiento?

Por qué la estimación pierde su propósito

Quizá la implicación más provocadora del flujo impulsado por la intención: la estimación tradicional se vuelve en gran medida irrelevante.

Los puntos de la historia existen porque la diferencia entre tareas de distinta complejidad es lo suficientemente significativa como para afectar a la planificación. Pero cuando la IA maneja la complejidad mecánica (generar código, escribir pruebas, crear infraestructura), el trabajo humano restante es principalmente juicio: revisar, validar, decidir. La IA puede generar diez implementaciones en el tiempo que antes tardaba en escribir una, pero un desarrollador no puede evaluar diez compensaciones arquitectónicas diez veces más rápido. El cuello de botella pasa de la producción al juicio, y ese cambio es lo que hace que la estimación basada en el esfuerzo tenga sentido.

El DLC de IA no elimina la medición. Desplaza el enfoque de la estimación del esfuerzo a la validación de valor. En lugar de preguntar «¿Cuántos puntos tiene esta historia?», los equipos preguntan: «¿Esta unidad ofrece el valor empresarial previsto? ¿Cumple con los criterios de calidad y cumplimiento?»

Esa es una pregunta fundamentalmente diferente y más útil.

El papel humano no se reduce. Se afila.

Una preocupación que escucho con frecuencia: «Si la IA es la que planifica, descompone y programa, ¿qué queda para los desarrolladores?»

Todo lo que importa.

AI-DLC se basa en un principio que me resulta convincente: invertir la dirección de la conversación. En lugar de que los humanos inicien tareas y la IA ayude, la IA propone planes, genera artefactos y recomienda enfoques. Los humanos validan, corrigen y deciden.

Piénsalo como un software de navegación. Tú pones el destino. El sistema propone la ruta, advierte sobre el tráfico y sugiere alternativas. Pero sigues conduciendo. Aún decides si tomar la autopista o la carretera panorámica. Sigues parando cuando algo no te cuadra.

En los DLC de IA, los desarrolladores se convierten en pensadores de sistemas, expertos en el dominio y guardianes de la calidad. Se centran en las preguntas que la IA no puede responder: ¿Este diseño se alinea con nuestra realidad empresarial? ¿Esta arquitectura gestiona los casos límite que realmente enfrentan nuestros clientes? ¿Cumple este enfoque con nuestras obligaciones regulatorias?

Como escribí en Puentes de Estrategia y Ejecución en el Liderazgo Tecnológico, la habilidad más valiosa en el liderazgo tecnológico es la traducción entre la visión y la realidad. Los DLC de IA hacen que esa habilidad sea el centro del papel del desarrollador, no una actividad secundaria.

Familiaridad como puente, no como jaula

Una cosa que aprecio del enfoque de DLC con IA es que no exige una ruptura total con todo lo que los equipos conocen. Preserva conceptos familiares (historias de usuario, criterios de aceptación, registros de riesgo) porque estos artefactos cumplen un propósito genuino: alinean la comprensión humana y la de la IA sobre lo que hay que construir.

Lo que cambia es la cadencia, el flujo y la división del trabajo.

Las historias de usuario siguen existiendo, pero se elaboran de forma colaborativa con la IA en cuestión de horas, no se refinan a lo largo de varias sesiones de planificación de sprints. El diseño sigue ocurriendo, pero la IA genera los modelos iniciales de dominio y los desarrolladores los validan en lugar de construir desde cero. Las pruebas siguen siendo importantes, pero la IA genera y ejecuta conjuntos de pruebas mientras los humanos se centran en la cobertura de escenarios y el pensamiento de casos límite.

La terminología cambia intencionadamente (Bolts en lugar de Sprints, Intents en lugar de Épicas) no para ser diferente por sí mismos, sino para señalar que la dinámica subyacente ha cambiado. Cuando llamas a algo Sprint, los equipos importan inconscientemente todas las suposiciones que conlleva: caja de tiempo de dos semanas, planificación del póker, seguimiento de velocidad. Renombrar rompe ese modelo mental y crea espacio para nuevos hábitos.

El verdadero riesgo: No hacer nada

Algunos líderes con los que hablo reconocen la desconexión pero dudan en actuar. «Nuestro proceso actual funciona bastante bien», dicen. «Nos adaptaremos cuando sea necesario.»

Entiendo la precaución. Pero he visto cómo se presenta «lo suficientemente bien» en la práctica: equipos donde la adopción de la IA está fragmentada, donde la gobernanza es reactiva, donde la brecha entre lo que la IA permite y lo que permite el proceso crece cada trimestre.

Y esto es lo que hace que esto sea diferente de los cambios tecnológicos anteriores: la aceleración por IA no es un ciclo que se estabilice. Las capacidades del modelo se están acumulando. Lo que hoy parece experimental se sentirá primitivo dentro de dieciocho meses. Las organizaciones que esperan a que la IA «se calme» antes de rediseñar sus procesos están diseñando para un momento que ya ha pasado. El pensamiento estático sobre una capacidad dinámica es en sí mismo una forma de deuda técnica.

Las organizaciones que prosperarán en la era de la IA no son las que disponen de las mejores herramientas de IA. Son ellos quienes rediseñan sus procesos para adaptarse a lo que esas herramientas hacen posible, y siguen rediseñando a medida que evolucionan las capacidades. Ya están surgiendo nuevas plataformas que ofrecen observabilidad y gobernanza específicamente para el código generado por agentes de IA, categorías que no existían hace un año. Así como Agile no tuvo éxito porque tuviera mejor software de gestión de proyectos (tuvo éxito porque reinventó cómo trabajan los equipos), el siguiente salto requiere reinventar el propio ciclo de vida del desarrollo.

Hacer una adaptación es cómodo. Es incremental. No requiere que nadie replantee su papel o sus rituales.

Pero la comodidad no es una estrategia.

Por dónde empezar

Si eres CTO, vicepresidente de ingeniería o líder técnico leyendo esto, no necesitas renovarlo todo mañana. Pero sí necesitas empezar a hacerte otras preguntas:

• Para cada ceremonia que organiza tu equipo, ¿puedes articular la limitación que resuelve en un entorno acelerado por IA? Si la planificación de sprints parece más una carga aérea que una alineación, eso es una señal.
• ¿Tus métricas siguen siendo relevantes? Si la velocidad se ha convertido en un número personalizado que no se correlaciona con el valor empresarial, es hora de replantearte lo que mides.
• ¿Dónde es más valioso el juicio humano? Identifica las decisiones que solo los humanos pueden tomar (compensaciones arquitectónicas, alineación de cumplimiento, priorización del negocio) y diseña tu proceso en torno a esos momentos.
• ¿Sabes manejar un piloto? Elige un proyecto pequeño y de terreno verde. Prueba a trabajar en ciclos rápidos con descomposición impulsada por IA y validación humana. Mide el tiempo de ciclo, la calidad y la satisfacción del equipo. Compáralo honestamente con tu enfoque actual.

El objetivo no es adoptar una metodología específica de la noche a la mañana. El objetivo es dejar de asumir que los procesos diseñados para un mundo previo a la IA te llevarán a través de la era de la IA sin cambios fundamentales.

El automóvil, no el caballo más rápido

Hay una cita que a menudo se atribuye a Henry Ford: «Si hubiera preguntado a la gente qué querían, habrían dicho caballos más rápidos.»

Que Ford realmente lo haya dicho no importa. La visión sí.

Cuando cogemos Scrum y añadimos asistentes de codificación de IA, estamos construyendo un caballo más rápido. Parece impresionante. Se mueve más rápido. Pero sigue estando limitada por la misma arquitectura fundamental: las mismas ceremonias, los mismos roles, las mismas suposiciones sobre cómo fluye el trabajo de la idea a la producción.

El automóvil no era un caballo mejor. Era un paradigma diferente, basado en principios distintos para una época distinta.

La IA no está pidiendo un sprint más rápido. Está exigiendo una máquina completamente nueva.

Las organizaciones que lo reconozcan pronto, que tengan el valor de reinventar en lugar de adaptar, definirán la próxima era de la ingeniería de software.

El resto se quedará preguntándose por qué sus caballos más rápidos no pueden seguir el ritmo.

Ricardo