sábado, octubre 03, 2026

Presento el Método AVANZA: un método para explorar las ideas que podrían transformar tu negocio

Hola a todos

Hoy quiero presentarles algo en lo que he venido trabajando y que me hace especial ilusión compartir: el Método AVANZA.

AVANZA significa Activación y Validación Ágil de Nuevas Zonas de Autotransformación y nace de una inquietud que he tenido durante mucho tiempo:

¿Qué hacemos con esas ideas que parecen extrañas, incómodas o fuera del negocio actual, pero que podrían contener la semilla de nuestra próxima transformación?

El método aparece originalmente en mi libro Pruebo luego existo , pero quise llevarlo más allá del libro.

Por eso construí un micrositio donde se puede conocer el método, explorar sus seis pasos, revisar ejemplos y, sobre todo, utilizar un Canvas interactivo para evaluar ideas reales.

¿Y si la próxima transformación ya estuviera dentro de tu empresa?

Hay una paradoja que aparece una y otra vez en la historia empresarial.

Algunas organizaciones no fueron sorprendidas por el futuro.

El futuro apareció primero dentro de ellas.

Tuvieron la investigación, la tecnología, las personas, los prototipos o incluso los primeros productos.

El problema fue otro: no consiguieron transformar suficientemente rápido el negocio alrededor de esa oportunidad.

Google y los Transformers

En 2017, investigadores de Google publicaron Attention Is All You Need, el trabajo que introdujo la arquitectura Transformer, hoy fundamental para buena parte de los grandes modelos de lenguaje. Google tenía una pieza esencial del futuro de la Inteligencia Artificial dentro de su propia organización. Años después, OpenAI convirtió esta clase de modelos en una experiencia de uso masivo con el lanzamiento de ChatGPT en noviembre de 2022. La lección no es que Google ignorara la tecnología —de hecho la desarrolló y utilizó ampliamente— sino que poseer una ventaja científica no garantiza convertirla primero en una nueva categoría de producto.
Fuentes: Google Research — Attention Is All You Need · OpenAI — Introducing ChatGPT

Kodak y la cámara digital

En 1975, Kodak desarrolló dentro de la propia compañía la primera cámara digital. La empresa había visto una parte importante del futuro de la fotografía décadas antes de que ese futuro destruyera buena parte de la economía basada en película, revelado y copias. El desafío no fue simplemente inventar la tecnología: era transformar un negocio extraordinariamente exitoso alrededor de una tecnología que amenazaba precisamente ese mismo negocio.
Fuente: Kodak — Milestones

Xerox PARC y la interfaz gráfica

Durante los años setenta, Xerox PARC desarrolló el Alto y muchas de las ideas que hoy asociamos con la computación personal: interfaz gráfica, ventanas, iconos, mouse, edición WYSIWYG y redes. En 1979, Steve Jobs y un equipo de Apple visitaron PARC y vieron una demostración de estas tecnologías. Apple ya trabajaba en ideas relacionadas, pero aquella visita reforzó decisivamente su visión sobre cómo debería funcionar una computadora personal. Xerox había creado una parte importante del futuro, pero no consiguió convertir buena parte de ese trabajo en productos de mercado con el impacto que posteriormente lograron otros actores.
Fuentes: Computer History Museum — Xerox PARC · Computer History Museum — Xerox Alto

Xerox, Interpress y el nacimiento de Adobe

Xerox ofrece otro caso todavía más revelador. John Warnock y Charles Geschke trabajaban en Xerox PARC en una tecnología llamada Interpress, destinada a describir digitalmente páginas e impresión. Cuando Xerox decidió no comercializar aquella tecnología, ambos dejaron la empresa y fundaron Adobe. Su trabajo evolucionaría posteriormente hacia PostScript, una tecnología fundamental para la revolución de la publicación digital. En este caso, la oportunidad no solo estaba dentro de la organización: las personas capaces de desarrollarla también estaban allí.
Fuentes: Computer History Museum — Charles Geschke · Computer History Museum — John Warnock

Nokia y el smartphone

Nokia tampoco desconocía el futuro del teléfono inteligente. En 1996 lanzó el Nokia Communicator, uno de los primeros smartphones, y posteriormente desarrolló teléfonos con cámara y nuevas capacidades digitales. La dificultad estuvo en otra parte: presión por resultados de corto plazo, burocracia, conflictos internos y una estructura que hizo cada vez más difícil responder al cambio. INSEAD señala que Nokia terminó atrapada en una competencia centrada en dispositivos mientras la industria migraba hacia plataformas, software y ecosistemas de aplicaciones. La tecnología estaba allí; la transformación organizacional no ocurrió con la velocidad necesaria.
Fuente: INSEAD — The Strategic Decisions That Caused Nokia’s Failure

