UX
Construyendo un Sistema de Diseño agéntico
Construí tres Claude skills para optimizar mi flujo de diseño a código. Accidentalmente creé un pipeline RAG para design systems. Con capacidades de auto-reporte, adopción, y UI generativa precisa.
Esto es lo que realmente funciona, y lo que se rompe.
La infraestructura funciona como un compilador: inyectas instrucciones, metadata y valores. Obtienes un toolchain donde la IA consume tu design system con contexto completo.
Son cuatro capas, cada una con herramientas específicas:
Protocol / how: Las instrucciones y ejemplos para la IA. Por ejemplo, cómo buscar un componente, cómo crear uno nuevo.
Structure / where: Indexamos componentes y sus relaciones a nivel macro, y por cada capa atómica. El mapa completo.
Components / what: El código del componente y metadata machine-readable que le indique a la IA la intención, patrones de diseño, casos de uso, dont's.
Tokens / which: Los valores específicos. Esto debe hacer match entre la herramienta de diseño y el codebase.
Esta data ya existe en todo sistema de diseño. Vive en Figma, en tu código, en las convenciones del equipo. La tarea no es inventarla. Es estructurarla para que la IA la pueda parsear.
Lo puse a prueba.
No solo se logró un 58% más velocidad en completar tareas con costos similares.
Pero más importante aún:
Precisión general: 65% → 100%
Descubrimiento de componentes: 77% → 100%
Consistencia: 80% → 100%
Ejemplos reales: cómo el sistema detectó componentes duplicados, encontró brechas de adopción, y generó reportes que típicamente requieren herramientas de $169usd/mes.
También los desafíos de mantenimiento, los bugs que me enseñaron qué importa, y por qué mantener la data fresca es lo más importante.
Esto es dogfooding duro, experimental e iterativo. Probé que la premisa funciona: los design systems pueden ser compilers de decisiones de diseño, no solo catálogos de componentes. Metadata que codifica el por qué, no solo el qué.
La arquitectura es replicable. Los skills son open source. Esto funciona para cualquier codebase con metadata estructurada. Les mostraré cómo lo implementé.
Esto es lo que realmente funciona, y lo que se rompe.
La infraestructura funciona como un compilador: inyectas instrucciones, metadata y valores. Obtienes un toolchain donde la IA consume tu design system con contexto completo.
Son cuatro capas, cada una con herramientas específicas:
Protocol / how: Las instrucciones y ejemplos para la IA. Por ejemplo, cómo buscar un componente, cómo crear uno nuevo.
Structure / where: Indexamos componentes y sus relaciones a nivel macro, y por cada capa atómica. El mapa completo.
Components / what: El código del componente y metadata machine-readable que le indique a la IA la intención, patrones de diseño, casos de uso, dont's.
Tokens / which: Los valores específicos. Esto debe hacer match entre la herramienta de diseño y el codebase.
Esta data ya existe en todo sistema de diseño. Vive en Figma, en tu código, en las convenciones del equipo. La tarea no es inventarla. Es estructurarla para que la IA la pueda parsear.
Lo puse a prueba.
No solo se logró un 58% más velocidad en completar tareas con costos similares.
Pero más importante aún:
Precisión general: 65% → 100%
Descubrimiento de componentes: 77% → 100%
Consistencia: 80% → 100%
Ejemplos reales: cómo el sistema detectó componentes duplicados, encontró brechas de adopción, y generó reportes que típicamente requieren herramientas de $169usd/mes.
También los desafíos de mantenimiento, los bugs que me enseñaron qué importa, y por qué mantener la data fresca es lo más importante.
Esto es dogfooding duro, experimental e iterativo. Probé que la premisa funciona: los design systems pueden ser compilers de decisiones de diseño, no solo catálogos de componentes. Metadata que codifica el por qué, no solo el qué.
La arquitectura es replicable. Los skills son open source. Esto funciona para cualquier codebase con metadata estructurada. Les mostraré cómo lo implementé.