Claude Code para diseñadores: el flujo completo sin ser developer

Por qué un diseñador debería tocar Claude Code

Claude Code es una herramienta de terminal. Esa frase espanta a la mitad de los diseñadores que la leen, y es exactamente la razón por la que quien la supera tiene ventaja: el flujo agéntico de 2026 pasa por ahí, y casi nadie del lado de diseño lo ha aprendido todavía. En inglés ya se enseña (Memorisely lo vende como titular); en castellano, este es de los pocos textos que lo cuenta.

La idea central: Claude Code no es un chat. Es un agente que lee tu repositorio, ejecuta comandos, edita archivos y abre pull requests. Para un diseñador que trabaja con un design system, eso significa poder pedir “crea la variante quiet del Button siguiendo los principios del sistema” y revisar el resultado como revisarías el trabajo de un junior: con criterio de sistema, no de sintaxis.

Lo mínimo para empezar

Instalación. Claude Code se instala con un comando (npm install -g @anthropic-ai/claude-code) y se abre con otro (claude). Si tu equipo tiene el repo del design system en GitHub, pide acceso de lectura: no necesitas permisos de escritura para aprender.
El primer prompt útil no genera nada. Pide un mapa: “explícame cómo está organizado este design system: dónde viven los tokens, dónde los componentes, qué convenciones de nombre se usan”. Claude Code lee el repo y te lo cuenta. Acabas de hacer en diez minutos el onboarding que normalmente toma dos semanas.
CLAUDE.md es tu documento de principios. En la raíz del repo puede haber un archivo CLAUDE.md con las reglas del proyecto. Si tu design system tiene principios escritos, este es el lugar donde se vuelven operativos: lo que pongas ahí condiciona todo lo que el agente genere. Un principio que no está en ese archivo es un principio decorativo.

El flujo de trabajo realista

El error habitual es pedirle pantallas enteras. El flujo que funciona es más quirúrgico:

Variantes de componente. “Crea la variante destructive de Button. Mira cómo está hecha primary, usa los tokens de color.feedback.error y no introduzcas valores hex nuevos.” El agente imita el patrón existente. Tu trabajo es haber decidido que esa variante debe existir.
Auditorías. “Lista todos los componentes que usan valores de espaciado fuera de la escala de tokens.” Esto a mano son días; al agente le toma minutos y no se aburre.
Documentación. “Escribe la página de documentación de Card siguiendo la plantilla de la de Button.” La documentación dual (para humanos y para agentes) deja de ser el trabajo que nadie hace.

En cada caso el patrón es el mismo: tú decides el qué y el criterio, el agente ejecuta el cómo, y tú revisas contra los principios del sistema.

Conectarlo a tu design system: MCP

Claude Code puede consultar herramientas externas vía Model Context Protocol. Si tu sistema expone un servidor MCP (cómo construirlo está en la guía de MCP servers), el agente deja de adivinar y consulta: tokens vigentes, API de componentes, principios. Figma también expone su MCP, lo que cierra el circuito archivo de diseño → código sin handoff manual.

La configuración es un JSON corto en los ajustes de Claude Code. Pídesela al equipo que mantiene el sistema; si no existe, acabas de encontrar el proyecto con el que justificar tu siguiente subida.

Cómo se revisa lo que genera un agente

La habilidad diferencial no es escribir prompts: es revisar resultados. Tres preguntas ante cada PR generado:

¿Usa tokens o valores directos? Un hex suelto es el primer síntoma de que el agente no encontró (o no existe) el token correcto.
¿Respeta la API del componente o inventa props? Los agentes inventan con seguridad absoluta. La API pública documentada es tu contrato de revisión.
¿El cambio pertenece al sistema o al producto? La pregunta de governance de siempre, ahora con más volumen de cambios que revisar.

Hasta dónde llega esto sin saber programar

Lejos, pero no hasta el final. Puedes auditar, documentar, crear variantes sencillas y prototipar. No deberías mergear a producción sin alguien que entienda el código revisándolo, igual que un developer no debería publicar una variante sin criterio de diseño. El punto dulce es el equipo donde ambos perfiles revisan lo que el agente produce.

Ver también

Este flujo completo, con tu design system real y acompañamiento del claustro, es el corazón del bootcamp ejecutivo. La semana 3 monta el servidor MCP; de la 5 a la 8, todo entregable pasa por Claude Code, Cursor y Figma MCP.