Atlassian prueba DESIGN.md contra MCP y skills: la lección para evitar interfaces genéricas de agentes
Atlassian publicó el 15 de junio de 2026 sus pruebas con DESIGN.md, ADS MCP y skills para dar contexto de diseño a agentes. La conclusión práctica: DESIGN.md ayuda en prototipos, pero en producción un MCP o skill bajo demanda puede ahorrar tokens y evitar que el agente reconstruya componentes.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Atlassian publicó el 15 de junio de 2026 una comparación muy útil para cualquier builder que ya sufrió interfaces generadas por IA que parecen correctas, pero no pertenecen a ningún producto real. El tema es DESIGN.md, un formato Markdown impulsado por Google para describir tokens, fundamentos y decisiones de diseño de forma portable para agentes.
La parte valiosa del post no es que Atlassian "use IA para diseño". La parte valiosa es que midió el tradeoff entre un archivo portable, un MCP server de Atlassian Design System y skills que dan contexto bajo demanda.
Qué problema intenta resolver DESIGN.md
Cuando un agente genera UI sin contexto, casi siempre cae en patrones promedio: botones con gradiente, tarjetas genéricas, headings exagerados, sombras de más y componentes que no existen en el producto. Funciona en demo, pero se siente como una interfaz sin dueño.
DESIGN.md intenta darle al agente una instantánea portable:
- tokens de color, forma y tipografía;
- racional de diseño;
- reglas de layout;
- pautas de componentes;
- y tono visual general.
Para prototipos, eso puede ser suficiente. Atlassian cuenta que un dashboard generado con DESIGN.md pasó de verse genérico a sentirse más reconociblemente Atlassian.
El dato incómodo: portabilidad también cuesta
La comparación de Atlassian es útil porque no vende una solución mágica. En una prueba simple de login, usar DESIGN.md como única fuente consumió 7.21 millones de tokens promedio, frente a 3.75 millones con ADS MCP y 4.43 millones con ADS skill. También tomó más tiempo y tuvo más variación entre corridas.
No hay que leer esos números como benchmark universal. La propia nota advierte que cambian con modelo, prompt, ambiente y calidad de fuentes. Pero sí revelan una regla de arquitectura: cargar todo el sistema de diseño cada vez es caro y menos preciso que pedir solo el contexto necesario.
La lección para producción
En producción, el objetivo no es que el agente reimplemente tu sistema de diseño. El objetivo es que use los componentes existentes.
Ahí Atlassian marca un límite importante: DESIGN.md describe intención y estilo, pero no sustituye librerías, linters, reglas de importación ni documentación técnica de componentes. Si el agente lee un botón como descripción estética, puede intentar recrearlo. Si recibe una skill o consulta MCP que le dice cómo importar el componente real, el diff suele ser más mantenible.
Para builders, el criterio práctico sería:
- DESIGN.md para prototipos, demos, herramientas nuevas y contextos donde no puedes conectar tu stack completo;
- MCP o skills para codebases reales donde el agente debe usar componentes, tokens y reglas existentes;
- linters y tests visuales como cierre, porque no todo problema de diseño se resuelve con más contexto.
Por qué esto puede ganar búsqueda
La intención está creciendo alrededor de queries como DESIGN.md, design system MCP, AI agent design system, agent UI slop, ADS MCP y skills para agentes de frontend. No hay tooling SEO conectado aquí; la demanda se infiere por la publicación oficial, el formato abierto de Google, la adopción por equipos de diseño y el dolor visible de interfaces generadas que no respetan marca ni componentes.
Este no es tráfico masivo de consumidores. Es tráfico cualificado de frontend, design systems y equipos que ya usan agentes de coding.
Errores comunes
No metería DESIGN.md en un repo y daría el trabajo por terminado. Revisaría estos riesgos:
- el archivo se queda viejo frente al sistema real;
- el agente copia la estética, pero ignora accesibilidad;
- se recrean componentes en vez de importar los existentes;
- el contexto largo aumenta costo sin mejorar calidad;
- la revisión humana se enfoca en "se ve bonito" y no en mantenibilidad.
También evitaría poner secretos, decisiones internas sensibles o detalles innecesarios del sistema en un archivo que se comparte fuera del perímetro. Un buen contexto para agentes debe ser útil, pero no una fuga completa de cómo opera tu producto.
Qué haría un equipo latinoamericano
Si tu stack es pequeño, empezaría con un DESIGN.md corto: colores, tipografía, espaciado, voz visual y tres reglas de composición. Luego agregaría ejemplos de "haz" y "no hagas". Eso puede mejorar prototipos en Codex, Claude Code o Gemini sin montar infraestructura.
Si ya tienes design system serio, iría por otro camino: skills pequeñas por familia de componentes, MCP para documentación bajo demanda y pruebas de UI que fallen cuando el agente reintroduce componentes inventados.
Esta nota conversa bien con A2UI y UI generativa para agentes. Una historia habla de cómo renderizar interfaces generadas; esta explica cómo darle al agente suficiente criterio para no producir pantallas genéricas desde el primer intento. Si todavía estás montando la base de agentes antes de tocar frontend, empieza por el curso gratis.
La lectura corta: DESIGN.md es una buena puerta de entrada, pero no reemplaza contexto bajo demanda ni componentes reales. Para prototipos puede quitar bastante "slop"; para producción, MCP, skills y linters siguen siendo la ruta más defendible.