jueves, octubre 01, 2026

Cómo empezar en Inteligencia Artificial, programación y agentes: la ruta que yo seguiría hoy

Muchas personas me han preguntado últimamente:

“¿Cómo comienzo en el mundo de la Inteligencia Artificial, la programación y la creación de agentes?”

Así que decidí escribir la respuesta más completa que pudiera.

No pretendo que esta sea la única ruta. Es simplemente la ruta que, con lo que sé hoy, 1 de octubre de 2026, recomendaría a alguien que quiere comenzar desde cero y llegar al punto en el que pueda construir sus propias aplicaciones con Inteligencia Artificial.

Y quiero comenzar con algo que para mí es fundamental:

No necesitas aprender todo antes de comenzar a construir.

De hecho, creo exactamente lo contrario.

La mejor manera de aprender este mundo es construyendo cosas pequeñas, equivocándote, preguntándole a la IA, corrigiendo y volviendo a construir.

En mi caso, la Inteligencia Artificial se ha convertido en un gran maestro.

He tomado cursos, leído documentación, visto videos y estudiado tecnología durante muchos años. Todo eso sigue siendo valioso. Pero pocas herramientas educativas me han permitido aprender con la velocidad con la que hoy puedo aprender teniendo al lado una IA a la que puedo preguntarle:

“No entendí esto. Explícamelo de otra manera.”

“Ponme un ejemplo.”

“Ahora hazlo más difícil.”

“Déjame intentarlo.”

“No continúes hasta que yo lo haya entendido.”

Eso cambia radicalmente la forma de aprender.

Esta es la ruta que recomiendo.


0. Antes de comenzar: cambia la forma de aprender

Hay una idea que atraviesa toda esta guía:

No utilices la IA solamente para que haga cosas por ti. Utilízala para que te enseñe a hacerlas.

Son dos usos completamente diferentes.

Puedes decir:

“Hazme una aplicación en Python.”

Y probablemente obtendrás código.

Pero también puedes decir:

“Quiero aprender Python construyendo una aplicación sencilla. Actúa como profesor. Explícame cada decisión. Avancemos paso a paso. No continúes hasta que yo confirme que entendí.”

La segunda aproximación construye algo mucho más importante que una aplicación:

construye conocimiento.


1. Comprende qué es realmente un LLM

Antes de crear aplicaciones con Inteligencia Artificial considero casi obligatorio comprender, al menos conceptualmente, qué es un Large Language Model — LLM.

No tienes que convertirte en investigador de Machine Learning.

Pero sí deberías comprender conceptos como:

  • tokens,
  • ventana de contexto,
  • probabilidades,
  • temperatura,
  • prompt,
  • alucinaciones,
  • entrenamiento,
  • inferencia,
  • embeddings,
  • modelos fundacionales.

Y, sobre todo, comprender una idea:

Un LLM no es una base de datos que “conoce la respuesta”. Es fundamentalmente un sistema probabilístico que genera una continuación plausible a partir del contexto recibido.

Eso explica muchas de sus fortalezas.

Y también muchas de sus limitaciones.

Para comenzar recomiendo ver este video:

No pases demasiado rápido por esta etapa.

Cuando entiendes aproximadamente qué ocurre detrás de un LLM, comienzas a utilizarlo de una manera completamente diferente.


2. Aprende Prompt Engineering

El siguiente paso es aprender a comunicarse correctamente con estos modelos.

Es decir: Prompt Engineering.

Puede parecer que esto perderá importancia porque los modelos cada vez entienden mejor nuestras intenciones.

En cierta forma es verdad.

Pero existe una habilidad más profunda que probablemente seguirá siendo muy importante:

aprender a expresar claramente una intención, proporcionar contexto, definir restricciones y describir cómo reconocer una buena respuesta.

Eso sirve para conversar con ChatGPT.

Pero también sirve para programar con agentes, desarrollar software con IA, construir automatizaciones y crear sistemas agénticos.

