Sesión 2 · Las capas · 23 de abril 2026

Lo que apareció,
lo que se complejizó.

Una reconstrucción interpretativa de la segunda sesión: qué se instaló, qué términos conviene conocer, qué seguir mirando, y una lectura crítica sin complacencia.

No fue una sesión sobre prompts.

La segunda sesión se movió desde la postura general frente a la inteligencia artificial hacia una pregunta más concreta y más exigente: qué significa realmente construir algo con IA. Si la primera instaló una manera de mirar, esta empezó a mostrar el costo real de volver esa mirada una obra.

La sesión abrió con una inquietud filosófica sobre el riesgo de que la eficacia de la IA termine desplazando intuición, criterio y voz humana, y desde ahí aterrizó rápido a una escena cotidiana: correos y respuestas que ya no parecen escritos por personas, sino por máquinas que responden sin terminar de leer el conflicto.

Después retomó la tarea de la sesión anterior: traer el mapa revisado, explicar el proyecto en una oración más precisa, e identificar sus capas, dependencias y posibles puntos de ruptura. Ese paso era clave: dejar de pensar la idea como entusiasmo y empezar a pensarla como arquitectura.

La parte central mostró proyectos reales. Aparecieron simuladores, plataformas de seguimiento, análisis de datos, apoyo escolar, revisión de presupuestos y aplicaciones conectadas a bases de datos. Los casos compartidos —y también los proyectos del facilitador— sirvieron como prueba de posibilidad: personas no técnicas sí pueden construir cosas mucho más complejas de lo que creían.

Pero la intuición pedagógica más importante fue otra: construir con IA no es pedir mejor; es sostener más capas. Detrás de una interfaz simple empiezan a aparecer hosting, dominios, DNS, bases de datos, servicios externos, variables sensibles, autenticación, antifraude, correos transaccionales, despliegues y posibilidad de volver atrás si algo se rompe. La IA ayuda a mirar ese mapa. No lo elimina.

La sesión terminó mostrando justamente eso: que el entusiasmo por la IA sigue siendo razonable, pero que la etapa siguiente ya no es inspiracional. Es infraestructural. Y ahí la curiosidad deja de ser una pose y empieza a parecerse a un oficio.

Cinco aprendizajes.

01
La delegación a la IA no es solo técnica; también puede ser humana. No solo le estamos pidiendo a la máquina que redacte mejor. A veces empezamos a entregarle partes de la respuesta, del criterio y de la atención real al otro.
02
Construir con IA no es solo conversar: es conectar capas. Cuando una idea empieza a volverse producto, aparecen hosting, base de datos, APIs, autenticación, seguridad, despliegue y mantenimiento.
03
Salir del navegador cambia la escala de lo posible. Una cosa es usar IA en una ventana de chat. Otra muy distinta es trabajar con ella en la consola, conectada a archivos, entorno local, nube o servicios reales.
04
Personas no técnicas sí pueden construir cosas importantes. Los ejemplos de la sesión mostraron que alguien sin formación formal en programación puede avanzar muchísimo si sostiene la curiosidad, acepta cierta fricción y aprende a formular mejor el problema.
05
La especificidad del encargo importa más de lo que parece. Pedirle a la IA que "revise" algo no siempre basta. Cuando la instrucción es demasiado general, la herramienta puede pasar por alto errores relevantes.

Términos que aparecieron.

Para que el vocabulario no quede flotando.