Microsoft y la Tablet PC

En 2001, Microsoft ya mostraba prototipos de Tablet PC y Bill Gates llegó a predecir que ese formato se convertiría en la forma más popular de PC en pocos años. Microsoft había identificado correctamente una nueva forma de computación móvil. Sin embargo, su propuesta seguía interpretando la tablet principalmente como una evolución del computador portátil con Windows, con lápiz digital, aplicaciones tradicionales y lógica de PC. Años después, otras propuestas replantearían la categoría desde una experiencia mucho más móvil, táctil y centrada en aplicaciones. La oportunidad había sido vista; la dificultad era dejar de interpretarla desde el paradigma dominante.
Fuentes: Microsoft — Gates: Next-Generation Mobile Computing Is Here · Microsoft — Gates Showcases Tablet PC at COMDEX

Quizás el problema no sea solamente detectar el futuro.
Quizás sea reconocerlo cuando todavía parece una idea extraña dentro de nuestra propia organización.

Y precisamente para ese tipo de situaciones creé AVANZA.

El problema: solemos juzgar las ideas demasiado pronto

Las organizaciones son bastante buenas evaluando ideas que se parecen a lo que ya conocen.

Tenemos presupuestos, ROI, business cases, roadmaps, portafolios, priorización, comités, indicadores y procesos de aprobación.

El problema aparece cuando llega una idea que no encaja.

Entonces suelen aparecer frases como:

“Eso no es lo que hacemos”.
“Nuestros clientes no pedirían eso”.
“No sabemos cómo monetizarlo”.
“No está dentro de la estrategia”.
“Quizás más adelante”.

Y algunas de esas respuestas pueden ser correctas.

Pero también pueden convertirse en el mecanismo mediante el cual una organización elimina una oportunidad antes siquiera de comprenderla.

De ahí nace AVANZA.

Ni enamorarse de la idea, ni matarla demasiado pronto

AVANZA no pretende que aceptemos cualquier idea extraña.

Todo lo contrario.

Busca evitar dos errores frecuentes:

1. Matar una buena idea demasiado pronto.
2. Enamorarnos de una idea sin evidencia.

Entre ambos extremos existe un espacio mucho más interesante: explorar, experimentar y aprender antes de decidir.

Los seis pasos del Método AVANZA

1. Identificar

El primer paso consiste en buscar deliberadamente ideas que desafían lo conocido: señales externas, movimientos de otras industrias, comportamientos emergentes, nuevas tecnologías o soluciones que incluso los propios clientes están inventando.

La pregunta central es:

¿Qué supuesto del negocio actual desafía esta idea?

2. Explorar el valor

Una idea puede no encajar en el modelo actual y, sin embargo, crear valor para alguien.

Por eso la segunda pregunta no es todavía: ¿cuánto dinero produce?

Primero preguntamos:

¿Qué valor aporta y para quién?

El método utiliza como apoyo diferentes tipos de valor: funcional, emocional, cambio de vida e impacto social.

3. Suspender el juicio

Este es probablemente uno de los pasos que más me gustan del método.

Suspender el juicio no significa abandonar el pensamiento crítico.

Significa simplemente cambiar el orden:

Primero entender. Luego opinar.

Una idea frágil necesita suficiente espacio para ser comprendida antes de enfrentarse a las reglas, limitaciones y supuestos del negocio actual.

4. Testear en pequeño

Aquí AVANZA se conecta directamente con una de las ideas centrales de Pruebo luego existo:

No necesitamos construirlo todo para comenzar a aprender.

Podemos usar experimentos pequeños, reversibles y baratos: prototipos, páginas de humo, pilotos, pruebas A/B, simulaciones o cualquier mecanismo que nos permita confrontar una hipótesis con la realidad.

La pregunta es:

¿Cuál es la prueba más pequeña que nos permite aprender con usuarios reales?

5. Evaluar cruzado

Una idea vista únicamente desde finanzas puede parecer completamente distinta cuando la observamos desde tecnología, experiencia de usuario, innovación, estrategia o desde la perspectiva del propio cliente.

Por eso AVANZA propone realizar una evaluación cruzada.

No para forzar consenso.

Sino para ampliar la mirada.

¿Qué valor vemos desde cada perspectiva y qué pasaría si otro lo lanza antes?

6. Desdoblar el camino

Finalmente, AVANZA propone algo que considero particularmente importante:

no todas las decisiones tienen que terminar en un simple sí o no.

Una idea puede entrar en una exploración protegida, donde un pequeño equipo tenga libertad para seguir experimentando.