Un buen prompt debería enseñarte a pensar en:

  • Rol: quién quiero que sea la IA.
  • Contexto: qué necesita saber.
  • Objetivo: qué quiero lograr.
  • Restricciones: qué puede y qué no puede hacer.
  • Criterios de éxito: cómo sé que la respuesta es buena.
  • Formato: cómo quiero recibir la respuesta.
  • Ejemplos: qué significa para mí una respuesta correcta.

Por ejemplo:

Rol: Actúa como arquitecto de software senior.

Contexto: Estoy construyendo una aplicación de citas médicas con React y Python.

Objetivo: Ayúdame a identificar los requerimientos funcionales.

Restricciones: El sistema inicialmente no tendrá pagos ni integración con EPS.

Proceso: Hazme preguntas antes de proponer la arquitectura.

Formato: Organiza los requerimientos por épicas e historias de usuario.

Eso ya es mucho más poderoso que decir:

“Créame una aplicación de citas.”

¿Dónde aprender Prompt Engineering?

Tienes muchas opciones.

Puedes hacer un curso en Udemy, buscar cursos y tutoriales en YouTube o utilizar directamente ChatGPT, Claude o Gemini como profesor.

Mi recomendación es combinar las tres cosas.

Pero no estudies prompting durante tres meses.

Aprende los fundamentos y comienza a utilizarlo inmediatamente en proyectos reales.


3. Después aparecen tres caminos

Una vez tienes esas dos bases —comprender aproximadamente los LLM y saber interactuar con ellos— aparecen varios caminos.

Yo los organizaría así:

  1. Vibe Coding: construir aplicaciones conversando con la IA.
  2. Spec-Driven Development: construir software mediante especificaciones explícitas.
  3. Desarrollo de aplicaciones y agentes de IA: comenzar a programar directamente soluciones con LLM, RAG, tools y agentes.

No son caminos excluyentes.

De hecho, recomiendo recorrer los tres.


4. Camino 1: aprende Vibe Coding

El llamado Vibe Coding consiste, simplificando mucho, en construir software mediante una conversación con una Inteligencia Artificial.

Describes lo que quieres.

La IA genera código.

Ves el resultado.

Corriges.

Refinas.

Repites.

Las herramientas cambian muy rápidamente, así que probablemente cuando leas este artículo existan otras.

A octubre de 2026, algunas herramientas que vale la pena explorar son:

Especialmente para alguien que está comenzando, estas herramientas son impresionantes porque reducen muchísimo la barrera de entrada.

Ejercicio: construye una aplicación de citas médicas

Por ejemplo, dile inicialmente a ChatGPT:

Quiero construir una aplicación sencilla para gestionar citas médicas.

Actúa como analista de producto.

Ayúdame a definir los requerimientos funcionales mínimos para una primera versión.

No programes todavía.

Quiero máximo 8 funcionalidades.

La IA probablemente te propondrá cosas como:

  • crear pacientes,
  • crear médicos,
  • consultar disponibilidad,
  • agendar una cita,
  • cancelar una cita,
  • consultar agenda,
  • modificar una cita,
  • visualizar próximas citas.

Toma esos requerimientos y llévalos a Lovable, Google AI Studio o la herramienta que quieras experimentar.

Pero aquí viene una recomendación importante:

No intentes construir toda la aplicación en un solo prompt.

Trabaja mediante incrementos pequeños.

Primero crea la pantalla principal.

Después pacientes.

Después médicos.

Después agenda.

Después citas.

Después persistencia.

Después autenticación, si realmente la necesitas.

Ese hábito de construir mediante cambios pequeños será increíblemente útil cuando pases a sistemas más grandes.

Aprende también qué hay detrás

No te conformes con que la aplicación “funcione”.

Pregúntale a la IA:

  • ¿Dónde está el frontend?
  • ¿Qué framework está utilizando?
  • ¿Dónde están los datos?
  • ¿Existe una base de datos?
  • ¿Cómo se autentican los usuarios?
  • ¿Dónde se almacenan las credenciales?
  • ¿Cómo se despliega?
  • ¿Qué riesgos de seguridad existen?

Aunque al comienzo entiendas solamente el 30 %, ya estás aprendiendo.


5. Camino 2: aprende Spec-Driven Development

