El mes pasado, estaba facilitando una sesión de elaboración de Mob con un equipo de desarrollo en una empresa que estaba atravesando su primer ciclo de adopción de IA-DLC. El Product Owner había declarado la intención: una nueva función para su flujo de incorporación de clientes. En cuestión de minutos, la IA generó un conjunto inicial de historias de usuario, criterios de aceptación y una propuesta de descomposición en unidades de trabajo independientes.

Luego pasó algo que ya he visto varias veces, pero que siempre me sorprende.

La habitación quedó en silencio.

No porque la salida fuera incorrecta. En realidad estaba bastante bien. El silencio venía de otro lugar. Un desarrollador senior, alguien con quince años de experiencia, se recostó y dijo: «Entonces… ¿qué hago ahora?»

No era una queja. Era una pregunta genuina. Durante toda su carrera, el valor que aportaba a un equipo se medía en el código que escribía, las arquitecturas que diseñaba desde cero, los problemas que resolvía pensando con intensidad y escribiendo rápido. Y ahora, en cuestión de minutos, AI había producido un primer borrador de trabajo que habría llevado días a su equipo.

Ese momento, la pausa entre el rol antiguo y el nuevo, es donde están la mayoría de las organizaciones ahora mismo. Y muy pocos hablan de ello con sinceridad.

El cambio para el que nadie se preparó

He escrito antes sobre la diferencia entre los asistentes de código de IA y el desarrollo empresarial , y sobre el desafío de la IA responsable en la empresa. Ambos puestos se centraban en procesos y gobernanza. Ninguno abordó lo que ahora creo que es la pregunta más difícil: qué pasa con la gente.

No en el sentido abstracto de «la IA cambiará trabajos». En el sentido concreto, diario. ¿Cómo se siente cuando la IA genera el primer borrador de tu modelo de dominio? ¿Qué significa para un responsable técnico que tres días de planificación se conviertan en tres horas?

Estas preguntas se están manifestando en equipos reales ahora mismo. Y las respuestas determinarán si el desarrollo impulsado por IA tiene éxito o se estanca, porque los procesos no se adoptan solos. La gente sí.

De iniciador a validador

El cambio más fundamental en el desarrollo impulsado por IA es engañosamente sencillo de describir y profundamente difícil de interiorizar.

En el desarrollo tradicional, los humanos inician y la IA asiste. Tú escribes el código; la IA sugiere completaciones. Tú diseñas la arquitectura; la IA completa el estándar estándar. El humano es el conductor. La IA es el pasajero que ofrece las indicaciones.

En los DLC de IA, esa dinámica se invierte. Propone IA. Los humanos validan.

La IA desglosa las intenciones en historias de usuario. La IA genera modelos de dominio. La IA produce código, pruebas e infraestructura. En cada paso, el papel humano es revisar, desafiar, corregir y aprobar.

Esto suena a un ascenso sobre el papel. En la práctica, provoca una crisis de identidad.

Los desarrolladores han pasado años, a veces décadas, construyendo su identidad profesional en torno a la creación. La satisfacción de resolver un problema difícil, el orgullo de un código elegante, el estado de flujo de construir algo desde cero. Cuando la IA asume el trabajo generativo, esa identidad no solo cambia. Se fractura.

He visto tres reacciones comunes:

El escéptico descarta la salida de la IA de forma refleja. «Podría haberlo hecho mejor.» A veces tienen razón. A menudo, protegen su sentido de relevancia en lugar de evaluar la calidad.

El que lo aproba todo sin escrutinio. «Tiene buena pinta, envíalo.» Esta es la reacción más peligrosa, porque elimina la supervisión humana que hace que el desarrollo impulsado por IA sea seguro.

El validador, y este es el papel que debemos cultivar, se involucra de forma crítica. Leen la producción de la IA no como algo que aceptar o rechazar por completo, sino como una propuesta para interrogar. ¿Por qué la IA agrupó estas historias de esta manera? ¿Este modelo de dominio captura las reglas de negocio que discutimos? ¿Es esta decisión arquitectónica el equilibrio adecuado para nuestras limitaciones?

El validador no escribe menos. Piensan más. Y ese pensamiento es donde reside el verdadero valor.

Cuáles son realmente las nuevas habilidades

Si el papel del desarrollador pasa de la creación a la validación, ¿qué habilidades son las que más importan?

Es tentador decir «ingeniería de prompts» y sí, saber cómo interactuar eficazmente con la IA importa. Pero eso es una técnica, no una habilidad. Las capacidades más profundas que definen a un gran desarrollador en la era de la IA son más antiguas y humanas que cualquier plantilla de prompt.

