Astryx resolvió el problema de la intención. El de Meta.

Meta abrió Astryx, el design system que funcionaba internamente desde hace ocho años en trece mil aplicaciones, bajo licencia MIT. El diferencial que todos comentan es que fue construido para ser leído por un agente: un CLI que devuelve la documentación completa de cada componente, un manifiesto en JSON que describe todos los comandos y todas las props, un servidor MCP integrado, y un formato denso que recorta el texto para humanos y así ahorrar contexto del LLM.

La lectura fácil de este lanzamiento es: listo, resolvieron el problema de hacer que la IA construya interfaces. Lo leí con atención justamente porque llevo dos meses metido en ese problema, y llegué a otra conclusión. Harness Design es contextual.

Lo que sí resolvieron

Astryx sí documenta la intención. Los principios del proyecto dicen explícitamente que las opiniones de diseño viven en la documentación y en los ejemplos. Cada componente lleva anotaciones con sugerencias de composición, orientación en línea sobre cómo encajan las piezas. Las reglas de nomenclatura, de props y de composición son las mismas en todos los componentes, así que cuando el agente aprende algunos, puede prever cómo se comporta uno desconocido.

El problema que Meta nombra es que los design systems siempre se hicieron para consumo humano, y eso dejó de servir cuando parte del código pasó a ser escrita por agentes. Su respuesta fue volver el sistema predecible: las mismas reglas de nomenclatura, props y composición en todos los componentes, de modo que la IA pueda inferir cómo se comporta un componente que nunca vio.

Eso es trabajo de intención. Es trabajo de designer. Pero es el trabajo de intención de Meta, resuelto para el contexto de Meta, y genérico por construcción (mira un caso), porque tiene que servir a las trece mil apps que corren allá adentro.

La intención vive en un espectro

Aquí fue donde me cayó la ficha.

En un extremo está la intención universal. Login es login. Un formulario es un formulario en casi cualquier sistema. Tabla, paginación, campo obligatorio. Ese conocimiento vive fuera de tu empresa, y por eso mismo una biblioteca de terceros puede entregarlo listo.

En el otro extremo está la intención de tu producto. En nuestro caso: el drawer reemplaza al modal, y se usa extensivamente. El componente que representa un diagrama de neumáticos, donde la información no puede encogerse sin perder legibilidad. La forma específica en que tratamos el estado de un vehículo. Nada de eso existe en ninguna biblioteca. Nace desde cero, puertas adentro.

La variable que decide dónde estás en el espectro es el legado

Y aquí la conversación cambia de lugar para la mayoría de los designers que conozco.

Si trabajas en un producto que lleva cinco o diez años en el mercado, tu empresa ya creó mucho por su cuenta. Decisiones acumuladas, patrones que se volvieron identidad, formas de hacer las cosas que el usuario ya aprendió y espera encontrar. No tomas la intención de un tercero y la pones encima de eso, porque va a chocar con lo que ya existe. Aquí, producir la propia intención es la regla, no la excepción.

Tengo datos de esta parte. En nuestras pruebas con Claude Code, antes del proyecto formalizado, acertaba con tablas, headers y menús con facilidad, porque el patrón existe fuera de nuestro sistema. Y fallaba justamente donde la referencia solo podía ser la nuestra: encogió la información en el diagrama de neumáticos hasta que quedó ilegible, usó un checkbox en un formato de listado que aquí no existe y, el caso más emblemático, no encontró nuestra forma de tratar el estado e inventó la suya: cards con fondo amarillo, rojo y verde, una lógica que no existe en nuestro design system.

Astryx corregiría la primera categoría. No corregiría ningún caso de la segunda.

Para ser justo con el otro lado

Si estás empezando un producto desde cero, el cálculo es distinto. Empiezas cerca del extremo universal, heredas una gran cantidad de intención ya documentada y solo bajas a la capa propia cuando chocas con un problema que la biblioteca no previó. En ese escenario, aprovechar un Astryx tiene mucho sentido. No estoy diciendo que nadie deba adoptarlo. Estoy diciendo dónde la cuenta cierra y dónde no.

Lo que se puede copiar, y lo que no

Lo que se copia de Astryx es el enfoque. La puerta única donde humanos y agentes preguntan lo mismo y reciben la misma respuesta. La documentación legible por máquina. El formato denso para no quemar contexto. Eso es un estándar de ingeniería, no es propiedad de ellos, y es la parte que vale la pena estudiar de cerca.

El contenido que pasa por esa puerta es otro problema. Documentar que el drawer reemplaza al modal en nuestro sistema, y en qué situación es la elección correcta, no es un trabajo que resuelva una biblioteca de terceros. Es el trabajo de entender qué necesita comunicar una pantalla de flota y escribirlo de una manera que la máquina pueda usar.

Este mercado lanza algo nuevo cada semana, y Astryx es la novedad de esta vez. La distinción entre la intención que viene lista y la intención que es tuya, esa no la veo cambiando con el próximo lanzamiento.