Después del Vibe Coding recomiendo dar un paso adicional.

En lugar de pedir:

“Construye esto.”

aprendes primero a definir:

“Esto es exactamente lo que quiero construir.”

Ahí aparece el Spec-Driven Development — SDD.

La idea me parece especialmente poderosa en un mundo donde producir código será cada vez más barato.

Si la IA puede producir muchísimo código, entonces aumenta el valor de especificar correctamente:

  • qué problema queremos solucionar,
  • qué comportamiento esperamos,
  • qué restricciones existen,
  • cómo vamos a verificarlo,
  • qué arquitectura utilizaremos,
  • qué pruebas demostrarán que funciona.

Dos proyectos que recomiendo explorar son:

Con Spec Kit, por ejemplo, el flujo básico se puede entender conceptualmente como:

Constitution → Specification → Plan → Tasks → Implementation → Validation

Eso obliga a pensar antes de generar código.

Pero no estudies SDD leyendo cincuenta páginas primero

Mi recomendación es exactamente la contraria.

Apréndelo construyendo.

Este fue el tipo de prompt que utilicé para aprender:

¿Quieres aprender Spec-Driven Development? No le pidas a la IA que te lo explique. Pídele que te enseñe mientras construyes algo.

Quiero aprender Spec-Driven Development usando Spec Kit:

https://github.com/github/spec-kit

Tengo GitHub Copilot y Visual Studio Code.

Construyamos un sistema de alquiler de vehículos con React, Python y CSV.

Solo 8 funcionalidades.

Sin login.

Actúa como mi profesor.

Quiero comprender por qué hacemos cada paso.

Avancemos paso a paso.

No continúes hasta que yo confirme.

Ese pequeño cambio es importantísimo.

No estás diciendo:

“Explícame Spec-Driven Development.”

Estás diciendo:

“Enséñame Spec-Driven Development mientras desarrollamos software.”

Para mí esa es una de las mejores formas de utilizar la IA como maestro.


6. Instala un entorno básico de desarrollo

Si quieres continuar hacia aplicaciones de IA más sofisticadas, en algún momento deberías sentirte cómodo con un entorno de desarrollo.

No necesitas convertirte inmediatamente en ingeniero senior.

Pero sí necesitas una pequeña caja de herramientas.

Yo recomendaría:

Personalmente trabajo mucho con Visual Studio Code.

Y, para comenzar con Python, usaría una versión moderna compatible con las librerías que quieras explorar. Python 3.11 y 3.12 siguen siendo versiones cómodas para muchos ejercicios y frameworks, aunque obviamente debes revisar siempre los requerimientos actuales de cada proyecto.


7. Aprende solamente el Python que necesites

Aquí tengo una opinión que probablemente molestará a algunos puristas.

No esperaría a “aprender Python completamente” para empezar a crear aplicaciones con IA.

Python es enorme.

No necesitas saberlo todo.

Probablemente yo utilizo conscientemente una fracción relativamente pequeña de todo lo que Python puede hacer.

La IA escribe buena parte del código.

Pero eso no significa que puedas ignorarlo completamente.

Necesitas comprender, al menos:

  • variables,
  • strings,
  • listas,
  • diccionarios,
  • condicionales,
  • ciclos,
  • funciones,
  • clases de manera básica,
  • módulos,
  • manejo de errores,
  • archivos,
  • entornos virtuales,
  • instalación de paquetes con pip o herramientas equivalentes.

Eso lo puedes aprender mediante un curso básico de Python.

Puedes hacerlo en:

Pero nuevamente:

aprende construyendo.


8. Reto 1: llama tu primer LLM desde Python

Este es, para mí, el primer gran reto técnico.

Debes lograr que un programa Python envíe una pregunta a un modelo y reciba una respuesta.

Punto.

Nada más.

Algo conceptualmente así:

Usuario
   ↓
Python
   ↓
LLM
   ↓
Respuesta

Puedes utilizar un modelo local mediante:

Ollama

o utilizar APIs externas como:

Cuando consigas enviar:

“Explícame qué es Business Agility.”

desde Python y recibir una respuesta, habrás dado un paso conceptual enorme.

