+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
El problema que nadie ve venir
Un cliente nos llamó hace unos meses. Acababa de integrar una herramienta IA en su workflow de producción web. ¿El resultado? La IA generaba código. Mucho código. Rápido. Pero ninguno de los componentes producidos correspondía a su design system existente. Colores aproximados, espaciados incoherentes, tipografías aleatorias. Había que rehacer todo a mano.
¿Cuántas horas perdidas para corregir lo que la IA había “creado”?
Este escenario lo vemos cada vez con más frecuencia. Los equipos adoptan herramientas IA para acelerar su producción — Copilot, Cursor, Claude Code, v0.dev — sin haber preparado el terreno. Y su design system, concebido en una época en que un desarrollador leía cada línea, se convierte en un lastre. Exploramos este tema desde el ángulo técnico en nuestro artículo sobre el design system listo para la IA y el centrado CSS que sus integradores siguen haciendo a mano.
Un design system no estructurado para la IA es un freno disfrazado de acelerador.
Aquí le explicamos cómo evitarlo. Concretamente, con acciones aplicables hoy.
Por qué su design system actual ya no es suficiente
La mayoría de los design systems se construyeron para humanos. Un desarrollador abre Figma, lee la documentación, entiende el contexto, toma decisiones. Interpreta. Se adapta.
La IA no hace eso.
Un modelo de lenguaje o una herramienta de generación de código trabaja a partir de tokens, patrones, estructuras. Necesita instrucciones explícitas, no ambiguas, sistemáticas. Cuando su design system dice “usar los colores de la marca”, la IA no sabe qué significa eso sin los valores hexadecimales precisos, los contextos de uso, las reglas de combinación.
Lo que vemos concretamente con nuestros clientes: design systems visualmente ricos en Figma, pero prácticamente inutilizables por una IA porque están documentados en lenguaje natural, sin estructura machine-readable.
La documentación bonita no vale nada si no es legible por una máquina.
Tres problemas recurrentes:
- Los tokens de diseño (colores, espaciados, tipografías) existen en Figma pero no se exportan en un formato estructurado (JSON, propiedades personalizadas de CSS, design tokens W3C)
- Las reglas de composición son implícitas — viven en la cabeza de los diseñadores, no en la documentación
- Los componentes no tienen una nomenclatura coherente entre Figma, el código y la documentación
Los cuatro pilares de un design system AI-ready
Pilar 1: los tokens de diseño como fuente única de verdad
Si solo hace una cosa después de leer este artículo, es esta.
Los design tokens son la traducción de sus decisiones visuales en valores con nombre y estructurados. No #1A73E8, sino color.brand.primary. No 16px, sino spacing.md. Esta nomenclatura semántica permite a una IA entender no solo el valor, sino la intención detrás de él — exactamente lo que transforma una identidad visual en un sistema explotable por la máquina.
El estándar que se está imponiendo actualmente es el formato W3C Design Tokens. Estructura sus tokens en JSON con metadatos: tipo, valor, descripción, contexto de uso. Herramientas como Style Dictionary o Tokens Studio para Figma permiten sincronizar estos tokens entre su archivo de diseño y su codebase.
Resultado concreto: cuando le da a Claude Code o a Cursor acceso a su archivo de tokens, genera código que respeta automáticamente su guía de estilos. Sin más colores aproximados. Sin más espaciados inventados.
“Los tokens no son una restricción técnica adicional. Son la traducción de su identidad visual en un lenguaje que la IA puede leer.” — Práctica cotidiana en GDM-Pixel desde hace 18 meses.
Pilar 2: una nomenclatura coherente entre todas las herramientas
La IA trabaja por correspondencia de patrones. Si su componente se llama CardProduit en Figma, product-card en su CSS y ProductTile en su React, tiene tres entidades distintas para la IA. No establecerá la conexión.
La regla es simple: un componente, un nombre. En todas partes.
Elija una convención — BEM, camelCase, kebab-case — y aplíquela sistemáticamente en Figma, en su código, en su documentación. Esta coherencia permite a las herramientas IA navegar entre contextos sin perder el hilo.
En nuestros proyectos Astro + Tailwind, usamos nomenclatura kebab-case en todas partes. Cuando Claude Code genera un componente, encuentra inmediatamente su correspondencia en el design system. Ahorro de tiempo: real, medible, inmediato.
Pilar 3: documentar las reglas, no solo los componentes
Un design system clásico muestra qué. Un design system AI-ready explica por qué y cuándo.
¿La diferencia? Su documentación debe incluir:
- Las reglas de uso (este componente se usa únicamente para acciones primarias)
- Las restricciones (nunca combinar este fondo con este texto por razones de accesibilidad)
- Las variantes permitidas y prohibidas
- Los contextos de aplicación (móvil, escritorio, modo oscuro)
Esta información, estructurada en Markdown o en JSON, se convierte en instrucciones directamente inyectables en un prompt de IA. Trabajamos con archivos de contexto que pasamos a Claude Code al inicio de cada sesión. Resultado: el modelo conoce nuestras restricciones antes de escribir la primera línea.
Pilar 4: versionar y mantener como código
Un design system que no está versionado es un design system que deriva.
Con la IA en el bucle, este problema se amplifica. Si sus tokens cambian pero su IA sigue trabajando con la versión anterior, produce incoherencias a velocidad industrial. La IA lo acelera todo — incluyendo los errores.
La solución: su design system debe vivir en un repositorio Git, con releases numeradas, un changelog claro y una integración en su pipeline de CI/CD. Cuando un color cambia en su guía de estilos, el cambio se propaga automáticamente — en el código, en la documentación y en los contextos que proporciona a sus herramientas IA.
Lo que esto cambia concretamente en la producción
Permítame darle un ejemplo de campo.
En el proyecto Nova Mind — nuestro propio SaaS — estructuramos nuestro design system con tokens W3C, una nomenclatura unificada Figma/Astro y archivos de contexto Markdown por tipo de componente. Cuando abrimos una sesión de Claude Code para desarrollar una nueva pantalla, inyectamos estos archivos como contexto.
El modelo genera componentes que respetan nuestra paleta, nuestros espaciados, nuestras reglas tipográficas — sin que tengamos que recordarlos en cada prompt. Corregimos la lógica de negocio, no el estilo. Ese es el uso correcto de la IA: ella ejecuta las reglas, usted concibe la estrategia.
Antes de la estructuración: del 40 al 60% del tiempo de revisión se dedicaba a la coherencia visual. Después: menos del 10%.
No es una estimación. Está medido en nuestros últimos proyectos entregados.
“La IA no reemplaza su design system. Revela sus fallos — los que no veía porque sus desarrolladores los compensaban intuitivamente.”
Por dónde empezar si parte de cero (o casi)
¿Tiene un design system existente pero no estructurado? Aquí hay un camino realista, sin rehacerlo todo de golpe.
Paso 1 — Auditar sus tokens existentes. Haga un inventario de todos los valores de color, espaciado y tipografía utilizados en su codebase. Herramientas como Style Dictionary o una simple búsqueda en su CSS le dan una visión general en pocas horas.
Paso 2 — Nombrar y estructurar. Transforme sus valores brutos en tokens semánticos. #2D3748 se convierte en color.neutral.800. Exporte a JSON. Sincronice con Figma si lo usa.
Paso 3 — Escribir las reglas de uso en Markdown. Para cada componente principal, un archivo .md con: descripción, casos de uso, variantes permitidas, restricciones de accesibilidad. Simple, directo, machine-readable.
Paso 4 — Integrar en su workflow de IA. Cree una carpeta /context en su proyecto con sus tokens y reglas. Referenciarlos en sus prompts o configurarlos como contexto persistente en su herramienta IA.
Paso 5 — Versionar. Git + changelog. Desde el primer día.
Los errores que hay que evitar absolutamente
Hemos cometido algunos. Mejor que usted no pase por el mismo dolor.
Querer estructurarlo todo a la vez. Un design system AI-ready se construye de forma iterativa. Empiece por los tokens de color y espaciado — ahí es donde la IA comete más errores. El resto viene después.
Descuidar la documentación de las excepciones. Su IA aplicará las reglas generales al pie de la letra. Si tiene excepciones no documentadas, no las conoce. Documente los casos particulares con tanto cuidado como los casos estándar.
Separar la responsabilidad de diseño y desarrollo. Un design system AI-ready es un proyecto común. Si el diseñador evoluciona los tokens en Figma sin sincronizar con el código, pierde la coherencia que tardó tiempo en construir. Proceso común, herramienta común, responsabilidad compartida.
La pregunta que debería hacerse ahora
Su design system actual — si tiene uno — ¿está documentado de forma que una IA pueda leerlo y aplicarlo sin interpretación?
Si la respuesta es no, o si no está seguro, es el buen momento para actuar. No porque la IA sea una moda. Sino porque las herramientas IA ya están en los workflows de producción web, y su eficacia depende directamente de la calidad de la estructura que se les proporciona.
Un design system no estructurado con la IA en el bucle supone trabajo doble. Un design system AI-ready es un multiplicador de productividad real — el mismo artesanado invisible del código y la UX que separa un buen sitio de un sitio que funciona de verdad.
En GDM-Pixel, invertimos tiempo en estructurar nuestros propios sistemas antes de integrarlos en nuestros workflows de IA. Ese tiempo de inversión lo recuperamos a partir del segundo proyecto. Y seguimos recuperándolo en cada entrega.
¿Quiere estructurar su design system para la IA, o auditar su workflow de producción web actual? Contáctenos — le damos un diagnóstico honesto, sin venderle una refactorización innecesaria.
Redes sociales
Analizar con IA
