El Nuevo Governance Agentic

La forma en la que trabajamos está cambiando muy rápido. Cada vez más designers prototipan y diseñan a través de agentes directamente en el código.

Y cada vez se valida y se prueba más y más rápido. Pero desde el design system tenemos un gran problema. Cada vez es más difícil saber cómo está trabajando la gente y cuál es el resultado tras usar el DS a través de un agente.

Antes veíamos los archivos de Figma, las revisiones y las dudas en Slack. Ahora gran parte de ese trabajo pasa en conversaciones que no vemos.

El governance de “antes” (revisiones, office hours, aprobar cada pantalla) a veces no funciona.

Así que el otro día, dándole vueltas al tema de los Evals, me puse a pensar en cómo mejorar este flujo de trabajo y se me ocurrió esta idea.

El mapa completo

Antes de entrar en cada paso, este es el recorrido entero:

1. Los designers suben sus prototipos a una carpeta del repo, cada uno en la suya.
2. Un agente revisa cada prototipo con las reglas del design system.
3. El designer recibe el feedback en su propia PR, con el porqué.
4. Solo las PRs con fallos se etiquetan, y todo queda registrado.
5. Quien lleva el design system busca patrones, no revisa pantallas.
6. Un fallo repetido se convierte en eval, se arregla el design system y se mide si ha mejorado.

1. Una carpeta por designer, una PR por prototipo

En el repo se crea una carpeta prototypes/ con una subcarpeta por persona: prototypes/ana/, prototypes/luis/… Cada designer prototipa con su agente conectado a GitHub y sube la pantalla como una PR.

Solo toca su carpeta. Nunca toca el design system. Así puede experimentar sin miedo a romper nada y cada prototipo deja rastro.

2. Un agente revisa cada PR con las reglas del design system

Cuando se abre una PR que toca prototypes/, Claude la revisa automáticamente con las reglas del design system. Por ejemplo, comprueba:

• Si usa Badge en vez de un div pintado a mano;
• Si usa tokens en vez de colores sueltos;
• Si los textos de error siguen el contrato del componente.

Las reglas son las mismas que ya tienes escritas: contratos, diccionario de props, tokens. Si todavía no las tienes, empieza por ahí (Make Your Design System Agent-Ready in 5 Steps). O apúntate a mi curso Crear un design system agentic.

3. El designer aprende en el momento

El agente deja un comentario en la PR con la lista de fallos. Cada fallo lleva:

• Su tipo (componente, token, accesibilidad…);
• El archivo del design system que lo explica.

El designer no espera a una revisión ni a que alguien tenga tiempo. Lo ve en su pantalla, con el motivo y el enlace para entenderlo.

4. Solo se etiqueta lo que tiene fallos

Si encuentra fallos, el agente pone una etiqueta, por ejemplo ds-feedback. Si la PR está bien, no hay etiqueta ni ruido.

Y todo queda registrado en GitHub: quién, qué pantalla y qué falló. No dependes de que alguien te pida ayuda, te cuente qué está haciendo, etc.

5. Quien lleva el design system revisa patrones, no pantallas

Filtras GitHub por ds-feedback y te salen solo las PRs con problemas. Una vez a la semana, o cuando te venga bien, las miras, agrupas los fallos por tipo y buscas lo que se repite.

Esto escala, da igual que haya 3 designers o 30. El filtro y la agrupación funcionan igual.

6. Un fallo repetido se convierte en un eval

Aquí está la clave: no un eval por pantalla, sino un eval por fallo que se repite.

Un día ves esto: “En 6 PRs de 4 personas, las etiquetas de estado se han hecho a mano en vez de usar Badge.” Eso ya no es un despiste de una persona. Es una señal de que el design system no explica bien ese punto.

1. Escribe un encargo parecido a esas pantallas: “Haz una tabla de pedidos con el estado de cada uno.”
2. Añade un ítem al checklist: “Usa Badge para el estado.”
3. Pasa el eval antes de tocar nada y apunta el porcentaje.
4. Arregla la regla o la documentación: el “never use for”, un ejemplo, una nota en el contrato.
5. Vuelve a pasarlo. Si sube, el cambio ha funcionado y lo puedes demostrar.

¿Por qué no un eval por pantalla?

• Tendrías cientos de evals que no dicen nada.
• Un fallo aislado puede venir de un encargo raro. Uno que se repite te habla del design system.
• Los evals miden tus reglas, no a tus designers.

La pantalla del designer es la pista y el eval es la prueba.

Para resumir

El governance de un design system siempre ha consistido en saber cómo se usa y corregir el rumbo. Con agentes, eso no desaparece, cambia de sitio, deja de estar en las revisiones y pasa a estar en lo que sale de cada prototipo.

No hace falta revisar cada pantalla. Basta con que cada fallo quede explicado y registrado, y con que tú mires dónde se repite.

Cómo empezar:

• Crea prototypes/ con una subcarpeta por designer.

• Escribe una revisión con las 5–10 reglas que más repites.

  Empezar con 5 reglas que valen para cualquier design system. No necesitas datos para elegirlas:

  • No hay valores a mano: ni colores, ni espacios, ni radios; todo con tokens.
  • Si existe un componente, se usa: nada de botones, badges o inputs reconstruidos con div.
  • Los componentes se usan como dice su documentación: props correctas y estados de error según el contrato.
  • Los nombres son los del design system: props y valores del diccionario (icon, no leftIcon; variant, no type).
  • Todo es accesible: cada campo tiene su label, cada icono sin texto tiene un nombre accesible y el contraste cumple AA.

• Haz que solo etiquete ds-feedback cuando encuentre fallos.

• En unas semanas, convierte el primer fallo repetido en tu primer eval.