Conocimiento del dominio. La IA puede generar un modelo de dominio, pero no puede saber que la entidad «cliente» de tu empresa se comporta de forma diferente en el contexto de incorporación frente al de facturación debido a una peculiaridad regulatoria de hace tres años. El desarrollador que posee ese conocimiento institucional se vuelve insustituible, no porque pueda programar más rápido, sino porque puede detectar lo que la IA falla.

Juicio arquitectónico. La IA propondrá un patrón de diseño. Incluso podría explicar los compromisos. Pero decidir si la arquitectura orientada a eventos es adecuada para este equipo, este calendario, este entorno de cumplimiento requiere un juicio que proviene de la experiencia, no de los datos de entrenamiento.

Intuición de riesgo. Un desarrollador experimentado lee código generado por IA y siente cuando algo no está bien, no por un error de sintaxis, sino por una suposición sutil que no se cumple en producción. Esa intuición, construida a lo largo de años de depuración, respuesta a incidentes y despliegues nocturnos, es precisamente lo que le falta a la IA.

Comunicación y facilitación. En los rituales colaborativos de AI-DLC, Mob Elaboration y Mob Construction, la capacidad de articular por qué una propuesta de IA es incorrecta, construir consenso en torno a una corrección y mantener alineada una sala de perspectivas diversas se convierte en una habilidad técnica fundamental. No es una habilidad blanda. Una habilidad técnica.

Como escribí en Puente de Estrategia y Ejecución en Liderazgo Tecnológico, la capacidad más valiosa en el liderazgo tecnológico es la transición entre la visión y la realidad. En el desarrollo impulsado por IA, todo desarrollador necesita esa capacidad, no solo el CTO.

La habitación lo cambia todo

Una de las cosas que más me sorprendió de los DLC de IA en la práctica es cuánto cambian los rituales colaborativos, la elaboración y la construcción de mobs, la dinámica del equipo.

En el Agile tradicional, la colaboración ocurre en ceremonias: planificación, monólogo, revisión, retro. Entre ceremonias, los promotores trabajan mayormente solos o en pequeños grupos. El trabajo se distribuye y la coordinación se realiza a través de tickets, pull requests y threads de Slack.

En Mob Elaboration, todo el equipo se sienta en una sala con una pantalla compartida. La IA genera artefactos en tiempo real. El Product Owner, desarrolladores, QA: todos ven el mismo resultado en el mismo momento y reaccionan juntos.

Esto crea una dinámica que no había previsto: la validación colectiva es cualitativamente diferente de la revisión individual.

Cuando un desarrollador revisa solo código generado por IA, aporta su propia perspectiva y sesgos. Podrían pasar por alto alguna norma de negocio que no conozcan. Puede que aprueben un patrón de diseño con el que se sientan cómodos aunque no sea el que mejor les queda.

Cuando una turba valida junta, el Product Owner detecta la brecha de lógica de negocio. El ingeniero de QA detecta el caso límite que falta. El desarrollador orientado a la infraestructura cuestiona el modelo de despliegue. El desarrollador junior hace la pregunta «obvia» que resulta ser la más importante.

La salida de la IA se convierte en un objeto compartido que el equipo moldea juntos. Y como todos estaban en la sala cuando se tomaron las decisiones, no hay ambigüedad sobre por qué algo se construyó de cierta manera. La alineación que los métodos tradicionales intentan lograr mediante documentación y traspasos ocurre de forma natural a través de la experiencia compartida.

He visto sesiones de Mob Elaboration comprimir lo que habrían sido dos semanas de ida y vuelta entre producto, arquitectura y desarrollo en tres horas. No porque la gente trabajara más rápido, sino porque la conversación ocurrió una vez, con todos presentes, con la IA haciendo el trabajo pesado de la generación mientras los humanos se encargaban del juicio.

La incómoda verdad sobre la antigüedad

Aquí hay algo que no se discute lo suficiente: este cambio reorganiza la jerarquía de antigüedad.

En el modelo antiguo, la antigüedad estaba en gran medida correlacionada con la profundidad técnica. El desarrollador senior conocía el código a fondo, podía escribir algoritmos complejos de memoria y había dominado las herramientas. Los desarrolladores junior aspiraban a esa maestría.

En la era de la IA, gran parte de esa profundidad técnica se convierte en mercancía. La IA puede escribir el algoritmo complejo. La IA conoce la API del framework mejor que cualquier persona. La IA no olvida la sintaxis.

