sábado, septiembre 12, 2026
lunes, septiembre 07, 2026
Cuatro años de LBAM (Lean Business Agility Model): la agilidad ya no es una opción
Hoy 7 de septiembre se cumplen exactamente cuatro años desde que publiqué por primera vez el Lean Business Agility Model (LBAM) en este blog.
El 7 de septiembre de 2022, junto con Lucho Salazar, presentamos públicamente una idea que veníamos trabajando desde nuestra experiencia acompañando equipos y organizaciones: la agilidad no podía quedarse en los equipos. Había que conectar la agilidad estratégica, táctica y operativa, los equipos transversales y de soporte, el liderazgo, la mentalidad Lean-Ágil, el foco en el cliente y el triple impacto.
Cuatro años después sigo creyendo en esa idea, pero hay algo que hoy expresaría con mucha más fuerza:
La agilidad organizacional ya no es deseable. Es imperativa.
El problema ya no es cambiar. Es cambiar constantemente
Durante años hablamos de “transformación” como si las organizaciones tuvieran que viajar desde un estado A hasta un estado B: hacemos una transformación digital, una transformación ágil, una transformación cultural, transformación a AI-First y, después de unos años, llegamos.
Creo cada vez menos en esa idea.
El entorno no espera a que terminemos nuestra transformación. Mientras una empresa cambia su estructura, cambia la tecnología. Cuando comienza a entender esa tecnología, cambia el comportamiento de sus clientes. Cuando responde a los clientes, aparece un nuevo competidor, una regulación diferente, una crisis geopolítica o, como ocurrió recientemente, una tecnología como la Inteligencia Artificial Generativa que modifica en pocos años lo que considerábamos posible.
Por eso la ventaja no está simplemente en ser capaz de cambiar. Está en desarrollar la capacidad de cambiar, aprender y evolucionar continuamente.
Ahí es donde, para mí, Business Agility adquiere todo su sentido.
De equipos ágiles a organizaciones capaces de evolucionar
Podemos tener equipos extraordinariamente ágiles dentro de organizaciones que siguen siendo lentas.
Un equipo puede entregar cada semana mientras la estrategia cambia una vez al año. Podemos tener ciclos rápidos de experimentación mientras el presupuesto impide reasignar recursos. Podemos descentralizar decisiones y simultáneamente mantener estructuras donde todo lo importante debe escalar varios niveles.
Optimizar una parte del sistema no hace ágil al sistema.
Por eso LBAM conecta la agilidad estratégica, táctica, operativa y la de los equipos transversales y de soporte. Pero esas agilidades necesitan algo debajo: una mentalidad Lean-Ágil, liderazgo, obsesión por el cliente y una concepción del resultado que considere el impacto financiero, social y ambiental.
Esta es la arquitectura que hemos venido evolucionando:
Una organización verdaderamente ágil no es entonces aquella que utiliza más prácticas ágiles. Es aquella que desarrolla mejores capacidades para detectar lo que está ocurriendo, decidir, experimentar, aprender, adaptarse y, cuando sea necesario, reinventarse.
Por eso cada vez me interesa menos preguntar “¿qué tan Agile es esta empresa?” y mucho más preguntar:
¿Qué tan rápido puede esta organización aprender y cambiar cuando descubre que lo que funcionaba ayer ya no funciona hoy?
Cuatro años después, apareció la IA
Hay además algo bonito —y bastante simbólico— en este aniversario.
Cuando publicamos LBAM aquel 7 de septiembre de 2022, ChatGPT todavía no había sido lanzado públicamente. Cuatro años después estoy lanzando el nuevo sitio del modelo con una enorme ayuda de Inteligencia Artificial.
La IA no creó LBAM. El modelo viene de años de trabajo, consultoría, estudio, clases, conversaciones, errores y experimentación. Pero la IA me permitió tomar todo ese conocimiento acumulado y convertirlo mucho más rápidamente en textos, diagramas, código, experimentos visuales y, finalmente, en un sitio web.
Eso también es agilidad.
No se trata simplemente de utilizar una nueva tecnología. Se trata de incorporar nuevas capacidades cuando aparecen y utilizarlas para evolucionar la manera como trabajamos y creamos valor.
Hoy GenAI hace parte del LBAM precisamente bajo esa lógica: no como una nueva capa del modelo, sino como un acelerador transversal de las capacidades organizacionales.
Un modelo que también ha tenido que evolucionar
LBAM tampoco ha permanecido igual desde 2022. Y espero que nunca lo haga.
Desde el principio dijimos que no pretendía ser otro framework ni una respuesta universal. Era una propuesta latinoamericana, deliberadamente simple, que debía complementar otros modelos y promover la mejora continua. Cuatro años después mantengo esa intención.
Y aquí quiero agradecer especialmente a Lucho Salazar.
Lucho estuvo allí desde el comienzo y ha contribuido al desarrollo del modelo, pero sobre todo ha mantenido durante estos años algo que considero todavía más valioso: retroalimentación continua. Conversaciones, preguntas, desacuerdos y observaciones que han obligado a revisar supuestos y mejorar ideas.
Un modelo sobre adaptación debería estar dispuesto a ser cuestionado y adaptarse también.
Gracias, Lucho, por estos cuatro años de conversaciones y por seguir haciendo preguntas incómodas. Suelen ser las más útiles.
Cuatro años después
En 2022 escribíamos que las organizaciones necesitarían “recodificarse genéticamente para infundir agilidad y adaptabilidad en su ADN”. Cuatro años después esa afirmación me parece incluso más vigente.
Quizá incluso me atrevería a simplificarla.
Las organizaciones del futuro no serán aquellas que hayan logrado transformarse. Serán aquellas que hayan aprendido a transformarse continuamente.
Ese es el problema que hoy quiero seguir explorando con LBAM.
Y precisamente hoy, cuatro años después de aquella primera publicación, el modelo estrena una nueva casa:
https://lbam.lecciones-aprendidas.info/
Allí encontrarán la evolución del modelo, su arquitectura, principios, capacidades, métricas, diagnóstico, transformación y su relación con GenAI.
LBAM seguirá cambiando.
Tiene que hacerlo.
Porque un modelo sobre agilidad que deje de evolucionar habrá comenzado, paradójicamente, a contradecir aquello que intenta enseñar.
Saludos ágiles,
Jorge Abad.
jueves, septiembre 03, 2026
EAFIT 2026-02: cuatro formas de repensar los Procesos Modernos de Desarrollo de Software - Trabajos de los estudiantes de la Especialización en Desarrollo de Software
Durante mucho tiempo, hablar de procesos modernos de desarrollo de software parecía reducirse a una discusión sobre Agile, Scrum, DevOps o alguna combinación de prácticas conocidas.
Pero la ingeniería de software está entrando en dominios donde esa respuesta ya no es suficiente.
¿Qué proceso se necesita para desarrollar un sistema que debe adaptarse autónomamente al entorno? ¿Cómo cambia la ingeniería cuando el software está compuesto por agentes de inteligencia artificial que toman decisiones? ¿Cómo se valida un sistema de realidad aumentada donde la experiencia del usuario, la latencia y los derechos sobre el contenido son parte del producto? ¿Y cómo se desarrolla un videojuego cuando una compilación exitosa no significa necesariamente que el juego sea divertido?
Estas fueron algunas de las preguntas abordadas por los estudiantes del curso Procesos Modernos de Desarrollo de Software de la Universidad EAFIT.
El reto no consistía simplemente en escoger una metodología existente. Los equipos debían estudiar un dominio, identificar sus problemas particulares, analizar diferentes enfoques de ingeniería de software y diseñar un modelo de proceso capaz de responder a esas características.
El resultado son cuatro propuestas que exploran sistemas ciberfísicos, aplicaciones agénticas, realidad aumentada y videojuegos.
un proceso moderno de desarrollo de software no debería comenzar preguntando “¿qué metodología vamos a usar?”, sino “¿qué características de este sistema hacen necesario diseñar una forma particular de construirlo, validarlo y operarlo?”
1. MDM: cuando el software debe coordinarse con el mundo físico
MAPE-Driven Methodology (MDM): Aplicación a un Sistema de Riego Inteligente para Cultivos de Café
Joan Sebastian Herrera M., Santiago Mesa V., Sergio Alfredo Juanca V., Tomas Echavarria G. y Mateo Muñoz B.
El primer trabajo se mueve hacia un territorio particularmente complejo: los sistemas ciberfísicos autoadaptables.
En ellos el software deja de vivir únicamente dentro de computadores y comienza a interactuar directamente con sensores, dispositivos físicos y condiciones cambiantes del mundo real.
El caso estudiado es un sistema inteligente de riego para cultivos de café mediante drones. La propuesta combina Spec-Driven Development, Domain-Driven Design, DevOps y MAPE-K.
Uno de los aspectos más interesantes del modelo es la separación entre los equipos de hardware y software. Ambos pueden avanzar en paralelo utilizando un principio de “contrato primero”, sincronizándose únicamente en puntos definidos del proceso.
La metodología se estructura en seis fases y utiliza simulación, ciclos de retroalimentación, especificaciones y trazabilidad para conectar las decisiones técnicas con las reglas del dominio agrícola.
La lección: cuando el software controla el mundo físico, integración continua ya no significa únicamente integrar código. También hay que integrar modelos, sensores, hardware, simulaciones y comportamiento físico.
2. AGORA: desarrollar agentes de IA no es simplemente escribir prompts
AGORA: Modelo de Procesos para el Desarrollo de Aplicaciones Agénticas
Juan José Henao Aristizábal, Ioav Mizrachi Muñoz, Juan Miguel Castro Martínez y Julián Giraldo Chica
Las aplicaciones agénticas introducen un cambio importante en la ingeniería de software.
Un sistema tradicional recibe una entrada, ejecuta una lógica relativamente determinada y produce un resultado. Un agente basado en modelos de lenguaje puede interpretar un objetivo, elaborar un plan, seleccionar herramientas, ejecutar acciones, observar sus resultados y modificar posteriormente su estrategia.
Eso cambia incluso la forma de probar software.
La pregunta deja de ser únicamente “¿la prueba pasa?” y comienza a convertirse en “¿con qué nivel de confiabilidad logra el agente el objetivo y qué evidencia tenemos de ello?”.
AGORA integra cuatro perspectivas: Desarrollo Dirigido por Objetivos, Diseño de Sistemas Multiagente, Spec-Driven Development y DevOps/DevSecOps complementado con AgentOps.
El modelo propone cinco fases: Iniciativa, Organización, Especificación, Realización y Despliegue, y las materializa mediante ocho roles, catorce artefactos, treinta y una tareas y veintiséis productos de trabajo.
Una de sus ideas centrales es particularmente relevante para la ingeniería de agentes: la autonomía no debería descubrirse accidentalmente en producción; debe diseñarse explícitamente.
También propone que cada objetivo pueda rastrearse hasta criterios de evaluación y posteriormente hasta evidencia obtenida durante la operación.
La lección: cuando construimos agentes inteligentes, gobernanza, observabilidad, evaluación, autonomía y trazabilidad dejan de ser preocupaciones secundarias. Se convierten en parte del proceso de desarrollo.
3. ARCA: en realidad aumentada, la experiencia también forma parte de la ingeniería
ARCA: un modelo de proceso para el desarrollo de software en realidad aumentada con aseguramiento continuo de experiencia, rendimiento y derechos
Quinnie Villarreal Aragón, José Manuel Carvajal, Jonathan Sandoval, Lina Ballesteros y Alejandro Ríos
La realidad aumentada combina software, dispositivos, sensores, contenido gráfico, interacción humana y representación del entorno físico.
Por eso una entrega técnicamente correcta puede seguir siendo una mala solución: puede tener problemas de latencia, usabilidad, registro espacial, experiencia de usuario, privacidad o derechos sobre el contenido.
ARCA —Augmented Reality Continuous Assurance— combina Human-Centered Design, DevOps, Event-Driven Architecture e Inteligencia Artificial Generativa.
La metodología propone siete fases y distingue explícitamente dos cadenas de construcción: una para software y otra para contenido.
También introduce tres cadencias anidadas, compuertas de retorno cuando una validación falla y responsabilidades específicas sobre producto, decisiones técnicas, derechos, licencias y responsabilidad social.
Esta última característica es especialmente interesante: privacidad, procedencia del contenido y responsabilidad social no aparecen simplemente como recomendaciones éticas al final del proyecto, sino como condiciones verificables dentro del proceso.
La lección: la calidad de un producto digital no siempre está contenida completamente en su código. En algunos dominios, experiencia, contenido, contexto de uso y responsabilidad también necesitan sus propios mecanismos de aseguramiento.
4. Videojuegos: una build que compila no necesariamente es un buen juego
Metodología integrada para la ingeniería de software de videojuegos
Angélica María Martínez Carmona, Ángel David Martínez Doria, David Gustavo Moreno Morán, Diego Mauricio Sánchez Buitrago y Tomás Olarte Hernández
El desarrollo de videojuegos muestra con claridad los límites de pensar únicamente en requisitos funcionales.
Un videojuego puede compilar correctamente, superar sus pruebas unitarias y aun así no ser divertido, tener una mala experiencia de juego o producir comportamientos emergentes no previstos.
La propuesta utiliza como unidad fundamental el incremento jugable verificable: una porción integrada de código y contenido que permite comprobar una hipótesis sobre la experiencia.
El modelo combina DevOps, BDD complementado con aprendizaje por refuerzo e imitación, Sistemas Multiagente e Inteligencia Artificial Generativa.
Los ciclos de los incrementos oscilan entre una y dos semanas, pero diferentes actividades —integración continua, entrenamiento de agentes o playtesting— pueden tener cadencias distintas.
La metodología se formaliza mediante SPEM 2.0 en siete fases, doce roles y treinta y dos productos de trabajo. Sin embargo, establece un límite importante a la automatización: solo las personas pueden cerrar determinadas compuertas de decisión.
El playtesting humano conserva así la responsabilidad sobre algo que ningún pipeline puede determinar completamente: la experiencia del jugador.
La lección: automatizar más no siempre significa delegar más. En sistemas donde existe creatividad, comportamiento emergente o experiencia humana, automatización y autoridad son dos decisiones diferentes.
Abrir metodología de videojuegos en Google Drive
La principal lección aprendida
Después de revisar los cuatro trabajos aparece una conclusión que considero especialmente valiosa para quienes estudiamos ingeniería de software:
DevOps, Agile, Spec-Driven Development, Domain-Driven Design, BDD, sistemas multiagente, GenAI o diseño centrado en el humano no deberían entenderse como metodologías que compiten por ser “la correcta”.
Son conjuntos de principios, prácticas y mecanismos que responden a problemas diferentes.
El verdadero trabajo de ingeniería consiste en entender primero la naturaleza del sistema y después diseñar la manera en que debe construirse.
Los cuatro trabajos muestran precisamente eso.
- Un sistema ciberfísico necesita sincronizar software y hardware.
- Un agente necesita gobernar su autonomía y demostrar que alcanza
- objetivos.
- Una aplicación de realidad aumentada necesita validar simultáneamente
tecnología y experiencia.
- Un videojuego necesita verificar comportamiento sin eliminar la creatividad
ni el juicio humano.
Quizá esa sea una buena definición de lo que significa estudiar Procesos Modernos de Desarrollo de Software:
no aprender cuál metodología utilizar, sino desarrollar el criterio necesario para comprender por qué, cuándo y bajo qué condiciones utilizar —o incluso diseñar— una forma determinada de desarrollar software.
Estos documentos son entregables académicos desarrollados por estudiantes de la Universidad EAFIT y se publican aquí como material de aprendizaje, discusión y consulta.
Saludos ágiles
Jorge Abad
domingo, agosto 23, 2026
El cuello de botella del software ya no será escribir código - Una experiencia académica que está permeando cada vez más proyectos corporativos
El sábado pasado (22 de agosto de 2026) vi algo que me dejó pensando seriamente sobre el futuro del desarrollo de software.
Junto con el profesor Andrés Felipe Alvarez,en el curso Procesos Modernos de Desarrollo de Software, de la Especialización en Desarrollo de Software de la Universidad EAFIT, retamos a nuestros estudiantes a evolucionar aplicaciones completas utilizando Spec-Driven Development (SDD) e Inteligencia Artificial.
Pero había una condición:
No queríamos ver IA generando código. Queríamos ver ingeniería de software.
Los equipos debían trabajar sobre aplicaciones reales:
Frontend → Backend/API → Base de datos → Pruebas → Git → CI/CD → Producción.
Y además tenían que hacerlo en paralelo.
Cada estudiante, desde su propia máquina, recibía una necesidad y debía recorrer aproximadamente este camino:
Necesidad → Spec → Plan → Tasks → Código → Pruebas → Commit → Integración → Deploy.
Lo que ocurrió fue impactante.
En nuestro ejercicio, observamos reducciones de más del 90% en el tiempo necesario para construir algunas funcionalidades.
En aproximadamente una hora u hora y media, varios estudiantes trabajaron simultáneamente sobre diferentes partes del producto, terminaron historias de usuario, integraron cambios y lograron llevar nuevas capacidades hasta producción.
Y ahí está, para mí, lo realmente importante.
La revolución no es que la IA escriba código más rápido.
Eso ya lo sabemos.
La revolución puede estar en que un equipo completo sea capaz de evolucionar software en paralelo, a gran velocidad, manteniendo especificaciones, trazabilidad, pruebas e integración.
Por supuesto, un salón de clase no es un entorno corporativo.
En una organización real aparecen legacy, regulación, arquitecturas complejas, dependencias, seguridad, compliance, datos sensibles, procesos de aprobación y una larga lista de restricciones.
Y todavía tenemos retos importantes en testing, calidad, seguridad y confiabilidad del código generado por IA.
Pero aun descontando todo eso, hay una señal que me parece difícil ignorar:
la velocidad potencial del ciclo de desarrollo está cambiando radicalmente.
Y si el desarrollo se acelera 5x, 10x o más, el cuello de botella simplemente se moverá.
Tal vez muy pronto el problema principal ya no sea:
“¿Qué tan rápido podemos programarlo?”
sino:
“¿Qué tan rápido podemos especificar correctamente lo que necesitamos, verificarlo, integrarlo y decidir qué vale la pena construir?”
Eso cambia muchas cosas.
Cambia el rol del desarrollador. Cambia el rol del arquitecto. Cambia QA. Cambia DevOps. Cambia Product Management. Y probablemente termine cambiando buena parte del SDLC que conocemos.
Mi invitación para quienes trabajan en tecnología es sencilla:
No se limiten a leer sobre Spec-Driven Development.
Pruébenlo.
Tomen una aplicación pequeña. Definan buenas especificaciones. Usen herramientas como GitHub Spec Kit u OpenSpec. Pongan varios agentes y personas a trabajar sobre Specs independientes. Integren. Prueben. Desplieguen.
Y observen qué ocurre.
Porque después de lo que vimos el viernes, tengo una hipótesis cada vez más fuerte:
la IA no solamente está acelerando la programación. Está empezando a comprimir el ciclo completo de construcción de software, y nos estamos moviendo -desde la construcción- a un escenario Predictivo-Adaptativo, por fin voy a saber cuando estará lista la funcionalidad y adaptaré rápidamente le codigo según la retroalimentación.
Y eso puede tener consecuencias mucho más profundas de las que estamos imaginando.
Saludos,
Jorge Abad.
#SpecDrivenDevelopment #SDD #GenerativeAI #ArtificialIntelligence #SoftwareEngineering #AIEngineering #SoftwareDevelopment #DevOps #Agile #FutureOfSoftware
Publicado originalmente en linkedin: Clic aquí
martes, agosto 11, 2026
sábado, junio 27, 2026
AI-BDF: un framework para reflexionar sobre cómo construir productos en la era de la IA
Durante los últimos meses he estado trabajando en un proyecto que resume muchas de las conversaciones, experimentos y aprendizajes que he acumulado alrededor de la transformación del desarrollo de software impulsada por la Inteligencia Artificial.
El resultado es AI-BDF (AI-Native Bet Delivery Framework).
No nació de una investigación aislada ni pretende ser una nueva metodología. Es una síntesis de ideas provenientes de múltiples fuentes: proyectos reales, clases de Ingeniería de Software y Transformación Digital en EAFIT, literatura especializada, observación de organizaciones que adoptan AI Engineering, Spec Driven Development (SDD), Vibe Coding, Product Discovery y experimentación continua.
Mi intención nunca fue crear "el framework definitivo".
Al contrario.
Creo que estamos viviendo uno de los cambios más profundos de la ingeniería de software desde la aparición de Internet. La Inteligencia Artificial está modificando la forma en que descubrimos problemas, tomamos decisiones, diseñamos productos y escribimos software. En un contexto tan dinámico, pensar que existe una metodología definitiva sería una contradicción.
Por eso AI-BDF se plantea como un marco de reflexión.
Propone una forma de organizar el trabajo alrededor de apuestas (Bets), hipótesis, experimentos, validaciones, especificaciones e industrialización, entendiendo que el verdadero cuello de botella ya no es construir software, sino decidir correctamente qué vale la pena construir.
Uno de los principios que más me gusta del framework es que el propio framework debe evolucionar.
No quiero que las organizaciones copien AI-BDF. Me gustaría que lo cuestionen, lo adapten y, ojalá, construyan una versión mejor para su propio contexto. Si sirve como punto de partida para una conversación estratégica o para mejorar un proceso interno, habrá cumplido su propósito.
Por esa razón, el framework se publica bajo licencia Creative Commons CC BY-SA 4.0, permitiendo que cualquiera pueda usarlo, adaptarlo y compartirlo, siempre manteniendo la atribución y la misma licencia en los trabajos derivados.
Si decides explorarlo o utilizar alguna de sus ideas, me encantaría conocer tu experiencia. La mejor forma de seguir mejorando un framework es aprender de quienes lo ponen en práctica.
Puedes explorar el proyecto en:
https://ai-bdf.lecciones-aprendidas.info
También puedes escribirme a:
Toda crítica, comentario o experiencia será bienvenida. Después de todo, si algo he aprendido durante estos años es que los mejores frameworks no nacen de una sola persona, sino de una comunidad que aprende y evoluciona continuamente.
martes, junio 23, 2026
lunes, junio 08, 2026
lunes, mayo 18, 2026
Rescatando mi tesis de maestría de 2012 usando IA generativa - "Software EDUP: ingeniería de software para estudiantes antes del boom ágil"
Hola a todos
Volver a mirar mi tesis de 2012 es
como volver a escuchar un vinilo de Led Zeppelin.
Hace unos días decidí rescatar y volver a publicar un proyecto que desarrollé como parte de mi tesis de maestría terminada en 2012:
EDUP – Framework de apoyo para proyectos universitarios (clic aquí)
|
| Framework: Software EDUP |
Y honestamente… verlo nuevamente me produjo una mezcla rara entre nostalgia, curiosidad técnica y una sonrisa de “wow… cómo ha cambiado todo”.
En ese momento, mi interés estaba centrado en algo muy específico: ayudar a los estudiantes universitarios a construir mejor sus proyectos de software utilizando buenas prácticas de ingeniería de software.
Esto ocurrió incluso antes del gran boom latinoamericano —al menos en Colombia— de Scrum, SAFe, Kanban y toda la explosión de marcos y métodos ágiles que vino después.
La idea detrás de EDUP era construir una especie de framework de acompañamiento: una guía estructurada para ayudar a estudiantes a entender procesos, artefactos, prácticas y formas organizadas de desarrollar software.
Y aquí viene una parte que hoy me parece fascinante.
El sitio original fue construido utilizando Eclipse Process Framework Composer (EPF Composer), una herramienta muy usada en esa época para modelar procesos y publicar metodologías de ingeniería de software.
Pero claro… han pasado más de 10 años.
- Muchas cosas ya no funcionan igual.
- Los applets de Java prácticamente desaparecieron del navegador moderno.
- Algunas tecnologías quedaron congeladas en el tiempo.
- Y el sitio original ya empezaba a sentirse como una cápsula arqueológica digital.
Entonces decidí hacer algo curioso:
Usar IA para revivirlo.
Y aquí viene la parte más increíble de toda esta historia.
La migración completa del sitio fue planeada y ejecutada prácticamente en unos 20 minutos usando Visual Studio Code, GitHub Copilot e IA generativa.
Literalmente construimos prompts para:
analizar la estructura vieja,
entender cómo estaba organizado EPF Composer,
eliminar dependencias obsoletas,
migrar componentes incompatibles,
modernizar la publicación,
-
y reconstruir el sitio estático para que funcionara nuevamente en navegadores actuales.
Y mientras veía el resultado funcionando otra vez, no pude evitar pensar algo:
la industria cambió radicalmente… pero algunas preguntas siguen siendo las mismas.
- ¿Cómo ayudamos a las personas a construir mejor software?
- ¿Cómo reducimos ambigüedad?
- ¿Cómo respetamos las especificaciones?
- ¿Cómo mantenemos coherencia entre intención y resultado?
Solo que hoy aparecen nuevos enfoques como Spec-Driven Development, agentes inteligentes y generación automática de código, que vuelven a poner las especificaciones y la intención en el centro del proceso.
Y eso me parece hermoso.
Porque mirando hacia atrás, siento que muchas de las preocupaciones de aquella tesis siguen vigentes… solo que ahora tenemos copilotos de IA ayudándonos a construir.
A veces la tecnología avanza tan rápido que parece magia.
Y a veces simplemente estamos persiguiendo las mismas ideas… pero con
herramientas mucho más poderosas.
Saludos ágiles,
Jórge
Abad
Notas
- Más información en: en este enlace, clic aquí
domingo, abril 26, 2026
domingo, marzo 01, 2026
miércoles, febrero 18, 2026
Dos Caminos, un Mismo Desafío Por qué la adopción de IA fracasa cuando olvidamos que empresas y personas recorren el mismo viaje
La ilusión del problema tecnológico
La mayoría de las organizaciones cree que adoptar Inteligencia Artificial es, ante todo, un desafío tecnológico. Invierten en herramientas, contratan consultores, lanzan pilotos y crean laboratorios de innovación con la expectativa de capturar rápidamente los beneficios prometidos por la IA generativa. Sin embargo, a medida que avanzan, muchas descubren una realidad incómoda: los resultados no aparecen al ritmo esperado.
No es un problema nuevo. Según estudios recientes, aunque la inversión empresarial en IA crece aceleradamente, la captura real de valor sigue siendo limitada en muchas industrias. McKinsey estima que la IA generativa podría generar entre 2.6 y 4.4 billones de dólares anuales en valor económico global, pero también reconoce que la mayoría de las organizaciones aún no logra traducir ese potencial en impacto tangible (McKinsey & Company, 2023).
La explicación más común suele ser técnica: falta de datos, modelos inmaduros o infraestructura insuficiente. Sin embargo, la verdadera causa suele ser otra. Las empresas fracasan en IA por las mismas razones que las personas fracasan cuando intentan aprenderla.
La adopción de IA no es solo un cambio tecnológico. Es un viaje de transformación.
El patrón oculto: dos viajes que avanzan en paralelo
Cuando observamos cómo las personas se acercan a la IA, aparece un patrón reconocible. El recorrido inicia con curiosidad y entusiasmo. Todo parece posible. La tecnología promete productividad, creatividad y ventajas competitivas inmediatas. Pero rápidamente surge la ansiedad: ¿mi trabajo seguirá siendo relevante?, ¿necesito aprender a programar?, ¿qué pasará con mi carrera?
Ese punto marca el inicio del verdadero aprendizaje. La persona atraviesa un proceso similar a un duelo profesional: resistencia, frustración y finalmente adaptación. Solo quienes desarrollan criterio y disciplina logran integrar la tecnología a su práctica diaria.
Las organizaciones recorren exactamente el mismo camino.
Primero aparece el entusiasmo estratégico. Luego llegan los pilotos aislados, la sobreexpectativa y, finalmente, la frustración cuando la innovación no se traduce en resultados medibles. En ese momento muchas empresas abandonan iniciativas o reducen su ambición.
El error es pensar que la transformación ocurre únicamente a nivel tecnológico. En realidad, la empresa está atravesando una transición cultural similar a la que viven sus empleados.
El problema no es la IA. El problema es que nadie reconoce que ambos viajes ocurren simultáneamente.
GenAI cambió la puerta de entrada — pero no el desafío
Durante años, acceder al mundo de la Inteligencia Artificial requería conocimientos profundos en matemáticas, estadística y aprendizaje automático. Hoy, la IA generativa ha reducido drásticamente esa barrera. Un profesional puede comenzar a utilizar herramientas avanzadas sin entender cómo se entrenan los modelos.
Esta democratización representa una oportunidad histórica. Pero también introduce una ilusión peligrosa: confundir facilidad de uso con comprensión real.
El hecho de que cualquiera pueda generar código, texto o análisis con un modelo no significa que haya desarrollado criterio para aplicarlo estratégicamente. La curva técnica se acortó, pero la curva de madurez sigue existiendo.
La paradoja es clara: cuanto más fácil se vuelve usar la IA, más importante se vuelve pensar bien.
El nuevo activo estratégico: claridad mental
Una de las lecciones más inesperadas de la IA generativa es que la calidad de los resultados depende menos del modelo y más de la calidad de las preguntas. El llamado prompt engineering no es simplemente una habilidad técnica; es una forma de pensamiento estructurado.
Las organizaciones que capturan valor no son necesariamente las que tienen acceso a mejores modelos, sino las que desarrollan mejores formas de formular problemas. La IA amplifica el pensamiento humano. Cuando el pensamiento es confuso, los resultados también lo son.
Esto cambia profundamente el perfil de talento requerido. La ventaja competitiva ya no reside únicamente en especialistas técnicos, sino en profesionales capaces de combinar criterio estratégico con capacidad de experimentación.
En este nuevo contexto, la IA no reemplaza el pensamiento humano. Exige que sea mejor.
El punto que la mayoría ignora: lo que no se mide no se transforma
Muchas iniciativas de IA fracasan porque permanecen en el terreno de la experimentación sin conectar con métricas reales de negocio. Las organizaciones celebran demos impresionantes, pero no pueden responder preguntas simples: ¿qué indicador mejoró?, ¿qué costo se redujo?, ¿qué ingreso nuevo se generó?
El NIST AI Risk Management Framework insiste en que la adopción responsable de IA requiere observabilidad y métricas claras (NIST, 2023). Sin medición, la innovación se convierte en narrativa.
Lo mismo aplica a nivel individual. Aprender IA no significa consumir contenido o probar herramientas. Significa lograr resultados observables: reducir tiempos, mejorar decisiones o resolver problemas que antes parecían imposibles.
La transformación solo es real cuando deja huellas medibles.
El futuro del trabajo ya comenzó
El impacto laboral de la IA ya es visible. Estudios del Fondo Monetario Internacional sugieren que hasta el 60 % de los empleos en economías avanzadas podría verse afectado por la IA en distintos niveles (IMF, 2024). Algunas empresas están reduciendo contratación en roles de entrada, mientras otras redefinen funciones completas.
Sin embargo, el cambio no se trata simplemente de reemplazo. Se trata de redistribución del valor humano.
Las tareas repetitivas y predecibles se automatizan primero. Lo que emerge es un mercado laboral donde el criterio, la creatividad y la capacidad de aprendizaje continuo se vuelven diferenciales críticos.
El verdadero riesgo no es la IA. Es quedarse quieto mientras el mundo cambia.
La ventaja invisible: aprender como sistema
Ninguna persona puede seguir el ritmo de cambio tecnológico por sí sola. Tampoco puede hacerlo una empresa que dependa únicamente de expertos aislados. Las organizaciones que avanzan más rápido están creando comunidades internas de aprendizaje que filtran información, comparten experimentos y aceleran la adopción colectiva.
La ventaja competitiva futura no pertenecerá a quienes adopten primero la tecnología, sino a quienes desarrollen mayor capacidad de adaptación continua.
En un entorno exponencial, la velocidad de aprendizaje supera a la velocidad de ejecución.
El verdadero desafío estratégico
Las empresas suelen preguntarse cómo implementar IA. La pregunta correcta es otra: ¿cómo transformamos nuestra capacidad de aprender mientras la tecnología evoluciona?
La IA no es un destino ni un proyecto puntual. Es una nueva capa operativa que obliga a rediseñar cómo pensamos, trabajamos y tomamos decisiones.
Las organizaciones que lo entiendan dejarán de tratar la IA como una iniciativa tecnológica y comenzarán a verla como una transformación humana y cultural.}
El cierre: dos caminos, una decisión
Las personas y las empresas están recorriendo el mismo viaje. Ambas enfrentan miedo, resistencia y sobreexpectativa. Ambas necesitan desarrollar criterio, disciplina y capacidad de aprendizaje continuo.
La diferencia entre quienes prosperen y quienes queden atrás no estará determinada por el acceso a la tecnología, sino por la voluntad de atravesar esa transformación.
La IA no reemplazará a las personas.
Pero reemplazará a las organizaciones que no aprendan lo suficientemente rápido.
Referencias
- McKinsey & Company. (2023). The economic potential of generative AI.
- International Monetary Fund. (2024). AI will transform the global economy.
- National Institute of Standards and Technology (NIST). (2023). AI Risk Management Framework.
- Stanford HAI. (2024). AI Index Report.
martes, noviembre 25, 2025
martes, octubre 21, 2025
jueves, octubre 09, 2025
jueves, agosto 28, 2025
viernes, junio 27, 2025
Nuestro cambio de foco, de la Transformación Digital a la GenAI
Hoy comparto un video que creé con Veo3, inspirado en esta sensación que muchos vivimos en las organizaciones:
“No se trata solo de correr. Se trata de saber hacia dónde vamos… y de acelerar con inteligencia.”
🔎 Prompt usado para crear el video:
🎬 Escena 1: “Transformación Digital”
Un grupo de ejecutivos C-level (personas reales) — hombres y mujeres de distintas etnias — corren en una pista olímpica profesional. Visten ropa ejecutiva formal, pero llevan zapatillas deportivas. Persiguen un dron que lleva claramente el texto “Transformación Digital”. El dron vuela a 3 metros delante de ellos, a la misma velocidad. La cámara los sigue en plano medio lateral. El ambiente es tenso pero enfocado, como en una carrera de relevos. Duración: 4 segundos.
🎬 Escena 2: “Aceleración de GenAI”
De pronto, el dron se transforma en un robot humanoide llamado “GenAI”, de la misma altura que los ejecutivos. El robot comienza a acelerar gradualmente, aumentando la distancia: primero 4 metros, luego 6 metros, y finalmente 10 metros. La cámara empieza a hacer zoom out lentamente, mostrando cómo se amplía la distancia mientras GenAI acelera. El fondo se vuelve cada vez más abstracto. Los ejecutivos se ven cada vez más pequeños. Duración: 4 segundos.
💡 Reflexión:
Hoy no basta con correr detrás de la transformación digital.
Es momento de pensar cómo alcanzamos a GenAI… y cómo la convertimos en ventaja.
👉 ¿Tu empresa está corriendo tras GenAI o ya encontró la manera de alcanzarla?
GenAI TransformacionDigital Innovación Liderazgo FuturoDigital InteligenciaArtificial AI Veo3 AIinBusiness EstrategiaDigital
GenAI DigitalTransformation Innovation Leadership FutureOfBusiness ArtificialIntelligence AI Veo3 AIinBusiness DigitalStrategy