Porque ya no estás usando ChatGPT.

Estás construyendo software que utiliza Inteligencia Artificial.


9. Reto 2: construye una API con FastAPI

El siguiente paso es aprender cómo convertir ese pequeño programa en un servicio.

Para eso recomiendo:

FastAPI

FastAPI es una excelente forma de construir APIs con Python.

Puedes pedirle a la IA:

Quiero aprender FastAPI.

Ayúdame a construir una API pequeña en Python que reciba una noticia y utilice un LLM para extraer cinco ideas principales.

Quiero utilizar buenas prácticas.

Explícame cada archivo.

Avancemos paso a paso.

No continúes hasta que confirme cada paso.

O puedes construir una API que:

  • convierta requerimientos en historias de usuario,
  • analice un RFP e identifique riesgos,
  • resuma documentos,
  • clasifique comentarios de clientes,
  • extraiga compromisos de una reunión,
  • proponga lugares turísticos entre dos puntos,
  • analice retrospectivas ágiles.

El objetivo todavía no es construir algo revolucionario.

El objetivo es comprender la arquitectura:

Frontend
   ↓
API
   ↓
Python / FastAPI
   ↓
LLM

10. Reto 3: aprende embeddings

Después necesitas comprender uno de los conceptos más importantes para muchas aplicaciones modernas de IA:

los embeddings.

Una forma sencilla de entenderlos es pensar que transformamos contenido —por ejemplo textos— en representaciones numéricas que permiten comparar significado.

Eso permite resolver problemas fascinantes.

Ejercicio recomendado

Supongamos que tienes:

  • 20 hojas de vida,
  • una descripción de un cargo.

Construye una aplicación que utilice embeddings para identificar cuáles hojas de vida son semánticamente más cercanas al perfil buscado.

No uses palabras exactas solamente.

Compara significado.

Cuando entiendas ese ejercicio habrás comprendido una pieza fundamental de:

  • búsqueda semántica,
  • sistemas de recomendación,
  • RAG,
  • memoria semántica,
  • recuperación de información.

11. Reto 4: aprende RAG

Después de embeddings, el siguiente concepto que considero fundamental es:

RAG — Retrieval-Augmented Generation.

La idea general es muy poderosa.

En lugar de preguntarle directamente al modelo:

“¿Cuál es la política de vacaciones de mi empresa?”

primero buscas la información relevante en tus documentos.

Después esa información se entrega al modelo como contexto.

Conceptualmente:

Pregunta
   ↓
Búsqueda
   ↓
Documentos relevantes
   ↓
LLM
   ↓
Respuesta fundamentada

Ese patrón aparece constantemente en aplicaciones empresariales.

Construye algo pequeño

Toma cinco documentos PDF.

Construye una aplicación que permita preguntar sobre ellos.

Pero no te conformes con obtener una respuesta.

Pregúntate:

  • ¿recuperé los fragmentos correctos?
  • ¿cuántos fragmentos recuperé?
  • ¿la respuesta realmente está soportada por los documentos?
  • ¿qué pasa cuando la respuesta no está en los documentos?
  • ¿cómo podría medir la calidad del sistema?

Ahí comienzas a entrar realmente en ingeniería de sistemas de IA.


12. Reto 5: aprende a utilizar Tools

Hasta ahora el modelo básicamente piensa y responde.

Pero un sistema mucho más interesante aparece cuando el modelo puede hacer cosas.

Por ejemplo:

  • consultar una base de datos,
  • llamar una API,
  • buscar información,
  • crear un archivo,
  • consultar un calendario,
  • enviar un correo,
  • ejecutar una función Python.

Esas capacidades suelen implementarse mediante tools o funciones que el modelo puede decidir utilizar.

Ese es uno de los saltos conceptuales más importantes.

Pasas de:

IA que responde.

a:

IA que puede actuar sobre un sistema.


13. Reto 6: aprende MCP

Después recomiendo estudiar:

MCP — Model Context Protocol.

MCP busca estandarizar la forma en que aplicaciones basadas en modelos pueden conectarse con herramientas, datos y servicios externos.