Lo que la IA no puede hacer es entender el contexto, navegar la ambigüedad y tomar decisiones bajo incertidumbre. Y esas capacidades no siempre se correlacionan con años de experiencia.

He visto a desarrolladores junior con gran curiosidad por el dominio y buenas habilidades de comunicación convertirse en validadores muy efectivos, a veces incluso más efectivos que desarrolladores senior que tienen dificultades para dejar atrás el rol generativo. También he visto a desarrolladores senior que abrazan el cambio volverse extraordinarios: su amplia experiencia, combinada con la capacidad de dirigir la IA en lugar de competir con ella, les convierte en multiplicadores de fuerza.

La cuestión no es que la antigüedad no importe. Es que la base de la antigüedad está cambiando. La profundidad técnica sigue importando, pero ya no es suficiente. El juicio, la comunicación y la capacidad de operar en un modelo colaborativo humano-IA se están convirtiendo en los factores diferenciadores.

Las organizaciones que no reconozcan este cambio se enfrentarán a un problema silencioso: su mejor talento de la era de la IA no encajará perfectamente en las viejas escaleras profesionales, y sus personas más experimentadas pueden resistirse a la transición no porque no puedan adaptarse, sino porque nadie les dijo cómo es adaptarse.

Lo que deben hacer los líderes

Si lideras una organización de desarrollo, la dimensión de personas en la adopción de la IA no es algo «bueno de tener». Es el cuello de botella.

Puedes comprar las mejores herramientas de IA. Puedes rediseñar tus procesos. Pero si tus desarrolladores no entienden su nuevo rol, o peor aún, si se sienten amenazados por él, la adopción se estancará.

Esto es lo que he visto funcionar:

Nombra el turno explícitamente. No dejes que los desarrolladores lo descubran por sí mismos. Diles: «Tu papel está cambiando de creador de código a validador de sistemas y tomador de decisiones. Eso no es un descenso. Es una elevación.» Dilo claramente, dilo, y dilo a menudo.

Redefine cómo es «bueno». Si tus evaluaciones de rendimiento siguen premiando líneas de código, pull requests fusionadas o historias completadas, estás incentivando el modelo antiguo. Empieza a medir la calidad de la validación, las decisiones tomadas, los riesgos detectados, la alineación alcanzada.

Invierte en habilidades de facilitación. La elaboración de la mafia y la construcción de la mafia no se gestionan solas. El papel de facilitador (mantener la sala enfocada, asegurarse de que la producción de la IA se examina correctamente, gestionar el tiempo y la energía) es una habilidad que requiere entrenamiento y práctica. No des por hecho que tus Scrum Masters pueden hacerlo sin preparación.

Crea espacios seguros para practicar. La primera vez que un desarrollador valida código generado por IA en un entorno de mafia, se sentirá incómodo. Eso es normal. Ejecuta pilotos de bajo riesgo donde el objetivo sea aprender la dinámica, no enviar código de producción. Deja que la gente desarrolle músculo antes de que las apuestas sean altas.

Fíjate en el patrón de sellos de goma. Es el asesino silencioso del desarrollo impulsado por IA. Si tus equipos aprueban la producción de IA sin un escrutinio significativo, no tienes un modelo colaborativo. Tienes desarrollo sin supervisión de IA. Y eso es un desastre de gobernanza y calidad esperando a ocurrir.

El lado humano es el lado duro

Cada transición tecnológica que he vivido, de cliente-servidor a web, de on-premises a nube, de waterfall a Agile, tenía una dimensión técnica y una dimensión humana. La dimensión técnica acaparó la mayor parte de la atención. La dimensión humana determinaba el resultado.

Las herramientas escalan al instante. La identidad no.

El desarrollo impulsado por IA no es diferente. Los modelos seguirán mejorando. Las herramientas seguirán evolucionando. Los procesos madurarán.

Pero la pregunta que separará a las organizaciones que prosperan de las que tropiezan no es: «¿Qué tan buena es vuestra IA?» Es «¿Qué tan bien preparaste a tu gente para una forma de trabajar fundamentalmente diferente?»

El papel del promotor no desaparece. Se está forjando de nuevo. Quienes la abracen, que aprendan a pensar en términos de validación, juicio e inteligencia colaborativa, serán más valiosos que nunca.

La cuestión es si tu organización les está ayudando a llegar a ese punto o si les está dejando resolverlo solos en una habitación tranquila, preguntándose qué se supone que deben hacer ahora.

La IA seguirá proponiendo. La cuestión es si tus desarrolladores están preparados para decidir.

Ricardo