Hace unos meses fue muy popular el debate (por no llamarlo de otra manera) de si Agile está muerto. Y, honestamente, siempre me ha parecido un tema irrelevante en el que no pienso perder mi tiempo. Pero sí reconozco que detrás de esto hay un síntoma: el debate —más allá del morbo que produce en los detractores de Agile sentir que “tenían razón”— evidencia una realidad que vale la pena analizar. No es tanto si Agile murió o no, sino que algo cambió. Y es precisamente de esto de lo que quiero hablar en este artículo.
Agile nació como respuesta a problemas muy específicos de la ingeniería de software de los 90: entregas que se demoraban una eternidad, requisitos que envejecían antes de salir, handoffs interminables y un negocio que solo veía valor al final del proyecto. Para ese tipo de problemas, Agile funcionó… y si hoy alguien sigue teniendo esos mismos problemas, Agile le seguirá funcionando.
Lo que cambió fue el mundo alrededor. Estamos en 2026. Si como humanidad siguiéramos atrapados en los problemas de 1990, algo estaría muy mal. En estos 30 años pasamos por todo tipo de revoluciones: masificación de internet, computación personal, smartphones, apps móviles, wearables, IoT, cloud computing, blockchain, NFTs, machine learning… hasta una pandemia tuvimos en el medio. Y ahora estamos viviendo la que promete ser una de las disrupciones más grandes: modelos generativos de lenguaje y, por supuesto, agentes de IA. La ingeniería de software cambió —y con ella cambió el tipo de problemas que hay que resolver.
Entonces, para mí, la conversación no es “Agile sirve o no sirve”. La conversación es: qué desafíos tenemos hoy para construir productos digitales, y con qué los vamos a sortear.
Si hacemos un viaje rápido en el tiempo, se ve bastante claro cómo hemos ido llegando a este punto.
La era del “Scrum Team” clásico
En el Pleistoceno (según los arqueólogos), durante varios años existió un estándar de equipo de desarrollo de producto: Product Owner, Scrum Master y developers. A eso le llamaban Scrum Team o, también, el mal llamado squad (algunos incluso le decían “células”). A nivel organizacional emergió el término “tribus” para referirse a agrupaciones de squads.
Luego vino un momento en el que construir productos digitales se volvió tan complejo que nos fuimos al otro extremo: equipos hiperfragmentados.
UX Writer, UI Designer, UX Researcher, frontend Angular, frontend React, mobile developer, backend Spring Boot, DBA, DevOps, tester, business analyst… y así. Tenía sentido: cada especialidad existía porque había tal nivel de complejidad que ameritaba asumir el costo de esos roles.
En esa época, el Scrum Master tenía una razón de ser muy concreta: ayudar a que un equipo entregara con ritmo, remover impedimentos y crear un sistema de mejora continua. Cuando la productividad era un problema real, ese rol brillaba. El Scrum Master aportaba valor impulsando la cohesión de equipos hiperfragmentados para que fueran más allá de sus silos y se convirtieran en equipos multifuncionales, donde un hiperespecialista evolucionara hacia un tipo de profesional capaz de aportar al equipo en roles más allá de su hiperespecialidad.
Llega la era del “full stack”
Después empezó a pasar algo interesante: apareció con fuerza el término full stack.
Antes, hablar de un “developer full stack” (un desarrollador lo suficientemente competente para trabajar en frontend y backend) era casi hablar de un unicornio. Pero con el tiempo fueron apareciendo herramientas cada vez mejores —y ahora, con IA— que facilitaron la aparición de estos perfiles sin necesidad de ser el máximo experto en cada una de estas disciplinas. Empezó a bastar con conocer los fundamentos del desarrollo front y back, mientras que la necesidad de profundidad en temas específicos se cubría con estas herramientas emergentes.
Y mientras aparecían los primeros especímenes de developers full stack, sucedieron otros cambios que redujeron aún más la multiespecialidad dentro de los squads: muchos equipos empezaron a prescindir del rol de tester. Aclaro: prescindir del cargo, no de la responsabilidad. Porque testear es igual o más importante que antes… solo que una parte relevante de ese trabajo se absorbió con tecnología (automatización, pipelines, testing asistido, etc.). Algo similar empezó a ocurrir con otras especialidades: de repente, el UX designer podía cubrir también necesidades de UX writing, UI design y research, con mucho más alcance que antes.
Entonces, los developers, en lugar de invertir su tiempo en profundizar su especialidad al extremo, empezaron a dedicarse a adquirir habilidades adyacentes y aparecieron profesionales en forma de Pi (π) o en forma de “M”. Esto significa que los profesionales ahora podían representar múltiples especialidades con la calidad necesaria para generar valor.
Este tipo de evolución profesional era el estado deseado que promovía el Scrum Master cuando buscaba productividad y el desarrollo de equipos multifuncionales. Pero, a medida que se producía esta evolución, el aporte requerido del Scrum Master fue disminuyendo.
Si hoy en día eres un hiperespecialista, déjame decirte que eres un espécimen en vía de extinción. Un humano nunca va a competir como especialista contra una máquina. El otro día escuchaba a Guillermo Rauch decir algo que me hizo clic: si eres buenísimo calculando números en la cabeza… igual vas a perder contra una calculadora [1]. Y esa analogía aplica perfecto para entender lo que ha pasado con los hiperespecialistas.
Aparece el meteorito LLM y la IA empieza a borrar fronteras de verdad
Con la aparición de los modelos generativos de lenguaje y la IA agéntica, estamos presenciando un punto de inflexión en el mundo del desarrollo de productos. Las fronteras tradicionales entre roles como Product Owner, diseñador y desarrollador se están desdibujando. Varias fuerzas convergen para impulsar este cambio:
- Automatización e IA generativa: La adopción masiva de IA está redefiniendo el trabajo. McKinsey estima que al menos 14% de los trabajadores a nivel mundial podrían verse obligados a cambiar de carrera para 2030 debido a la digitalización y la IA [2]. Incluso, uno de cada cuatro CEO a nivel global anticipa recortes de personal del 5% o más en el corto plazo por el impacto de la IA generativa [3]. Esto refleja la disrupción que la automatización está causando en empleos altamente calificados, incluidos los tecnológicos. ¿Un dato revelador? En 2025, las ofertas de trabajo para desarrolladores de software cayeron un 34% respecto a 2020, aun cuando las ofertas totales crecieron un 10% en ese período [4]. La razón de fondo es clara: herramientas como los modelos de lenguaje (LLMs) han disparado la productividad, permitiendo que equipos más pequeños logren mucho más. Grandes empresas como Salesforce reportaron incrementos de productividad cercanos al 30% en ingeniería gracias a IA, al punto de congelar nuevas contrataciones de desarrolladores sin frenar su capacidad de entrega [5]. La ingeniería de software ya no parece el cuello de botella de antes.
- Ciclos de desarrollo acelerados: Con metodologías ágiles aprendimos a entregar valor continuamente. Ahora, con plataformas low-code/no-code y asistentes de código impulsados por IA, el tiempo desde la idea hasta el prototipo funcional se redujo dramáticamente. Hoy un desarrollador puede testear una idea sin necesitar de otras especialidades; un product manager puede generar un prototipo con lenguaje natural; o un emprendedor sin equipo técnico puede lanzar un MVP por su cuenta. La iteración rápida deja de ser ventaja competitiva para convertirse en requisito de supervivencia. La agilidad es un commodity; si una empresa no es ágil en esta era, seguramente ya desapareció. Habilitar agilidad ya no es “una necesidad” en estos tiempos: por definición, quien esté vivo después de todas las revoluciones que hemos vivido, ya es ágil.
- Convergencia de roles: Este contexto está colapsando categorías laborales antes bien delimitadas. El viejo modelo en silos —“el Product Owner escribe requisitos → el ingeniero construye → el analista evalúa”— se queda corto frente a la velocidad actual. Las organizaciones más innovadoras empiezan a valorar perfiles versátiles capaces de saltar entre funciones. Microsoft, por ejemplo, describe la aparición de un “Full-Stack Product Builder”: individuos que integran gestión de producto, ingeniería y ciencia de datos en una sola persona, apalancada por IA. Si antes la especialización extrema era la norma, hoy la capacidad de operar en la intersección es lo que marca la diferencia.
Dado lo anterior, la productividad ya dejó de ser un problema en los equipos de producto de 2026 con la misma magnitud que sí lo era en la década de los 90. Por ende, las responsabilidades que emergieron para contribuir a resolver esos problemas —me refiero al Scrum Master, Agile Coach, facilitadores ágiles y demás especies— ya no son tan necesarias (aunque soy fiel creyente de que un buen Scrum Master o Agile Coach siempre puede aportar valor; el problema es encontrar uno bueno entre tanto humo).
Por otro lado, es evidente que la tecnología ha democratizado muchas herramientas de creación. Las barreras técnicas están bajando, pero eso no significa que cualquiera pueda construir un buen producto sin más. Al contrario: cuanto más accesible es la ejecución, más crucial se vuelve decidir qué construir, para quién y por qué. Esa fineza estratégica —el criterio de producto— no desaparece con la IA; se vuelve más urgente.
De hecho, ya vemos equipos donde la ejecución dejó de ser el cuello de botella. He visto casos en los que el product backlog se vuelve el principal stopper: no porque falten manos para construir, sino porque no está suficientemente claro qué construir o por qué.
Y, en ese contexto, las fronteras entre el AI Engineer (o AI Software Engineer) y el Product Owner / Product Manager se están volviendo difusas.
Porque el AI Engineer ya no solo “recibe requerimientos”: puede aprender de producto apoyado en IA. Y el Product Owner / Product Manager ya no solo “define y prioriza”: puede entrar a construir gracias a herramientas de vibe coding. Experimentar y validar hipótesis nunca había sido tan fácil: en minutos puedes tener un MVP funcional.
Esto también vuelve incómodo algo que antes era intocable: la “escritura tradicional” de historias de usuario. En muchos casos, redactar una HU detallada empieza a sentirse igual de costoso (o más) que pasar un prompt bien pensado a una herramienta y mostrar un prototipo real. Las HU nacieron para invitar a la conversación entre Product Owner y developer… pero si un feature lo puede trabajar casi completo una sola persona, la conversación cambia de forma.
Y ahí es donde aparece el perfil que yo veo como el rol aspiracional del futuro: el Product Builder.
Para mí, un Product Builder es alguien que:
- entiende negocio y necesidades del cliente,
- puede gestionar expectativas y comunicarse con stakeholders,
- pero además tiene capacidad real de convertir esa necesidad en producto,
- apoyándose en agentes de IA para ejecutar con velocidad y una calidad razonable.
No es “un Product Manager que aprendió a codear un poquito”. Tampoco es “un developer que ahora opina de producto”. Es alguien que opera en la intersección: piensa y construye, valida con realidad y no necesita un ejército para mover una idea desde el problema hasta el usuario.
Ahora, esto no significa “si antes un squad estaba conformado por 10 personas, entonces ahora van a despedir 9”. Eso depende de la estrategia, la industria, la cultura, la regulación… de mil cosas.
Yo lo veo con dos lentes posibles:
- Lente pesimista: la IA desplaza. Se recortan roles, se “compacta” la estructura y el mercado se vuelve más duro para quien se quede solo con una especialidad muy estrecha.
- Lente optimista (que es el que elijo creer): la capacidad de producción aumenta brutalmente. En vez de un squad entregando X, podrías tener un equipo de Product Builders entregando 5X o 10X… no porque sean superhumanos, sino porque la ejecución técnica se apalanca en IA y la restricción se mueve hacia la claridad de producto, la estrategia y el criterio.
Hagamos una pausa: el mundo no es lineal. “10X” puede sonar exagerado —y probablemente lo sea en muchos contextos—. Pero que la productividad puede crecer de forma no lineal… eso ya es difícil de negar.
Y si hoy un squad empieza a parecerse a la capacidad de un Product Builder, entonces lo que antes llamábamos “tribu” podría comprimirse también. Incluso podríamos ver empresas exitosas cada vez más pequeñas, o hasta negocios unipersonales con impacto real. No porque sea fácil, sino porque la palanca tecnológica cambió el juego.
El futuro es de los Product Builders
Si algo nos está enseñando esta nueva era no es que “Agile murió”, sino que los problemas y necesidades de los equipos de producto son diferentes a los de hace 30 años: antes optimizábamos por coordinación y previsibilidad; hoy debemos optimizar por criterio, aprendizaje y capacidad de convertir intención en producto sin fricción. La IA está abaratando la ejecución, pero no está abaratando el juicio: sigue siendo difícil escoger el problema correcto, entender al usuario, diseñar una propuesta de valor coherente y sostenerla en el tiempo. Por eso el Product Builder no es un buzzword más, sino una respuesta emergente a un mundo donde construir es cada vez más fácil y, precisamente por eso, decidir bien es cada vez más importante. La pregunta que deja este cambio no es si tu organización “es ágil”, sino si está formando —o atrayendo— personas capaces de pensar y construir producto de valor. Porque, al final, cuando la velocidad deja de ser ventaja y se vuelve estándar, lo que realmente diferencia no es cuánto produces, sino qué tan bien entiendes lo que vale la pena producir.
Referencias
[1] Platzi. (2025, 13 de noviembre). Así serán los programadores del futuro, según el CEO de Vercel [Video]. YouTube. https://www.youtube.com/watch?v=ZpM9XotPOBk
[2] Illanes, P., Lund, S., Mourshed, M., Rutherford, S., & Tyreman, M. (2018, January 22). Retraining and reskilling workers in the age of automation. McKinsey Global Institute. https://www.mckinsey.com/featured-insights/future-of-work/retraining-and-reskilling-workers-in-the-age-of-automation
[3] Torres, R. (2024, January 17). CEOs expect jobs cuts — and some gains — because of generative AI. CIO Dive. https://www.ciodive.com/news/CEO-generative-AI-job-cuts-pwc/704795/
[4] Indeed. (s. f.). Software development job postings on Indeed in the United States (IHLIDXUSTPSOFTDEVE) [Data set]. FRED, Federal Reserve Bank of St. Louis. Recuperado el 28 de enero de 2026, de https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
[5] Clark, L. (2025, February 27). No new engineer hires this year as AI coding tools boost productivity, says Salesforce. The Register. https://www.theregister.com/2025/02/27/salesforce_misses_revenue_guidance/