AI Lab · shipped-locally
Premier Push: del taller al método
Relato del diseño de un taller code-first de 3 horas y media: cada diseñador del equipo reimagina el dashboard de PrestaShop con PUIK y Claude Code, en su propia rama, y luego hace su primer push de Git. La apuesta de partida: una transformación no se transmite contándola, se hace vivir.
La apuesta de partida
El miedo al code-first no se razona, se atraviesa. Esa convicción viene de una experiencia personal: mi primer push de Git, hecho construyendo este sitio, y la frase que quedó en la memoria: ‘tenía miedo, fue magnífico’. La petición inicial del taller era simple: hacer que el equipo de diseño perdiera el miedo al code-first y a la IA. La trampa clásica habría sido un taller que explica, con slides, un retorno de experiencia, buenas prácticas. Pero un relato no hace atravesar nada. La apuesta de Premier Push: diseñar un taller que no cuenta un recorrido de aprendizaje sino que lo hace vivir, en varias versiones paralelas dentro de la misma sala.
El diseño mismo del taller siguió la doctrina ‘auditoría antes que solución’. La materia prima existía: una docena de learning debriefs personales, esas notas donde cada experimento documentado se vuelve reutilizable. Y antes de cualquier propuesta de formato, el co-diseño con Claude pasó por doce preguntas críticas: la realidad técnica del equipo, su dinámica, el lugar estratégico del taller. Partir de lo que existe, no de una página en blanco.
Un artefacto que todos conocen y nadie posee
Tres rutas se descartaron antes de encontrar el buen tema. Un producto lúdico y desconectado: el taller habría perdido su seriedad. La pantalla de una squad: una invasión, alguien en la sala ya es dueño de ese territorio. Un repo starter genérico: el entregable habría sido desechable. El dashboard de PrestaShop marca las tres casillas inversas. Todo el mundo lo conoce, nadie lo posee, y se puede mejorar. Ese es el sweet spot del tema de taller colectivo: un artefacto compartido, neutro, real.
La misma lógica del lado del design system: PUIK, el design system open source de PrestaShop, instalado vía npm en lugar de clonar el monorepo, para que la instalación no se coma el día D. La stack: Vue 3, Vite, TypeScript, Tailwind 4. Trabajar sobre el design system real abre una puerta adicional: un componente nacido durante el taller puede volverse candidato para PUIK. Nada de lo que se construye ese día es un ejercicio desechable.
Tres archivos .md como columna vertebral
La intuición más estructurante del diseño: los archivos markdown no son un meta-instrumento, son el medio pedagógico. Tres archivos, tres funciones. product.md encuadra el qué: contexto, restricciones, entregables, el mismo brief para todo el mundo. CLAUDE.md encuadra el cómo: reglas PUIK, convención de commits. JOURNAL.md captura el porqué: qué decisiones de diseño, por qué razones. Sin el journal, el taller se quedaría en lo técnico. Con él, documentar las decisiones propias se vuelve un entregable por derecho propio. Y esos archivos no se aprenden escuchando a alguien describirlos: se aprenden habitándolos durante tres horas.
Ese journal es también la proyección de una práctica personal a la escala del equipo: la miniatura de mi base de learning debriefs. Potente y delicado a la vez, porque lo que funciona en solitario puede volverse una carga en grupo. La protección elegida: Claude Code llena el journal durante las micro-pausas, el diseñador valida. La documentación se hace, la energía se queda en el diseño.
Tres horas y media, tres ejercicios, un push
El desarrollo del 20 de mayo de 2026: ocho minutos de puesta en contexto sobre lo que cambia de verdad (el rol, no la herramienta), treinta segundos de matiz (‘este método es una forma de hacer, no la forma’), cinco minutos de demo en vivo. Luego tres ejercicios: reimaginar la pantalla por defecto del dashboard (60 minutos), trabajar sus estados (45 minutos), hacer el primer push (20 minutos). Entre los hitos, micro-pausas de tres minutos donde la IA llena el journal y hace commit.
Una decisión de diseño pesa más que las otras: el push es un objetivo, no una prueba de paso. Nadie fracasa en Premier Push. Esa es la diferencia entre un taller que transforma y un taller que filtra. La duda existió durante el diseño (‘el push, ¿no será demasiado?’) y la respuesta fue defender el sentido en lugar de recortar el alcance: ese push es el que le da su nombre al taller, ahí está el punto de quiebre.
El cierre: la galería colectiva. En pantalla grande, se pasa de rama en rama y desfilan seis versiones del mismo dashboard, una por cada diseñador del equipo, facilitadora incluida. El mismo brief, el mismo design system, seis respuestas que no se parecen. Después el debrief, cuatro preguntas: qué te sorprendió, qué te marcó, qué te llevas, qué haces mañana.
Lo que resistió
El ratio de preparación, primero: diez días de trabajo para tres horas y media de taller. Parece desproporcionado, en realidad es la condición del formato. Todo lo que se pueda hacer antes debe hacerse antes (script de verificación de prerrequisitos, una rama por participante, mensaje de Slack en dos tiempos para separar la logística de la preparación cognitiva), o el día D se convierte en un taller de instalación.
El formato, después: la pista de una jornada completa se abandonó, porque el cansancio habría matado la galería final, el momento más valioso. Tres horas y media es lo que protege la energía hasta el final.
El journal, por último, quedó bajo vigilancia hasta el día D: pre-estructurado pero liviano, llenado por la IA, validado por el diseñador. La trampa identificada desde el diseño: que nunca se volviera una tarea para la casa.
De ‘mi taller’ a ‘nuestro método’
La parte más fuerte de esta historia no es el taller, es lo que viene después. Un taller exitoso que se queda en las manos de una sola facilitadora no es un método, es una performance. El retorno de experiencia se formalizó entonces en ocho ingredientes reutilizables: la puesta en contexto estratégica, el matiz inicial, la demo en vivo, el brief único, los ejercicios con hitos y micro-pausas, el push autónomo, la galería colectiva, el debrief en cuatro preguntas.
Luego esos ingredientes se volvieron una herramienta: un prompt que cualquier diseñador experto del equipo puede pegar en Claude para co-diseñar su propio taller, sobre su propio dominio. La arquitectura cabe en cuatro bloques. Un rol: la IA es co-diseñadora de experiencia de aprendizaje, no experta del tema, esa expertise se queda con el diseñador. Un contexto: los ocho ingredientes. Una tarea en tres etapas: planteamiento por preguntas, entrega de un brief completo minuto a minuto, iteración. Y salvaguardas, con una central: la IA nunca produce el contenido pedagógico en lugar del diseñador y no lo reemplaza en la facilitación.
La primera versión derivada ya está en marcha: una content designer del equipo prepara la suya sobre el tono y la voz. Y ese es exactamente el punto: diseñar una capacitación se vuelve un acto de liderazgo accesible a cada diseñador experto, no un privilegio de facilitadora. Tres beneficios se acumulan: la escalabilidad (los talleres ya no me necesitan para existir), la visibilidad (cada diseñador porta públicamente su expertise), la coherencia (una gramática pedagógica común, es decir un vocabulario compartido sobre qué es una buena capacitación interna).
Lo que esto dice del enablement IA de un equipo de diseño
El enablement, es decir el camino de un equipo hacia la autonomía en una práctica nueva, sufre de un malentendido persistente: creemos transmitir contenido cuando lo que se transmite es una experiencia. Un diseñador que escucha a alguien contar su primer push no atravesó nada. Un diseñador que escribe su propio git push, ve aparecer su rama y ve su dashboard en la galería cambió su relación con el código. Es la misma distancia que hay entre leer una receta y cocinar el plato.
Segunda lección: el tema hace la mitad del trabajo. Un artefacto que todos conocen pero que nadie posee le da a cada quien la legitimidad de tocarlo, y a nadie el reflejo de defenderlo. La divergencia de las seis versiones viene de ahí: el brief era común, el territorio era libre.
Tercera lección: la transmisión escalable no se decreta, se equipa. Sin la parte 2, Premier Push se habría quedado en un buen recuerdo de equipo. Con el prompt de adaptación, es una V1 de método, con todo lo que eso implica de inacabado.
Y la pregunta sigue abierta, la que decidirá si Premier Push es un método o un recuerdo: ¿esto vive sin mí? Se volvió literal en el verano de 2026, con mi salida del equipo: los talleres que se hagan de ahora en adelante se harán sin mí, con el prompt-herramienta como única herencia. El día en que uno de ellos ocurra, el paso de ‘mi taller’ a ‘nuestro método’ quedará probado, no solo contado.