Si vas a trabajar seriamente con agentes, vale la pena comprenderlo.

Documentación:

https://modelcontextprotocol.io/

Tu ejercicio puede ser muy sencillo:

Construye o utiliza un servidor MCP con una herramienta sencilla y haz que un cliente o agente pueda descubrirla y ejecutarla.

No importa que el ejemplo sea trivial.

Lo que importa es comprender el protocolo.


14. Ahora sí: comprende qué es un agente

Después de recorrer lo anterior, finalmente la palabra agente comienza a tener mucho más sentido.

Una explicación simplificada podría ser:

             ┌─────────────┐
             │     LLM     │
             │   Cerebro   │
             └──────┬──────┘
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Memoria    Tools     Contexto
          │         │
          └────┬────┘
               ↓
            Acción

Yo lo explicaría inicialmente así:

Un agente combina un modelo, instrucciones, contexto, memoria y herramientas para perseguir un objetivo mediante una secuencia de decisiones y acciones.

No es solamente un chatbot.

Puede observar.

Puede decidir.

Puede utilizar herramientas.

Puede revisar resultados.

Puede volver a intentarlo.

Puede mantener estado.

Y ahí empieza la parte realmente interesante.


15. Aprende LangChain y especialmente LangGraph

Cuando llegues a este punto, tiene mucho más sentido estudiar frameworks como:

Mi recomendación es no comenzar aprendiendo el framework de memoria.

Primero entiende:

  • LLM,
  • prompts,
  • embeddings,
  • RAG,
  • tools,
  • estado,
  • agentes.

Después LangGraph tiene mucho más sentido.

Porque entiendes qué problema está resolviendo.

Y no solamente cómo copiar código de un tutorial.


16. Reto 7: crea tu primer agente

Construye algo realmente pequeño.

Por ejemplo:

Agente analista de RFP.

El agente recibe un RFP y puede:

  1. leer el documento,
  2. identificar requisitos,
  3. buscar información adicional utilizando una herramienta,
  4. detectar riesgos,
  5. generar preguntas para el cliente,
  6. crear un resumen ejecutivo.

Eso ya te obliga a combinar muchas de las piezas anteriores.


17. Reto 8: crea una red de agentes

Después puedes dar el siguiente salto:

sistemas multiagente.

En lugar de tener un agente intentando hacerlo todo, puedes experimentar con agentes especializados.

Por ejemplo:

                 Orquestador
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
   Investigador   Analista     Revisor
        │            │            │
        └────────────┼────────────┘
                     ↓
                  Resultado

Para experimentar con esto puedes utilizar:

n8n resulta especialmente interesante cuando quieres combinar agentes con automatización visual, APIs y servicios empresariales.

LangGraph es particularmente interesante cuando necesitas controlar mediante código el estado, las transiciones y la orquestación de sistemas agénticos.


18. Después vienen los Skills

El ecosistema está evolucionando tan rápidamente que continuamente aparecen nuevos patrones.

Uno de ellos es encapsular conocimiento, instrucciones y capacidades reutilizables en skills que los agentes pueden utilizar dependiendo de la tarea.

No comenzaría por ahí.

Pero cuando ya comprendas agentes, tools, MCP y orquestación, empieza a explorar:

  • skills,
  • subagentes especializados,
  • memoria,
  • guardrails,
  • observabilidad,
  • evaluaciones,
  • tracing,
  • sistemas multiagente.

19. Algo que no puedes olvidar: seguridad

Cuando comiences a programar con APIs, nunca pongas tus API keys directamente en el código que subes a GitHub.

Aprende desde el comienzo a utilizar:

  • variables de entorno,
  • archivos .env,
  • .gitignore,
  • gestores de secretos cuando llegues a producción.

Y mientras estés aprendiendo evita utilizar datos personales, historias clínicas, credenciales reales o información sensible.

Utiliza datos sintéticos.


20. La ruta completa

Si tuviera que resumir toda la jornada, sería aproximadamente esta:

1. Comprender qué es un LLM
            ↓
2. Prompt Engineering
            ↓
3. Vibe Coding
            ↓