O puede pasar a vigilancia estratégica, cuando todavía no sea el momento de actuar, pero resulte suficientemente importante como para seguir observándola.

La pregunta final es:

¿Dónde puede crecer esta idea y qué seguimiento necesita?

Del libro a una herramienta que ya puedes usar

Lo que más me interesaba al llevar AVANZA al micrositio era que no se quedara únicamente como una explicación conceptual.

Quería que pudiera utilizarse.

Por eso desarrollé un Evaluador Rápido de Ideas de Autotransformación basado en las seis preguntas del método.

Puedes tomar una idea real de tu organización, recorrer los seis bloques, completar el Canvas y luego descargar el resultado en PDF, copiar el resumen o conservar la información en JSON.

También incluí ejemplos aplicados a diferentes contextos para que sea más sencillo comprender cómo utilizar el método.

Quiero invitarte a probarlo

No solamente a leerlo.

Piensa en alguna idea que haya aparecido recientemente en tu empresa, equipo o negocio.

Idealmente una de esas ideas que generó una reacción como:

“Eso aquí no funcionaría”.

Y antes de descartarla, llévala al Canvas AVANZA.

Pregúntate qué desafía, qué valor podría crear, qué necesitas comprender, cómo podrías probarla con poco riesgo, quién debería evaluarla y qué destino estratégico merece.

Al final quizás descubras que era una mala idea.

Y eso está bien.

Habrás aprendido barato.

Pero también podrías descubrir algo mucho más interesante.

No toda idea extraña es una gran innovación.
Pero ninguna gran innovación debería morir simplemente por parecer extraña.

Este es apenas un primer lanzamiento del método en formato digital. Seguiré evolucionándolo, incorporando aprendizajes, ejemplos y recursos a medida que lo utilicemos en contextos reales.

Si lo pruebas, me interesa especialmente conocer qué funciona, qué no funciona y qué mejorarías.

Saludos ágiles,
Jorge Abad


Notas, aclaraciones, referencias y comentarios

1. Método AVANZA.
AVANZA significa Activación y Validación Ágil de Nuevas Zonas de Autotransformación. El método, su Canvas, ejemplos y recursos se encuentran disponibles en: https://avanza.lecciones-aprendidas.info/

2. Pruebo luego existo.
El Método AVANZA forma parte de mi libro Pruebo luego existo. Puedes encontrarlo en Amazon: Pruebo luego existo .

3. Google y la arquitectura Transformer.
Vaswani, A. et al. (2017). Attention Is All You Need. Google Research. Consultar fuente . El lanzamiento público de ChatGPT se realizó el 30 de noviembre de 2022: OpenAI — Introducing ChatGPT .

4. Kodak y la cámara digital.
Kodak registra entre sus hitos corporativos la invención de la primera cámara digital en 1975. Kodak — Milestones .

5. Xerox PARC, Alto e interfaz gráfica.
El Computer History Museum documenta el desarrollo del Xerox Alto, su interfaz gráfica y la visita del equipo de Apple a Xerox PARC en 1979. Xerox PARC · Xerox Alto .

6. Xerox, Interpress y Adobe.
El Computer History Museum documenta que John Warnock y Charles Geschke desarrollaron Interpress en Xerox PARC y que, después de que Xerox decidiera no comercializarlo, ambos fundaron Adobe. Ese trabajo evolucionó posteriormente hacia PostScript. John Warnock · Charles Geschke .

7. Nokia.
El análisis de Yves Doz para INSEAD describe cómo las decisiones estratégicas, la presión de corto plazo, estructuras organizacionales disfuncionales y el paso de una competencia basada en dispositivos hacia plataformas y aplicaciones contribuyeron al declive de Nokia en teléfonos móviles. INSEAD — The Strategic Decisions That Caused Nokia’s Failure .

8. Microsoft Tablet PC.
En 2001 Microsoft presentó públicamente prototipos de Tablet PC. Bill Gates predijo que este formato podría convertirse en la forma más popular de PC dentro de cinco años. Microsoft — Next-Generation Mobile Computing Is Here · Microsoft — Gates Showcases Tablet PC at COMDEX .

9. Elementos de valor.
El segundo paso de AVANZA utiliza como referencia el marco The Elements of Value, desarrollado por Eric Almquist, John Senior y Nicolas Bloch y publicado en Harvard Business Review en 2016. The Elements of Value .

10. Sobre las imágenes.
Las imágenes utilizadas en este artículo forman parte de los recursos publicados en el micrositio oficial del Método AVANZA.

11. Licencia.
El micrositio publica el Método AVANZA bajo licencia CC BY-SA 4.0.

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.