Pipeline Una secuencia de pasos conectados entre sí. Una acción activa la siguiente y así se construye un flujo de trabajo más estable.
Agente No solo un chat, sino una lógica más persistente, con rol, memoria, personalidad o tareas específicas dentro de un sistema.
Consola / PowerShell Una interfaz menos amable visualmente, pero mucho más poderosa para ejecutar instrucciones directamente en el computador.
Hosting El lugar donde vive un sitio o una aplicación en internet. Dicho simple: un espacio en la nube donde el proyecto queda disponible.
Vercel Una plataforma de hosting pensada para desplegar proyectos web con rapidez. Fue parte del stack de varios ejemplos mostrados en la sesión.
Supabase Una herramienta para trabajar con base de datos y lógica de backend. Apareció como una de las capas centrales de proyectos ya funcionando con datos reales.
API Una forma de conectar servicios entre sí. Por ejemplo: una página web con WhatsApp, Google Places o un sistema de correos.
Variables de entorno Claves o datos sensibles que el sistema necesita para funcionar, pero que no deben quedar expuestos públicamente en el código.
Captcha Una barrera para distinguir si quien interactúa es una persona o un bot. En la sesión apareció como parte de una lógica antifraude.
Deploy / despliegue Publicar una nueva versión del proyecto para que quede disponible en internet.
Rollback Volver a una versión anterior del proyecto cuando algo se rompe o la actualización genera problemas.
Stack tecnológico El conjunto de herramientas y servicios que sostienen un proyecto: dominio, hosting, base de datos, autenticación, APIs, seguridad y otras capas. Fue probablemente el concepto estructural más importante de esta sesión.
Correo transaccional Correo automático que confirma una acción del usuario: registro, validación, premio, instrucciones o seguimiento.
Semilla de aleatoriedad Una base para producir resultados aleatorios de manera auditable o controlada. Apareció dentro de la lógica de premios del caso mostrado en la sesión.

Lecturas recomendadas.

Cada una dialoga con algo que apareció en la sesión.

Éric Sadin

No para aceptar su tesis sin más, sino para entrar en una pregunta incómoda y necesaria: qué pasa cuando la eficacia técnica empieza a desplazar criterio, intuición y voz humana. Esa pregunta abrió la sesión.

Las lecturas de la Sesión 1 siguen vigentes ↗

Anthropic, OpenAI, Ethan Mollick y UNESCO siguen dialogando bien con este taller. La diferencia es que ahora conviene leerlas ya no solo desde la curiosidad inicial, sino desde el problema más concreto de cómo pasar de una conversación con IA a un sistema que realmente se sostenga.

Lo que funcionó y lo que falta afinar.

La segunda sesión tuvo algo valioso: dejó de vender magia. Mostró cocina, fricción, infraestructura, errores, capas, límites y materialidad. Eso le hizo bien al taller. Bajó la fantasía y subió la verdad. Se sintió menos como charla motivacional y más como el comienzo de un oficio.

Punto 01

La sesión tuvo dos centros y no siempre eligió entre ellos. Por una parte, la pregunta filosófica por la delegación del criterio y la pérdida de voz humana. Por otra, la demostración técnica de cómo se construye un proyecto real.

Punto 02

El material fue más potente que la progresión pedagógica. Los casos mostrados fueron fértiles, pero a ratos la exposición se dejó arrastrar por la fascinación del constructor.

Punto 03

El vocabulario técnico empezó a crecer más rápido que la digestión del grupo. Hosting, Node, Vercel, Supabase, variables de entorno, DNS, rollback, APIs.

Punto 04

La sesión fue mejor como testimonio de construcción que como pieza pedagógica cerrada. Y eso no es un fracaso. Es más bien un síntoma: cuando una idea entra en fase de obra, el lenguaje se ensucia, aparecen capas nuevas y el relato se vuelve menos elegante.

La fisura estructural

La fascinación por la obra en curso.

No por vanidad, sino por intensidad real. Cuando el facilitador ya está construyendo cosas complejas y empieza a mostrar pruebas vivas de posibilidad, el espacio corre el riesgo de girar demasiado alrededor de esa energía. La demostración entusiasma, pero también puede desplazar la progresión del aprendiz.

La consecuencia es delicada: la gente no sale descreída. Al contrario: sale impresionada. Pero no necesariamente con la misma claridad sobre cuál era la lección central de la sesión. Esa observación dialoga además con la autocrítica ya instalada al cierre de la sesión 1: la dificultad para administrarse como flujo.

"A veces la obra que muestras avanza más rápido
que el mapa que el otro necesita."

La tarea del grupo.

Para la Sesión 3

  • Traer el proyecto con una formulación todavía más precisa. No solo qué quiero hacer, sino qué problema concreto resuelve.
  • Intentar reconocer sus capas reales: qué necesita para existir, qué servicios lo sostienen, qué decisiones técnicas o humanas lo vuelven viable.
  • Empezar a distinguir entre idea, prototipo y sistema. No todo lo que funciona una vez está listo para sostenerse en el tiempo.

Autoría

Escrito por Nicolás Steil a partir de la sesión del 23 de abril de 2026.
Co-creado con inteligencia artificial como parte del mismo proceso que enseña.