4. Spec-Driven Development
            ↓
5. Python básico
            ↓
6. Consumir un LLM desde Python
            ↓
7. FastAPI
            ↓
8. Embeddings
            ↓
9. RAG
            ↓
10. Tools
            ↓
11. MCP
            ↓
12. Agentes
            ↓
13. LangGraph / n8n
            ↓
14. Sistemas multiagente
            ↓
15. Skills, evaluaciones y observabilidad

21. Una propuesta de ocho semanas

No necesitas dedicar un año a esto antes de construir algo interesante.

Una persona disciplinada puede recorrer esta ruta inicial en aproximadamente uno o dos meses.

Semana 1

LLM + Prompt Engineering.

Semana 2

Vibe Coding. Construye dos aplicaciones pequeñas.

Semana 3

Spec-Driven Development con Spec Kit u OpenSpec.

Semana 4

Python + llamadas a APIs + FastAPI.

Semana 5

Embeddings + búsqueda semántica.

Semana 6

RAG.

Semana 7

Tools + MCP + primer agente.

Semana 8

LangGraph o n8n + pequeño sistema multiagente.

Si tienes tiempo y disciplina, probablemente puedas hacerlo incluso más rápido.

Pero no conviertas esto en una carrera.

El objetivo no es terminar ocho semanas.

El objetivo es que al terminar puedas decir:

“Entiendo las piezas y soy capaz de construir con ellas.”


22. El secreto: proyectos pequeños

Creo que uno de los errores más comunes cuando comenzamos en este mundo es intentar construir inmediatamente:

“Una plataforma inteligente multiagente con RAG, memoria, visión artificial, blockchain, Kubernetes y probablemente café automático.”

No.

Haz cosas ridículamente pequeñas.

Un script.

Una API.

Una pantalla.

Un embedding.

Un documento.

Una tool.

Un agente.

Después combínalos.

La complejidad debe aparecer como consecuencia del aprendizaje, no como requisito para comenzar.


23. Utiliza la IA como profesor

Esta quizás sea mi recomendación más importante.

No preguntes solamente:

“¿Cómo funciona RAG?”

Pregunta:

Quiero aprender RAG construyendo una aplicación pequeña.

Tengo conocimientos básicos de Python.

Actúa como profesor de ingeniería de software e Inteligencia Artificial.

Construiremos una aplicación que permita hacer preguntas sobre cinco documentos PDF.

Quiero entender cada decisión.

Explícame solamente lo necesario para realizar el siguiente paso.

Hazme preguntas para comprobar que comprendí.

No continúes hasta que yo confirme.

Ese prompt cambia completamente la experiencia.


24. No necesitas saberlo todo

Este mundo se está moviendo demasiado rápido.

No existe una persona que conozca todas las librerías, todos los modelos, todos los frameworks y todas las técnicas.

Y probablemente esa no sea siquiera una meta razonable.

La habilidad importante es otra:

aprender rápidamente cosas nuevas, comprender los principios y saber utilizar la IA para acelerar ese aprendizaje.

Hoy utilizamos unas herramientas.

Dentro de seis meses utilizaremos otras.

Dentro de tres años probablemente buena parte del desarrollo de software se parecerá muy poco al desarrollo de software que conocíamos hace una década.

Por eso intenta aprender los conceptos que sobreviven a las herramientas:

  • cómo describir un problema,
  • cómo especificar comportamiento,
  • cómo dividir problemas grandes,
  • cómo diseñar sistemas,
  • cómo probarlos,
  • cómo evaluar resultados probabilísticos,
  • cómo reducir incertidumbre,
  • cómo construir sistemas confiables.

Conclusión

Si hoy alguien me preguntara:

“Jorge, ¿cómo comienzo en Inteligencia Artificial?”

mi respuesta no sería:

“Haz seis cursos.”

Sería:

Construye ocho cosas.

Construye una conversación con un LLM.

Construye una aplicación mediante vibe coding.

Construye una pequeña aplicación mediante SDD.

Construye una API.

Construye una búsqueda con embeddings.

Construye un RAG.

Construye un agente.

Construye una pequeña red de agentes.

