Video y la app antes del código

Video: cuadros por parches y flujo completo

Si una fotografía se divide en parches espaciales y un audio se divide en segmentos de tiempo, un video combina ambas dimensiones: para el modelo, un video es una secuencia de cuadros a lo largo del tiempo, donde cada cuadro es una imagen dividida en parches.

De los cuadros a los parches (capa de entrada)

Cuando un video entra al tokenizador visual, primero se separa en cuadros (frames) sucesivos y luego cada cuadro se corta en una grilla de parches, igual que una foto fija. En la siguiente animación simplificada, cuatro cuadros del pug en fila se dividen en parches para convertirse en una secuencia de tokens (en un video real, el número de parches y de cuadros es muchísimo mayor):

Como multiplicar cuadros por parches hace crecer rápidamente la cantidad de tokens, procesar todos los cuadros de un video largo sería muy costoso. Por esa razón, los modelos multimodales muestrean cuadros (por ejemplo, leen uno o pocos cuadros por segundo en lugar de los 30 o 60 cuadros originales), lo que abarata el cálculo a cambio de poder perder detalles muy rápidos entre un cuadro y el siguiente.

Son las mismas capas: entrada, modelo compartido y salida en streaming

Al igual que con la imagen y el audio, el video entra por la misma puerta arquitectónica. Un tokenizador de entrada convierte los parches de cada cuadro en vectores dentro del espacio compartido, y el mismo modelo central los procesa junto con el texto o el audio:

En el extremo superior, cuando le pedimos a un modelo que genere o anime un video, la capa de salida arma el video en streaming, cuadro por cuadro y parche por parche, transformando los vectores que salen del modelo en cada fotograma de la secuencia:

Al juntar todas las piezas vemos el flujo completo en video: entran cuadros cortados en parches por la capa de entrada, el modelo compartido procesa los vectores y la capa de salida arma la secuencia de cuadros.

Qué entra y qué sale en video

Según qué modalidad entregamos en la entrada y qué necesitamos en la salida, las tareas con video se agrupan en cuatro combinaciones principales:

IA para apps: pensar la aplicación antes del código

Una vez que comprendemos cómo los modelos procesan texto, imagen, audio y video, podemos dar el siguiente paso del curso: usar agentes para construir una aplicación. Antes de pedirle al agente que escriba código, conviene distinguir las dos mitades técnicas de cualquier aplicación , recorrer tres etapas de preparación y dejar por escrito las decisiones de interfaz.

Conceptos técnicos básicos: Frontend y Backend

Toda aplicación web o móvil se divide en dos partes que cumplen funciones complementarias:

• Frontend (lo que se ve y se toca): es toda la parte visible con la que interactúa directamente la persona en su pantalla o navegador. Incluye la disposición de cada vista, los botones, los formularios, los colores, las tipografías y cómo responde la interfaz ante cada clic. En esta primera etapa nos enfocamos sobre todo aquí, porque define la experiencia de uso y el flujo de trabajo.
• Backend (lo que ocurre detrás de la pantalla): es la capa que corre en un servidor o servicio externo. Se encarga de guardar datos en una base de datos, aplicar las reglas del negocio, verificar permisos de usuario y conectarse con APIs externas o modelos de IA. Mientras el frontend muestra y recoge información, el backend la procesa y la persiste para que siga disponible al volver a abrir la aplicación.

Antes del código: las tres etapas de preparación

El error más común al programar con un agente es abrir una sesión vacía y pedirle de inmediato que construya la aplicación entera. Cuando hacemos eso, el modelo rellena cada vacío con decisiones genéricas. Un flujo ordenado empieza con tres pasos de preparación. Después vienen las decisiones de interfaz, también antes de escribir código:

1. Brainstorming: explorar varias propuestas de solución dentro de la misma sesión para abrir el abanico de ideas.
2. Moodboard: reunir en un tablero visual los colores, tipografías y referencias de interfaz para que el agente multimodal lea el estilo buscado.
3. Spec (el plan de implementación): destilar qué hará exactamente la aplicación y cómo responderá ante los casos borde (edge cases) en un documento persistente.

