2026-09 · 4 min de lectura
Escribir reglas para un juego que nadie sabe que está jugando
Los agentes de IA pueden leer componentes y reglas. Lo difícil es poner a su alcance, en el momento de generar, el criterio que da sentido a esas reglas.
La mayoría de los diseñadores utilizan un sistema de diseño de una forma parecida a como la mayoría de las personas utiliza la gramática.
No estudiando cada regla. Absorben suficiente como para que las reglas pasen al fondo y la atención pueda ir a otra parte. El diseñador piensa en el problema, no en el token. Sabe qué suele pertenecer junto, qué se siente incorrecto y cuándo está justificado romper el patrón.
Esa intuición también forma parte del sistema.
Simplemente rara vez vive en la documentación.
Los agentes de IA están cambiando esa relación.
Los sistemas de diseño se están convirtiendo en inputs para máquinas que generan interfaces y código. Componentes, tokens, ejemplos, instrucciones de repositorio y metadatos estructurados pueden ofrecerse como contexto.
Así que el problema ya no es que un agente no tenga contexto.
El problema es que no tiene una historia compartida a menos que decidamos hacerla accesible.
Un diseñador humano adquiere contexto a través de críticas, correcciones, exploraciones fallidas, excepciones y la memoria de por qué un equipo tomó una decisión y no otra. Un agente no atraviesa esa socialización. Ve el contexto disponible en el momento de la tarea.
El reto no consiste en dar más reglas a la IA. Consiste en darle acceso al juicio que hacía significativas esas reglas.
La mayoría de los sistemas de diseño ya son buenos codificando decisiones.
Este es el botón. Esta es la escala de espaciado. Estos son los estados de interacción. Estos componentes pueden combinarse de estas maneras.
Para los diseñadores humanos eso solía ser suficiente porque la capa que faltaba vivía en las personas que utilizaban el sistema. Sabían cuándo el componente aprobado seguía siendo incorrecto para una situación. Sabían qué regla representaba un principio y cuál era simplemente un compromiso histórico.
Un agente no puede inferir eso de manera fiable a partir del componente.
Por eso la siguiente generación de sistemas de diseño tendrá que contener más que UI reutilizable. Tendrá que contener intención.
¿Por qué existe este patrón? ¿Cuándo no debería utilizarse? ¿Qué restricción es estructural? ¿Qué excepción es legítima?
El sistema de diseño empieza así a convertirse en memoria organizacional legible por máquinas.
Los sistemas de diseño solían codificar decisiones. Cada vez más tendrán que codificar el juicio necesario para tomar decisiones nuevas.
Hay un peligro en esta idea.
Hacer explícito el juicio puede convertirse fácilmente en un intento de transformar el juicio en reglas. No son lo mismo.
Los buenos diseñadores no se vuelven buenos memorizando instrucciones cada vez más detalladas. Aprenden qué principios importan bajo qué condiciones. Un sistema de diseño legible por máquinas también necesita representar incertidumbre, excepciones y límites.
A veces la instrucción correcta no es: «Utiliza siempre este patrón».
Es: «Utiliza este patrón salvo que se den estas condiciones. Si aparecen, detente y reconsidera el problema que hay debajo».
Eso también cambia el papel de DesignOps: no solo mantener la consistencia, sino diseñar el contexto a través del cual humanos y máquinas entienden para qué sirve esa consistencia.
Durante años, una gran parte de la calidad de diseño vivía entre líneas.
En la crítica. En el criterio. En la memoria institucional. En la frase que nunca llegó a la documentación porque todas las personas de la sala ya sabían lo que significaba.
Eso era manejable mientras el siguiente usuario del sistema fuera otra persona capaz de adquirir el contexto que faltaba con el tiempo.
Se convierte en un problema estructural cuando el siguiente usuario es una máquina que genera de inmediato.
El sistema de diseño pasa entonces a ser más que un vocabulario compartido. Se convierte en una interfaz hacia el juicio de diseño acumulado por la organización.
La próxima generación de sistemas de diseño quizá se mida menos por la consistencia con la que reproduce el pasado y más por su capacidad para conservar el razonamiento necesario para diseñar lo que viene después.
Las herramientas son nuevas. El problema de fondo — hacer transferible el conocimiento organizacional tácito — no lo es.