De las variables CSS al DESIGN.md: cómo los Design Systems están aprendiendo a hablar con la IA
Cómo DESIGN.md está redefiniendo la forma en que los equipos de producto mantienen consistencia visual cuando trabajan con agentes de IA. Análisis desde la trinchera.
Una conversación que en Dribba hemos tenido demasiadas veces en los últimos doce meses. Va más o menos así:
"El agente me ha vuelto a cambiar los border-radius."
"Sí, y el padding de los cards ya no cuadra con nada."
"¿Usó Inter o Manrope esta vez?"
"Las dos. En la misma pantalla."
Si trabajas con agentes de IA para generar o iterar interfaces —Cursor, Claude Code, Copilot, lo que sea— esta conversación te resultará familiar. Y si no la has tenido todavía, es porque aún no has llegado a ese punto del proyecto donde la deuda de inconsistencia empieza a doler.
Durante años, los Design Systems fueron la respuesta a un problema interno de los equipos: cómo hacer que diez personas distintas produzcan interfaces que parezcan salir de la misma cabeza. Hoy ese problema tiene una dimensión nueva: cómo hacer que una IA produzca interfaces que respeten lo que hemos definido nosotros, y que lo haga de forma consistente entre sesión y sesión.
DESIGN.md es la propuesta más concreta que ha aparecido hasta ahora para resolver eso. Y merece un análisis serio.
Un poco de historia: de la hoja de estilos al sistema vivo
Para entender por qué DESIGN.md importa, hay que saber de dónde venimos.
Primera generación: las guías de estilo estáticas (2005–2015)
Todo empezó con PDFs y páginas web de referencia. Los equipos documentaban colores, tipografías y componentes en documentos que envejecían mal. Dos semanas después de publicarlos, ya estaban desactualizados. Eran útiles como referencia, inútiles como sistema.
Segunda generación: los Design Systems como producto (2016–2020)
Google Material Design (2014) y después el IBM Carbon System o el Atlassian Design System normalizaron la idea de que un DS no es un documento, es un producto vivo con su propio roadmap. Aparecen los primeros sistemas de tokens: variables con semántica (color-primary, spacing-md), no solo valores (#1A73E8, 16px). Figma cambia las reglas del juego: diseño y documentación empiezan a vivir en el mismo sitio.
Tercera generación: tokens multiplataforma y Style Dictionary (2020–2023)
Amazon's Style Dictionary y el W3C Design Token Community Group (DTCG) intentan resolver el problema de la fragmentación: los mismos tokens en web, iOS y Android. La promesa era buena. La realidad es que cada plataforma seguía teniendo sus particularidades y la adopción fue parcial.
Cuarta generación: el problema de la IA (2023–hoy)
Y aquí estamos. Los agentes de IA generan código e interfaces a una velocidad impensable hace tres años. Pero tienen un problema fundamental: no tienen memoria entre sesiones. Cada vez que abres Cursor o le pides a Claude Code que añada un nuevo componente, el agente empieza desde cero. Sin contexto. Sin saber que en tu sistema los botones primarios son rounded-[8px], no rounded-full. Sin saber que usas Fraunces para headings y JetBrains Mono para código.
El resultado es lo que en Dribba llamamos UI drift: interfaces que se van alejando del sistema definido cada vez que la IA toca algo.
Qué es DESIGN.md y por qué Google lo creó ahora
En mayo de 2025, Google lanzó DESIGN.md como formato abierto bajo licencia Apache 2.0, originalmente desarrollado para su herramienta Stitch. La idea es simple pero potente: un único archivo de texto plano que describe el sistema de diseño de tu producto de forma que tanto humanos como agentes de IA puedan leerlo e interpretarlo.
El archivo combina dos capas:
YAML estructurado para los tokens machine-readable: colores, tipografía, espaciado, radios, sombras. Es la parte que el agente puede parsear con precisión.
Markdown narrativo para el contexto que los tokens no pueden expresar: por qué existe cada decisión, cómo aplicar los valores, qué no hacer y por qué. Es la capa que le da juicio al agente, no solo datos.
El archivo se organiza en secciones definidas:
- Overview — Identidad del producto, personalidad visual, principios
- Colors — Paleta primaria, secundaria, semántica (error, warning, success)
- Typography — Familias, escalas, pesos, line-heights
- Layout — Grid, breakpoints, contenedores, espaciado
- Elevation and depth — Sombras, z-index, capas
- Shapes — Border-radius por tipo de componente
- Components — Especificaciones de los elementos clave
- Do's and don'ts — Las reglas no negociables
La clave está en la portabilidad: un DESIGN.md puedes arrastrarlo a Cursor, pegarlo en el contexto de Claude Code, referenciarlo desde un CLAUDE.md o un AGENTS.md, o cargarlo en cualquier agente que entienda texto. No necesitas plugins, no necesitas integraciones especiales.
Lo que funciona bien (y por qué no es trivial)
Llevamos varios meses experimentando con distintos enfoques para mantener consistencia en proyectos con IA intensiva. DESIGN.md tiene virtudes reales que vale la pena reconocer.
Resuelve un problema real, no uno inventado. El UI drift existe y escala. En proyectos con más de un agente o más de un desarrollador usando IA, la divergencia se multiplica. Tener un único source of truth en texto plano que cualquier agente puede consumir es una solución pragmática.
La simplicidad es una feature, no una limitación. El hecho de que sea Markdown + YAML es deliberado. No requiere tooling especial. No tiene dependencias. Un desarrollador junior puede escribir y mantener el archivo. Un diseñador puede leerlo sin formación técnica. Eso tiene valor.
Está construido sobre estándares existentes. Google alinea DESIGN.md con el W3C DTCG (Design Token Community Group) y ofrece un CLI para exportar a Tailwind. Eso significa que no es un silo: puede coexistir con tu sistema de tokens actual.
Es tool-agnostic por diseño. No importa si usas Claude, GPT-4o, Gemini o el modelo de turno. Cualquier LLM que reciba el contenido del archivo como contexto puede interpretarlo. Eso es lo que lo hace potencialmente duradero.
Los límites que hay que conocer
No voy a vender DESIGN.md como la solución definitiva porque no lo es, todavía. Hay limitaciones importantes que cualquier equipo debe tener en cuenta antes de adoptarlo.
Está en fase alpha, y lo saben. En el propio GitHub de Google aparece el aviso: "expect changes to the format as it matures." Si construyes procesos sobre la versión actual, tendrás que migrar. Eso tiene un coste.
El vocabulario de componentes es limitado. En la spec actual, los componentes solo soportan 8 propiedades: backgroundColor, textColor, typography, rounded, padding, size, height, width. Un Design System real necesita mucho más: bordes, transiciones, estados (hover, focus, disabled), gradientes, animaciones, breakpoints por componente. Todo eso queda fuera.
No hay soporte para temas. Light mode, dark mode, temas de marca para diferentes clientes o contextos: nada de esto está contemplado en la versión actual. Es una omisión significativa para cualquier producto moderno.
Los aspectos más ricos de un DS no son tokenizables. ¿Cómo describes en YAML el tono de voz de tu interfaz? ¿Las reglas de accesibilidad específicas de tu producto? ¿Los principios de motion design? ¿Cuándo usar una ilustración en lugar de un icono? Los Design Systems maduros tienen una capa semántica y cultural que no cabe en un archivo de tokens.
No hay adopción confirmada fuera de Google. Stitch lo usa nativamente. Aura (de Meng To) lo ha incorporado. Pero ni Anthropic, ni OpenAI, ni Figma, ni ninguna otra herramienta principal ha anunciado soporte oficial. El riesgo de que se convierta en el enésimo estándar que no despega es real.
Cómo lo estamos integrando en Dribba
(Imagen: Estructura de carpetas de un proyecto mostrando DESIGN.md, CLAUDE.md, AGENTS.md en la raíz. Captura de terminal o explorador de archivos en VS Code.)
En Dribba trabajamos principalmente con Flutter para mobile y Next.js + Tailwind para web. Los dos contextos tienen particularidades distintas, pero el problema de consistencia con IA es el mismo en ambos.
Lo que estamos haciendo no es adoptar DESIGN.md como spec estricta, sino usar su lógica como base para construir nuestros propios archivos de contexto. La estructura que nos está funcionando en proyectos web:
/proyecto
CLAUDE.md → instrucciones generales para el agente
DESIGN.md → tokens y guías visuales
COMPONENTS.md → especificaciones detalladas de componentes clave
COPY_GUIDELINES.md → tono de voz, textos de UI, microcopy
Esta fragmentación resuelve uno de los problemas que anticipo en la evolución del formato: a medida que el Design System crece, un solo archivo se hace inmanejable. La solución natural es modularizar: un archivo por dominio semántico, referenciados desde un índice.
En Flutter, el equivalente tiene su propia lógica porque el paradigma de componentes es diferente, pero el principio es el mismo: darle al agente contexto estructurado antes de que empiece a generar.
La pregunta real: ¿estándar o tendencia pasajera?
Esta es la pregunta que más me hacen cuando hablo de DESIGN.md en conversaciones con otros equipos.
Mi respuesta honesta: la necesidad que resuelve es permanente; si el formato específico sobrevivirá, aún está por ver.
Los agentes de IA no van a desaparecer de los flujos de trabajo de desarrollo. Al contrario, van a ir tomando más protagonismo. Y mientras eso ocurra, el problema de la consistencia visual y de diseño va a seguir siendo relevante. Los equipos necesitan una forma estructurada de darle contexto al agente sobre quiénes son visualmente. Eso no es una moda.
Lo que sí puede ser una moda es el formato concreto. Si Google no acelera la spec, si no aparece adopción por parte de los players principales (Figma, Anthropic, OpenAI, Vercel...) o si alguien propone una alternativa mejor, DESIGN.md podría quedarse como una buena idea que no llegó a convertirse en estándar.
El precedente más cercano que tengo en mente es el de los Web Components a principios de los 2010: tecnología sólida, respaldo de Google, buenas intenciones... y diez años de adopción parcial porque el ecosistema se fragmentó antes de que pudiera consolidarse.
Lo que sí creo que va a ocurrir, pase lo que pase con DESIGN.md, es que el concepto de "archivo de contexto de diseño para agentes" se va a normalizar. Ya sea en este formato, en una variante de él, o en algo que todavía no existe. La idea tiene demasiado sentido para no prosperar.
Qué debería hacer Google (y qué debería hacer el resto del ecosistema)
Si Google quiere que DESIGN.md se convierta en estándar y no en un proyecto de Google Labs más, hay movimientos concretos que necesita hacer:
Ampliar el vocabulario de componentes. Los 8 atributos actuales son insuficientes para cualquier DS real. Hay que añadir soporte para bordes, estados, transiciones, breakpoints y al menos las variantes más comunes de cada componente.
Resolver el problema de los temas. Dark mode y múltiples temas no son opcionales en 2026. Deben estar en la spec antes de que el formato llegue a beta.
Modularizar el formato. Un único archivo no escala. La solución obvia es permitir un sistema de archivos múltiples con un índice: DESIGN.md como punto de entrada, con referencias a motion.md, accessibility.md, iconography.md, etc.
Conseguir adopción de Figma y de al menos un LLM principal. Sin integración nativa en Figma y sin soporte explícito en Claude, GPT o Gemini, el formato seguirá siendo una herramienta para early adopters.
Del lado del ecosistema: el W3C DTCG debería acelerar su propio trabajo y valorar si tiene sentido alinearse con DESIGN.md o proponer una convergencia. Los equipos de Tailwind, Radix, shadcn/ui y otras librerías populares podrían añadir exportación al formato con poco esfuerzo y mucho impacto.
Conclusión: la coherencia visual es demasiado valiosa para dejársela al azar del agente
Los Design Systems nacieron para que los equipos humanos hablaran el mismo idioma visual. DESIGN.md es el primer intento serio de enseñarle ese idioma a las máquinas.
No está terminado. Tiene limitaciones importantes. Puede que no sea el formato que acabe imponiéndose. Pero la dirección es la correcta, y la urgencia es real: cada día que trabajamos con agentes de IA sin darles un contexto de diseño estructurado es un día en el que el UI drift se acumula.
En Dribba, ya hemos tomado la decisión de incorporar esta capa de contexto en todos nuestros proyectos nuevos. No esperamos a que el estándar madure para resolver un problema que ya tenemos encima.
Si trabajas con IA en el desarrollo de interfaces y todavía no tienes alguna versión de este archivo en tus proyectos, este es el momento de empezar. Aunque sea una versión mínima. Aunque no sea perfecta.
La consistencia no es un lujo de los equipos grandes. Es la diferencia entre un producto que se siente construido y uno que se siente generado.
Explora DESIGN.md:
- Spec oficial y GitHub: github.com/google/design-md
- Generador asistido: getdesign.md
- Alternativa con IA: designmd.ai
- Google Stitch: stitch.withgoogle.com
¿Tu equipo ya está usando DESIGN.md o alguna variante? Cuéntanos en los comentarios o escríbenos directamente — nos interesa mucho saber cómo otros equipos están resolviendo el problema de la consistencia con IA.