Brainstorming en la misma sesión

La primera etapa consiste en pedirle al agente varias propuestas distintas dentro de una misma sesión de conversación, antes de comprometerse con una sola pantalla.

• Por qué hacerlo en la misma sesión: como las respuestas anteriores quedan acumuladas en el contexto usado, el modelo no vuelve a repetir la continuación más probable y se ve empujado a explorar enfoques de interfaz genuinamente distintos entre sí.
• Qué pedirle al agente: que proponga 3 o 4 maneras diferentes de resolver el problema del usuario (por ejemplo, una vista de tarjetas con etiquetas de estado, una tabla filtrable o un asistente paso a paso), explicando qué ventaja tiene cada alternativa.
• Qué decides tú: cuál de esas propuestas resuelve la tarea real con menos fricción, qué elementos vale la pena combinar y qué ideas descartar antes de pasar al diseño visual.

Para guiar esta conversación sin saltar prematuramente al código, puedes usar la skill brainstorming en skills.sh, que instruye al agente para formular preguntas clave, presentar alternativas comparables y acordar el diseño con la persona.

Moodboard: fijar la dirección visual con un modelo multimodal

Un moodboard (tablero de inspiración) es una lámina visual que fija cómo se ve y se siente la aplicación antes de construir su frontend. Si le pedimos a un agente una interfaz "moderna y limpia" solo con palabras, cada ejecución interpretará esos adjetivos de forma distinta. En cambio, cuando reunimos colores, tipografías y pantallazos de referencia en una imagen, aprovechamos que el modelo es multimodal: el agente lee directamente esas referencias visuales y las traduce en componentes, espaciados y estilos concretos.

Cómo armar un moodboard rápido en la práctica

Armar un moodboard útil para un agente no requiere programas complejos de diseño gráfico; basta con una lámina de Google Slides, PowerPoint o una página en Google Docs:

1. Pega 2 o 3 pantallazos de aplicaciones o sitios web reales que te gusten y escribe una nota breve al lado indicando qué rescatas de cada uno (por ejemplo, "me gusta este orden de tarjetas" o "todo en una sola pantalla dividida").
2. Agrega 3 o 4 colores (para el fondo, el texto principal y los acentos o estados) junto con el nombre de la tipografía para títulos y lectura.
3. Saca un pantallazo o expórtalo como PNG/PDF y adjúntalo en tu conversación con el agente para que construya la interfaz siguiendo esa lámina.

En skills.sh puedes combinar tu moodboard con tres skills complementarias para el frontend:

• frontend-design (Anthropic): guía la dirección estética, el uso de color, la escala tipográfica y la composición visual de la interfaz.
• web-design-guidelines (Vercel Labs): audita que la interfaz resultante cumpla buenas prácticas de contraste, jerarquía, estados de foco y accesibilidad.
• shadcn: permite componer y estilizar componentes de interfaz consistentes sobre la paleta y tipografía elegidas.

Spec: el plan de implementación con expandir y contraer

Una vez decidida la idea en el brainstorming y definida la apariencia en el moodboard, llegamos al tercer pilar antes de programar: la spec (especificación). A grandes rasgos, la spec es el plan de trabajo e implementación de la aplicación: un documento que deja por escrito qué pantallas existen, qué entra y qué sale en cada acción del usuario, cómo se divide el trabajo entre frontend y backend, y qué debe ocurrir en los casos borde (edge cases, como un archivo que no abre, un campo vacío o un dato incompleto).

Expandir y contraer el contexto hacia un plan persistente

Para construir una buena spec sin contaminar la sesión en la que luego escribiremos el código, aplicamos la lógica de expandir y contraer el contexto llevada a un archivo de trabajo persistente:

1. Expandir en la conversación: dialogamos con el agente para explorar los requisitos, destapar preguntas pendientes, definir el flujo de pantallas y enumerar los casos borde. Durante esta exploración el contexto usado crece con borradores, preguntas y descartes.
2. Contraer en un archivo del proyecto: cuando el diseño y las reglas están claros, le pedimos al agente que destile todos los acuerdos en un documento limpio y estructurado guardado en el repositorio, como SPEC.md o PLAN.md.
3. Persistir y ejecutar en sesiones limpias: cerramos el hilo exploratorio y abrimos una sesión nueva que lee directamente SPEC.md (y el moodboard) para implementar el plan etapa por etapa, libre del ruido de la discusión inicial.

