Todo developer tiene ese proyecto. En el que te convencés de que estás resolviendo un problema real, te metés en el rabbit hole, construís algo genuinamente interesante — y luego descubrís que el problema ya estaba resuelto. La diferencia esta vez: gracias a la AI, no fueron semanas. Fueron días. Esto es esa historia de todas formas.
El Problema (Que Creí Tener)
El workflow entre agentes de AI y diseño de UI está roto. Cuando un agente AI construye una UI, escribe código a ciegas. No puede ver el diseño. No puede verificar que lo que generó se parece a lo que vos querías.
Mi inspiración fue Pencil.dev — una herramienta propietaria que cierra esta brecha dejando que agentes AI interactúen con diseños visualmente. La idea era buena: AI diseña → Screenshot → AI codea. Humano revisa → Notas → AI itera.
Pero Pencil es closed source y requiere suscripción. Diay, la pregunta fue inevitable: ¿y si construyo la versión open-source?
Me Puse a Construir Sand 🏖️
Sand es un editor de diseño AI-native donde los diseños renderizan componentes React reales — no aproximaciones vectoriales. Lo que se ve en el canvas es literalmente lo que se va a construir.
Está en github.com/kno-raziel/sand-canvas.
La Idea Central
La mayoría de herramientas de diseño (Figma, Sketch) usan primitivas vectoriales. Dibujás un "botón" pero es solo un rectángulo con bordes redondeados. Sand invierte esto: los componentes son la primitiva. Ponés un Button de daisyUI en el canvas y estás viendo el componente React real, renderizado en un browser, con todos sus tokens de tema aplicados.
Esto importa para AI porque los screenshots de componentes reales son inputs de mayor fidelidad para la generación de código.
Cómo Funciona
Los agentes controlan Sand a través de 13 herramientas MCP (Model Context Protocol):
| Herramienta | Qué hace |
|---|---|
batch_design | Insertar, actualizar, eliminar, copiar nodos en el canvas |
batch_get | Leer la estructura del documento |
get_screenshot | Capturar un PNG de cualquier nodo |
open_document | Cargar archivos .sand |
get_variables / set_variables | Gestionar tokens de diseño y temas |
reply_conversation | Responder comentarios en el canvas |
| …y 7 más | Análisis de layout, espacio libre, ediciones masivas |
Lo Que Construí
- Rendering real de componentes — adaptador daisyUI 5 con 30+ componentes
- Auto-layout Flexbox — gap, padding, alineación, sizing
fill_container - Temas & Variables — tokens de diseño con soporte dark/light multi-tema
- Breakpoints responsive — pantallas Desktop / Tablet / Mobile en paralelo
- Notas & comentarios — conversaciones threaded para el loop humano ↔ agente
- Formato
.sand— JSON puro, validado con Zod, amigable con Git - Undo/Redo — historial completo con Immer patches
El Sistema de Adaptadores
Una de las decisiones que más me gustó: el patrón de adaptador. Cualquier librería de componentes React se puede enchufar. El adaptador de daisyUI usa un CSS-Class Engine — cada componente son ~10 líneas de datos declarativos:
{
name: "Button",
element: "button",
baseClass: "btn",
modifiers: {
variant: { prefix: "btn-", values: ["primary", "secondary", "accent"] },
size: { prefix: "btn-", values: ["xs", "sm", "md", "lg"] },
},
content: "label",
}
El engine auto-genera schemas Zod, defaults y funciones de render desde ese spec. Agregar un componente nuevo es tarea de 10 minutos.
Así quedó Sand con el demo de landing page de café:
Entonces… ¿Por Qué Storybook?
La respuesta honesta: Storybook ya resolvía esto — y ya lo tenía en el monorepo.
Al revisar el workflow con más calma, caí en cuenta que el monorepo ya incluía Storybook como una app independiente (apps/storybook). No solo para testing, sino como catálogo vivo de componentes: cada story, co-localizada junto al componente en packages/design-system, es documentación interactiva con props, variantes y ejemplos reales.
Y resulta que Storybook tiene su propio servidor MCP oficial (@storybook/addon-mcp). Eso cambia todo:
| Feature de Storybook MCP | Qué habilita |
|---|---|
| Descubrimiento de componentes | El agente lista todos los componentes disponibles con props y variantes |
| Generación de código desde stories | El agente sugiere el componente correcto basado en descripción |
| Previsualización viva de stories | El agente devuelve URLs exactas para verificar visualmente el UI |
| Testing de interacción y accesibilidad | El agente ejecuta tests, identifica fallas y propone correcciones |
| Extracción de documentación | Tipos, defaults y descripciones en formato legible para LLMs |
El mismo workflow que construí desde cero con Sand — agente ve componentes → expone preview → escribe código → humano revisa — ya existía, probado en producción, sobre infraestructura que ya mantenía.
Una nota al pie (meta y real): Durante la escritura de este mismo párrafo, mi agente IA de asistencia intentó agregar "Screenshots automáticos" a la tabla de arriba. Estaba cruzando features de un repositorio viejo de la comunidad con el oficial. Sirve como prueba irrefutable del punto principal de todo este experimento: el loop necesita un humano al final curando el resultado. La IA propone, el human in the loop verifica.
Sand tiene un emoji divertido en el README. 🏖️
La Lección: Los POCs Son Baratos Ahora
Acá es donde se pone interesante. Con la IA como ejecutora, el desarrollo real de una idea como Sand tomó unas pocas horas repartidas en 3 días (del 25 al 27 de febrero) — algo que sin esa asistencia hubiera requerido meses. Los días restantes fueron para demos, documentación y preparación para publicación.
Esto cambia la economía del software. POCs que antes requerían un equipo dedicado y meses de runway ahora se pueden validar en días. El costo de estar equivocado bajó dramáticamente.
La Pregunta Abierta
Si la AI hace que el tooling custom sea tan barato de construir, se plantea una pregunta genuina para estudios pequeños:
¿Por qué un estudio pequeño debería pagar por herramientas closed source, cuando un equipo con AI puede construir el workflow hecho a la medida?
No todo equipo necesita una licencia de Figma. No todo workflow encaja en el modelo de Storybook. Con AI como aliado en la construcción, ahora es posible costear la herramienta que se ajusta al contexto propio — el stack, el idioma, el proceso. Tropicalizada, como decimos en Costa Rica: adaptada a las condiciones locales, no enviada desde Silicon Valley asumiendo requisitos universales.
Sand 🏖️ sí era el reemplazo — de Figma, de Pencil, para mi workflow personal. El POC funcionó exactamente como se supone que debe funcionar un POC: rápido, honesto, descartable. Solo que la respuesta fue 'ya existe y ya lo tenés...'. Y eso, en tiempo de AI, salió barato.
Este artículo fue escrito y revisado con asistencia de IA, y parte de las ilustraciones fueron generadas con IA — lo que en sí mismo es una demostración del flujo que describe.