Si usaste cualquier herramienta AI para generar UI — Cursor, Claude Code, v0, Bolt, Lovable, Windsurf, lo que sea — te chocaste con esta pared: la IA genera algo funcional pero visualmente genérico. Describís “un dashboard con los colores de mi marca” y te devuelve una paleta default de Tailwind con botones azules. Lo arreglás a mano, prompteás de nuevo, y el siguiente componente sale con un lenguaje visual completamente distinto.
El problema no es la IA. El problema es que tu IA no tiene idea de cómo se ve tu design system.
Google acaba de open-sourcear la solución. Se llama DESIGN.md.
Qué Es DESIGN.md
DESIGN.md es una especificación de formato — un archivo markdown que describe tu identidad visual de una manera que los agentes de codificación AI pueden leer, entender y aplicar consistentemente. Nació dentro de Google Stitch, el canvas de diseño AI-native de Google Labs, y desde esta semana la spec es open source bajo licencia Apache 2.0.
El repo: github.com/google-labs-code/design.md
El concepto es simple pero poderoso: combinar design tokens legibles por máquina (YAML front matter) con la lógica de diseño legible por humanos (markdown prose). Los tokens le dan al agente valores exactos. La prosa le dice por qué existen esos valores y cómo aplicarlos.
Así se ve un archivo DESIGN.md:
---
name: Heritage
colors:
primary: "#1A1C1E"
secondary: "#6C7278"
tertiary: "#B8422E"
neutral: "#F7F5F2"
typography:
h1:
fontFamily: Public Sans
fontSize: 3rem
body-md:
fontFamily: Public Sans
fontSize: 1rem
rounded:
sm: 4px
md: 8px
spacing:
sm: 8px
md: 16px
---
## Overview
Architectural Minimalism meets Journalistic Gravitas. The UI evokes a
premium matte finish — a high-end broadsheet or contemporary gallery.
## Colors
- **Primary (#1A1C1E):** Deep ink for headlines and core text.
- **Tertiary (#B8422E):** "Boston Clay" — the sole driver for interaction.
- **Neutral (#F7F5F2):** Warm limestone foundation, softer than pure white.
Un agente que lee este archivo produce una UI con títulos en tinta oscura usando Public Sans, un fondo cálido tipo piedra caliza, y botones de acción en Boston Clay. Cada vez. En cada componente que genera.
Ese es el unlock: consistencia visual sin corrección manual en cada prompt.
Por Qué Importa Ahora
El timing no es casualidad. Estamos en un momento donde las herramientas AI generan UI desde texto a una velocidad impresionante — pero cada herramienta tiene su propia forma de entender la intención de diseño. Armás algo en Stitch, querés continuar en Claude Code, y arrancás de cero con el lenguaje visual. Prototipás en v0, te movés a Cursor para el código de producción, y gastás una hora re-explicando tu paleta de colores.
DESIGN.md propone ser el contrato universal entre tu design system y cualquier agente AI que toque tu código. Un archivo. Lo tirás en el root de tu proyecto. Todas las herramientas lo leen.
El formato es deliberadamente simple: es markdown. No necesitás exports de Figma, ni schemas JSON propietarios, ni tooling especial. Markdown es el formato que los LLMs leen mejor — no hay nada que parsear ni configurar. Y como la lógica de diseño vive al lado de los tokens, la IA no solo sabe que tu color primario es #1A1C1E — sabe que se llama “Deep Ink” y se usa para títulos, no para fondos.
El Workflow Práctico
Así es como lo usarías en la práctica:
Opción 1: Arrancá desde Stitch. Diseñás tu UI en Google Stitch, y cuando terminás, exportás el DESIGN.md. Esto te da un archivo con todos los tokens, roles de color, tipografía, spacing, y la lógica de diseño ya escrita para que la IA la entienda. Después lo tirás en tu proyecto de código.
Opción 2: Escribilo a mano. Si ya tenés un design system o brand guidelines, podés escribir el DESIGN.md vos mismo. El YAML front matter cubre tokens (colores, tipografía, spacing, border-radius), y la prosa en markdown describe la filosofía, los do’s/don’ts, y los patrones de componentes. La spec tiene documentación clara sobre qué incluir.
Opción 3: Extraelo de un sitio existente. Ya se formó un ecosistema de herramientas alrededor de este formato. Hay una extensión de Chrome (DESIGN.md Style Extractor de TypeUI) que extrae CSS variables y computed styles de cualquier sitio web y genera un DESIGN.md. Hay CLIs como dembrandt que crawlean una URL con Playwright y producen design tokens en formato DESIGN.md. Y hay un repositorio curado entero — awesome-design-md — con archivos DESIGN.md pre-armados modelados a partir de Stripe, Vercel, Linear, Notion, Airbnb, y docenas de otros design systems conocidos.
Una vez que tenés el archivo, el uso es idéntico en todas las herramientas:
project/
├── DESIGN.md ← tu spec de design system
├── src/
│ ├── components/
│ └── pages/
└── package.json
Le decís a tu agente AI: “Construí una página de settings siguiendo el design system en DESIGN.md.” El agente lee el archivo, aplica los tokens, sigue la lógica de diseño, y genera código que realmente se ve como tu marca.
Agent Skills: Yendo Más Profundo
Google también mantiene una librería de skills — google-labs-code/stitch-skills — que se complementa con DESIGN.md. Los skills son pequeños sets de instrucciones que le enseñan a los agentes de codificación cómo realizar workflows específicos. El skill design-md, por ejemplo, le dice a tu agente cómo analizar un proyecto de Stitch y generar un DESIGN.md completo a partir de él.
Se instalan así:
npx skills add google-labs-code/stitch-skills --skill design-md --global
Otros skills de la colección incluyen stitch-loop (genera un sitio web multi-página desde un solo prompt), react:components (convierte pantallas de Stitch a sistemas de componentes React con consistencia de design tokens), y enhance-prompt (transforma descripciones vagas de UI en prompts detallados y optimizados para Stitch).
Estos skills siguen el estándar abierto Agent Skills, lo que significa que funcionan con Claude Code, Cursor, Windsurf, Gemini CLI, y otros agentes compatibles — no solo con herramientas de Google.
¿Y la Accesibilidad?
Un detalle del blog post de Google que vale la pena destacar: DESIGN.md no solo captura tokens visuales — puede codificar intención de accesibilidad. En lugar de que un agente adivine si una combinación de colores cumple con los requisitos de contraste WCAG, la spec te permite declarar roles de color con su propósito semántico. El agente puede entonces validar sus decisiones contra reglas de accesibilidad antes de generar código.
Esto es significativo porque la UI generada por IA tiene un problema conocido de accesibilidad. Cuando el agente no conoce el rol intencional de un color, no puede verificar si ese naranja brillante sobre fondo blanco cumple con el contraste AA. Con los roles semánticos de color de DESIGN.md, la información está ahí para que el agente haga esa verificación.
El Ecosistema que Ya se Está Formando
La spec tiene un día en su forma open source y ya acumula ~1.600 estrellas en GitHub (con un ritmo de crecimiento acelerado). Pero la señal interesante es el ecosistema que se está formando alrededor:
- awesome-design-md — una colección curada por la comunidad de archivos DESIGN.md para marcas populares (Stripe, Binance, Airbnb, Meta, etc.)
- DESIGN.md Style Extractor — una extensión de Chrome que genera el archivo desde cualquier sitio que estés navegando
- dembrandt — un CLI que crawlea sitios con Playwright y genera DESIGN.md, tokens DTCG, e incluso PDFs de brand guide
- design-md-generator — usa extracción con Playwright + Claude Code para la escritura semántica del DESIGN.md
- Shuffle.dev — ya soporta export de DESIGN.md desde su UI builder
- MindStudio — publicó un workflow para encadenar Stitch → DESIGN.md → Claude Code
Para algo que acaba de ir open source, esta curva de adopción es notable. Sugiere que el formato está atacando una brecha real en el pipeline de design-to-code que los desarrolladores venían resolviendo con soluciones ad-hoc.
La Evaluación Honesta
Lo que funciona bien:
- El formato en sí es elegante: YAML para máquinas, markdown para humanos, ambos en un mismo archivo. No se necesita tooling nuevo.
- Agnóstico de agente por diseño. Funciona con Claude Code, Cursor, Windsurf, Gemini CLI, Codex — cualquier herramienta que lea markdown.
- La combinación de tokens exactos + lógica de diseño es más inteligente que solo tokens. Saber que
#B8422Ees “Boston Clay, el único driver de interacción” le da al agente más información que simplementeaccent: #B8422E. - Licencia Apache 2.0. No hay lock-in con el ecosistema de Google.
Lo que hay que observar:
- La spec sigue siendo un draft. Funciona, pero son posibles cambios estructurales a medida que más herramientas la adopten.
- La generación desde sitios existentes (vía extensiones de Chrome o CLIs) produce aproximaciones, no documentación oficial de design system. Los valores computed de CSS no siempre capturan la intención de diseño.
- Si esto se convierte en un verdadero estándar de la industria o sigue siendo un formato originado por Google que otros toleran depende de la adopción por parte de Figma, Storybook, y el ecosistema más amplio de tooling de diseño.
- Todavía no hay alineación con el W3C Design Tokens Community Group. El DTCG tiene su propia spec de formato de tokens. Si DESIGN.md y DTCG convergen o compiten está por verse.
Cómo Empezar
El camino más rápido para probar DESIGN.md:
- Andá al repo: github.com/google-labs-code/design.md
- Revisá la carpeta
examples/para archivos DESIGN.md de ejemplo - Copiá uno como punto de partida, editalo con los tokens de tu marca
- Tiralo en el root de tu proyecto
- En tu herramienta AI de preferencia, referencialo: “Seguí el design system en DESIGN.md”
O, si querés extraer desde un sitio existente:
# Usando dembrandt
npx dembrandt tusitio.com --design-md
O navegá la colección pre-armada en awesome-design-md para inspiración.
¿Ya estás usando DESIGN.md o algo similar para mantener la consistencia en tu UI generada por IA? ¿Cuál es tu estrategia para mantener coherencia visual cuando codeás con IA? Contanos en los comentarios. 