Para estructurar ese documento de trabajo antes de programar, la skill writing-plans en skills.sh toma los requisitos de la spec y los convierte en un plan de implementación ordenado por pasos verificables.

Diagramas: el flujo antes de programarlo

Un diagrama representa un flujo, una estructura o los estados de una app. Sirve para detectar un paso que falta y para conversar sobre el comportamiento antes de programarlo.

Mermaid convierte ese acuerdo en texto. Le pedimos al agente el diagrama, revisamos cada decisión y guardamos el archivo junto al proyecto. La skill mermaid elige el tipo de diagrama, lo escribe en Markdown y valida que la sintaxis se pueda dibujar. La documentación oficial de Mermaid describe el lenguaje.

El ejemplo es hipotético: la inscripción a una sección. La persona elige una sección. Si hay cupos, confirma la inscripción. Si no hay cupos, la app muestra alternativas.

Diagrama en Mermaid

flowchart TD
  A[Elegir sección] --> B{Hay cupos?}
  B -->|Sí| C[Confirmar inscripción]
  B -->|No| D[Mostrar alternativas]

Wireframes: la estructura de la pantalla

Un wireframe es un bosquejo de una pantalla. Ordena el contenido y las acciones. El color y el estilo final vienen después.

Podemos empezar con lápiz y papel, o con FigJam o Figma. También podemos pedirle al agente un HTML de baja fidelidad para comparar alternativas. La skill wireframe produce un bosquejo en blanco y negro: qué va en cada zona, en qué orden y a qué tamaño. Nielsen Norman Group publica una lectura sobre wireframes.

Antes de elegir la herramienta, respondemos cuatro preguntas:

• Qué necesita hacer la persona.
• Qué información debe ver para decidir.
• Cuál es la acción principal de la pantalla.
• Qué pasa cuando falta información o algo falla.

Design systems: reglas y componentes en un lugar común

Un design system reúne reglas visuales y componentes reutilizables: colores, tipografía, espaciado, botones, campos y patrones de interacción. Una decisión vive en un lugar común y las pantallas nuevas la reutilizan.

Dos skills acompañan este paso. frontend-design fija paleta, tipografía y composición con una dirección visual clara. shadcn revisa los componentes ya instalados y agrega botones, campos y diálogos como código del proyecto. Material Design publica los fundamentos de un sistema visual de referencia.

Al agente le pedimos tres cosas:

• Identificar los componentes y estilos ya disponibles.
• Usar esos componentes en las pantallas nuevas.
• Registrar las reglas que todavía debemos decidir.

UI y UX: la interfaz y el recorrido

La UI es la interfaz que vemos y usamos. La UX es el recorrido completo de la persona al cumplir una tarea.

La skill web-design-guidelines revisa la interfaz contra las pautas de Vercel: diseño, accesibilidad y experiencia de uso. En la inscripción a una sección, por ejemplo, miramos cuatro puntos del recorrido:

• Si se entiende qué sección está seleccionada.
• Si la app confirma que la inscripción quedó guardada.
• Qué mensaje aparece cuando ya no quedan cupos.
• Si el flujo se puede completar con teclado.

Textos de interfaz

El copy de una interfaz incluye los nombres de botones, las instrucciones, las confirmaciones, los mensajes de error y los estados vacíos. La skill ux-writing-content-design escribe y revisa esos textos, y cuida el vocabulario del sistema.

El botón nombra la acción. Guardar es un nombre genérico. Confirmar inscripción dice la acción en el botón. Si algo falla, el mensaje explica qué pasó y qué puede hacer la persona.

Lo que queda por escrito antes del código

Un diagrama deja el flujo. Un wireframe deja la estructura de cada pantalla. Un design system deja las reglas visuales. La revisión de UI y UX recorre la tarea. El copy orienta cada acción.