Y utiliza la Inteligencia Artificial como compañero y como profesor durante todo el proceso.

Probablemente en uno o dos meses sabrás muchísimo más de lo que imaginas hoy.

Y, sobre todo, habrás adquirido algo mucho más importante que conocer una herramienta específica:

habrás aprendido a aprender en la era de la Inteligencia Artificial.

Eso, en mi opinión, es la verdadera superpotencia.


Recursos mencionados

Publicado originalmente el 1 de octubre de 2026. Este ecosistema cambia extremadamente rápido; algunas herramientas, modelos o interfaces probablemente habrán cambiado cuando leas este artículo o mientras lo lees😮. Los principios, sin embargo, deberían sobrevivir bastante más tiempo.

martes, septiembre 15, 2026

Los testers son el nuevo cuello de botella de TI.

La IA ya hace testing: ¿entonces para qué necesitamos testers? Una mirada desde Spec-Driven Development

La Inteligencia Artificial ya puede generar código, crear pruebas, ejecutar validaciones, analizar resultados e incluso corregir errores.

Entonces aparece una pregunta inevitable:

Si la IA ya hace testing, ¿para qué necesitamos testers?

Esta fue la pregunta central de la charla que compartí en Testear.la el 10 de septiembre de 2026:

“La IA ya hace testing, ¿entonces para qué necesitamos testers? — Una mirada desde Spec-Driven Development (SDD)”

La discusión no se limita a preguntarnos si la IA reemplazará o no a los testers. El cambio que estamos viviendo es mucho más profundo.

Cuando utilizamos Inteligencia Artificial y agentes para desarrollar software, el trabajo humano comienza a desplazarse desde la ejecución hacia la definición de:

  • qué debe hacer realmente el sistema,
  • qué comportamiento esperamos,
  • qué escenarios debemos considerar,
  • qué riesgos necesitamos controlar,
  • y qué significa que una funcionalidad esté realmente terminada.

El testing está cambiando

La IA puede automatizar una parte creciente de las tareas que tradicionalmente realizaban desarrolladores y testers.

Puede generar pruebas unitarias, pruebas de integración, escenarios, datos de prueba e incluso interpretar los resultados.

Pero existe una diferencia importante entre generar pruebas y entender qué debe probarse.

Y justamente allí aparece uno de los espacios más interesantes para la evolución del rol del tester.

La IA puede automatizar cada vez más la ejecución del testing, pero alguien todavía tiene que decidir qué significa que el software realmente funcione.

Spec-Driven Development cambia la conversación

Desde la perspectiva de Spec-Driven Development (SDD), las especificaciones dejan de ser documentos secundarios que describen algo que ya construimos.

Empiezan a convertirse en uno de los principales mecanismos para dirigir, controlar y verificar el trabajo realizado por agentes de Inteligencia Artificial.

Especificaciones, reglas de negocio, escenarios, criterios de aceptación y condiciones de validación adquieren entonces un valor mucho mayor.

Esto también transforma el testing.

El tester puede evolucionar desde un rol fuertemente enfocado en la ejecución hacia uno cada vez más relacionado con:

  • análisis de riesgos,
  • diseño de escenarios,
  • definición de criterios de aceptación,
  • exploración de comportamientos inesperados,
  • validación del producto,
  • y evaluación del trabajo producido por agentes de IA.

🎥 Mira la charla completa

📑 Consulta también la presentación

Puedes revisar a continuación el documento utilizado como apoyo durante la charla:

Una pregunta abierta

Probablemente el futuro del testing no consista en competir con la IA para ver quién ejecuta más pruebas.

El verdadero valor puede estar en algo mucho más humano:

formular mejores preguntas, descubrir riesgos, definir comportamientos y decidir qué significa realmente construir el producto correcto.

Y en un mundo de desarrollo agéntico, esa capacidad puede ser incluso más importante que antes.

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.

Una idea atraviesa los cuatro trabajos:

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.

Abrir MDM en Google Drive

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.

Abrir AGORA en Google Drive

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.

Abrir ARCA en Google Drive

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:

No existe un proceso moderno universal.

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í