В прошлой статье про StyleX я разбирал, почему компилируемый CSS выглядит логичным продолжением ветки CSS-in-JS. Одно из главных свойств StyleX для меня — предсказуемость: стили описываются в ограниченной форме, которую можно анализировать ещё до запуска приложения.

Это особенно важно в момент, когда код всё чаще пишет не только человек, но и AI-ассистент. Если инструмент допускает любую форму записи стилей, ассистент рано или поздно начнёт пользоваться всей этой свободой: добавлять магические значения, дублировать решения, обходить токены и постепенно размывать дизайн-систему. StyleX сужает пространство для таких ошибок.

Теперь Meta открыла Astryx — дизайн-систему, построенную на React и StyleX. На первый взгляд это выглядит как релиз большой библиотеки: больше 170 компонентов, темы, тёмный режим, шаблоны, CLI, всё как мы любим. Но количество компонентов здесь не самое интересное. Astryx стоит рассматривать как следующий шаг после StyleX: если StyleX делает предсказуемыми стили, то Astryx пытается сделать предсказуемой работу с интерфейсом целиком — и для человека, и для AI-агента.

Что выпустила Meta

Meta позиционирует Astryx как открытую дизайн-систему, которая полностью кастомизируется и готова к работе с агентами. Проект пока находится в бете, требует React 19+, а внутри Meta, по словам команды, его основа развивалась около восьми лет и теперь обслуживает больше 13 000 приложений.

В публичном виде Astryx даёт:

• библиотеку компонентов;

• готовые шаблоны страниц и блоков;

• компоненты и шаблоны для AI-продуктов;

• темы на CSS-переменных;

• поддержку StyleX, Tailwind и обычного className;

• CLI для поиска компонентов, шаблонов, документации и генерации проекта;

• MCP-сервер, через который AI-инструмент может сам читать документацию системы.

Показательно, что первая же страница документации начинается не с команды установки, а с раздела Quick Start with AI. Пользователю предлагают вставить готовый промпт в инструмент разработки: установить пакеты, запустить init, сгенерировать документы для агента и прочитать правила проекта.

На этом уровне Astryx выглядит как стандартный набор современной дизайн-системы. Восприятие меняется, когда начинаешь разбирать документацию и инструменты: описания компонентов структурированы так, чтобы из них можно было собирать вывод CLI, плотную версию для контекстного окна модели, MCP-ответы, списки компонентов, подсказки по темизации и проверяемые правила. Документация становится не только сайтом, но и машиночитаемым слоем дизайн-системы.

Почему это продолжение StyleX

StyleX заставляет описывать стили в форме, которую можно анализировать. Стили живут в stylex.create, токены проходят через типизацию, итоговый CSS компилируется заранее, а динамика выражается явно. Это не убирает все ошибки, но делает их заметнее. Astryx берёт ту же идею и поднимает её уровнем выше.

На уровне целого интерфейса пространство ошибок расширяется. Ассистент может:

• выбрать не тот компонент;

• придумать несуществующий проп;

• собрать форму из сырых div;

• обойти тему локальными стилями;

• сделать красивый, но не системный интерфейс;

• скопировать общий React-паттерн вместо паттерна конкретной дизайн-системы.

Обычная библиотека компонентов с этим справляется плохо. У неё может быть хороший сайт, Storybook и примеры, но AI-агенту всё равно приходится угадывать: как искать компонент, какой проп отвечает за поведение, какие правила обязательны, где лежат шаблоны, какие способы выхода за пределы базового API допустимы, а какие ведут к техническому долгу.

Astryx пытается убрать угадывание из процесса, и здесь как раз видно родство со StyleX. Обе системы ограничивают свободу в тех местах, где она слишком легко превращается в хаос.

Что значит agent-ready на практике

Слово agent-ready легко превратить в маркетинговую наклейку, поэтому полезнее посмотреть, что в Astryx реально сделано для AI. На мой взгляд, одного промпта в README здесь недостаточно. Дизайн-система становится удобной для агента, когда у неё есть:

• предсказуемый API;

• структурированная документация;

• машинно-читаемые контракты;

• короткий путь от намерения к рабочему коду;

• ограничения, которые можно проверить автоматически;

• инструменты, через которые агент получает правильный контекст в правильный момент.

Это хорошо совпадает с общей логикой AI-first разработки: модели не нужен весь контекст сразу, ей нужен правильный контекст под конкретную задачу. В Astryx эта мысль реализована довольно буквально.

Документация как данные

Одна из самых важных деталей в кодовой базе Astryx — формат документации компонентов. Для них есть .doc.mjs файлы со структурированным описанием: название, ключевые слова, пропсы, примеры, практики использования, анатомия компонента, цели темизации, компонентные и производные переменные, дополнительные секции.

Структурированный файл можно красиво отрисовать на сайте, а затем прочитать программно и собрать из него CLI-ответ, подсказку для агента, индекс поиска, MCP-ответ или плотную версию для контекстного окна. Например, у Button документация содержит не только список пропсов, но и ключевые слова вроде button, cta, submit, loading, primary. Для человека это почти незаметная деталь, а для агента — способ найти нужный компонент по пользовательскому намерению.

Отдельно интересна поддержка docsDense — сжатой версии документации, которая при этом не превращается в короткий пересказ “для красоты”. Внутри репозитория есть отдельный протокол плотной документации: нужно сохранять слова вроде must, never, always, instead, обязательные пропсы, имена компонентов, связи между компонентами и важные ограничения.

Это важная инженерная деталь. Когда мы сжимаем документацию для AI, нельзя просто выбросить “лишнюю прозу”: иногда одно слово never или instead меняет поведение модели сильнее, чем целый абзац объяснения.

Для дизайн-системы это особенно важно. Агенту недостаточно знать, что компонент существует. Ему нужно понимать, когда его использовать, какие пропсы нельзя придумывать и чем заменить неправильный паттерн.

CLI как интерфейс дизайн-системы

В обычной дизайн-системе CLI, если он есть, часто отвечает за установку, генерацию компонентов или создание темы. В Astryx он становится отдельным интерфейсом для человека и агента.

Через него можно:

• найти компоненты;

• прочитать документацию компонента;

• получить список шаблонов;

• получить каркас (skeleton) шаблона;

• подобрать страницу, блоки и компоненты по описанию задачи через astryx build;

• собрать тему;

• проверить проект через doctor;

• выполнить миграции через upgrade;

• получить манифест возможностей — машинно-читаемое описание всех команд, аргументов, флагов и типов ответов.

Последний пункт особенно важен. В коде CLI есть манифест, который описан почти как аналог OpenAPI для командной строки. Агенту не нужно парсить --help как обычный текст: он может получить структурированное описание возможностей CLI.

Кроме того, команды поддерживают JSON-режим с устойчивой формой ответа:

{
  "apiVersion": 1,
  "type": "component",
  "data": {}
}

Ошибки тоже имеют стабильные коды: ERR_UNKNOWN_COMPONENT, ERR_UNKNOWN_TEMPLATE, ERR_INVALID_ARGUMENT и так далее. В комментариях к коду прямо написана причина: человек читает текст ошибки, но AI-агенты и CI не должны ветвиться по человеческой фразе, потому что текст можно поменять.

Это небольшой, но очень зрелый признак. Чтобы агент надёжно работал с инструментом, ему нужен не только красивый вывод в терминале, но и контракт, на который можно опереться в коде.

Агенту дают маршрут, а не просто каталог

В документации Astryx есть раздел Working with AI. Там предлагается установить CLI и выполнить:

npx @astryxdesign/cli init --features agents

Эта команда генерирует контекстные файлы для AI-инструментов: AGENTS.md, CLAUDE.md, .cursorrules и другие варианты. Внутрь вставляется блок Astryx с маркерами, чтобы его можно было обновлять вместе с библиотекой. При этом важен не только сам файл с правилами, но и рабочий процесс, который в него закладывается.

В актуальном CLI над этим маршрутом появился ещё один вход:

astryx build "analytics dashboard with filters and a table"

Команда собирает кандидатов сразу из компонентов, хуков, документов и шаблонов. Запрос очищается от служебных слов, расширяется через словарь синонимов, а затем результаты ранжируются по точному имени, ключевым словам, близости написания и покрытию понятий из запроса.

Внутри нет отдельной модели и сетевого вызова. Это детерминированный поиск: одинаковый запрос должен вернуть одинаковый набор. На выходе агент получает не только список совпадений, а рекомендуемый первый шаг, ближайший шаблон страницы, подходящие блоки, недостающие компоненты и базовый каркас.

Дальше маршрут выглядит так:

1. запустить astryx build "<задача>";

2. собрать подходящий шаблон или изучить его каркас через --skeleton;

3. прочитать точную документацию каждого используемого компонента;

4. собрать интерфейс на компонентах и токенах;

5. прогнать автоматические проверки и отдать результат на дизайн-ревью.

Вместо каталога из 170 с лишним компонентов агент получает маршрут с понятной последовательностью действий. Это сильно отличается от обычной документации дизайн-системы. Человек может глазами пробежать список, открыть демо и вспомнить похожий паттерн. Агенту нужен более явный порядок действий, иначе он легко вернётся к общим React-паттернам, которые видел в обучающих данных. Astryx прямо признаёт эту проблему: без правильного контекста модели уверенно угадывают неправильные импорты, пропсы и варианты поведения.

MCP: правильный контекст в правильный момент

Ещё одна важная часть — MCP-сервер. MCP, если коротко, это протокол, через который AI-инструмент может обращаться к внешним источникам и инструментам. В случае Astryx сервер открывает две базовые операции:

• search(query) — найти компоненты, документы и шаблоны;

• get(name) — получить полную документацию по компоненту, теме или шаблону.

Операций немного, но архитектурно это важный шаг. Если агенту нужен выпадающий список, ему не приходится держать всю документацию Astryx в контексте. Он может спросить систему, что в ней есть для dropdown menu или selector, а затем получить документацию конкретного компонента.

Контекст подтягивается под задачу. Это один из ключевых принципов AI-first разработки: не складывать всю базу знаний в промпт, а давать агенту инструменты для точного поиска нужного фрагмента.

Для дизайн-системы это особенно полезно, потому что документация быстро разрастается. Больше 170 компонентов, варианты, примеры, темы, состояния, рекомендации по доступности — всё это нельзя эффективно держать в контексте модели постоянно, но можно сделать доступным через инструмент.

Дизайн-система для самих AI-продуктов

Есть ещё один слой, который сначала легко пропустить. Astryx помогает AI-агенту собирать интерфейсы и одновременно предлагает набор компонентов и шаблонов для продуктов, где AI является центральной частью пользовательского опыта.

В основном пакете есть отдельная группа Chat. Это не один компонент “чатик”, а несколько слоёв:

• раскладка и сообщения: ChatLayout, ChatMessageList, ChatMessage, ChatMessageBubble, ChatMessageMetadata, ChatSystemMessage;

• область ввода: ChatComposer, ChatComposerInput, ChatComposerDrawer, ChatSendButton, ChatDictationButton, ChatComposerTokenElement;

• работа агента: ChatToolCalls, ChatTokenizedText, прокрутка и потоковое появление ответа.

В документации Chat прямо описан как набор составных частей для AI-чатов и обычных пользовательских переписок. То есть система закрывает не только классические интерфейсы вроде форм, таблиц и настроек, но и новые паттерны, которые стали массовыми из-за AI-продуктов.

Особенно показателен ChatToolCalls. Он отображает вызовы инструментов из ответа модели: какой инструмент запущен, к какому файлу, команде или поисковому запросу он относится, сколько занял времени, завершился ли ошибкой и какой результат можно раскрыть. Для изменений кода компонент умеет показывать статистику добавленных и удалённых строк, а для команд — вывод терминала. Так чат превращается в интерфейс наблюдаемости агента: пользователь видит не только ответ, но и ход работы, статус и последствия действий.

Есть и два готовых шаблона страниц:

• AI Chat Landing — стартовый экран AI-ассистента с областью ввода, вложениями, категориями и режимами;

• AI Chat Conversation — полноценный экран диалога с вызовами инструментов, системными сообщениями, Markdown, блоками кода, группировкой сообщений и изменяемой по размеру панелью артефакта.

Здесь появляется интересная петля. Astryx делает дизайн-систему удобной для AI-агентов, которые пишут код, и одновременно содержит готовые интерфейсные паттерны для продуктов, где пользователь взаимодействует с AI-агентом. Получается, что система с помощью AI помогает строить сами AI-продукты.

Это важный сдвиг для дизайн-систем. Раньше им было достаточно описать кнопки, поля, модальные окна, таблицы и базовые паттерны раскладки. Теперь в продуктовой реальности появляются новые устойчивые интерфейсные сущности:

• поле ввода запроса;

• потоковый ответ;

• вызов инструмента как видимое действие агента;

• панель артефакта;

• системное сообщение агента;

• статус выполнения;

• вложения и токены в области ввода;

• команды через /;

• упоминания через @;

• режимы и категории задач.

Если дизайн-система не описывает эти паттерны, продуктовые команды всё равно начнут собирать их сами. А значит, появятся десятки разных чатов, разные способы показывать действия агента, разные области ввода и разная степень прозрачности для пользователя.

Astryx фиксирует AI-интерфейсы как полноценную часть дизайн-системы. На мой взгляд, это сопоставимо по важности с MCP и документами для агента, потому что AI меняет и процесс написания кода, и сами интерфейсы, которые мы начинаем проектировать.

Компоненты, токены и запреты

На уровне самой системы Astryx закрепляет несколько принципов:

• компоненты важнее сырых примитивов;

• семантические токены важнее хардкода;

• код должен быть независимым от конкретной темы;

• раскладка строится через системные компоненты;

• плотные представления данных не нужно превращать в набор карточек;

• не стоит изобретать пропсы;

• нельзя уходить в style={{}} и магические значения.

Это звучит знакомо для любой зрелой дизайн-системы. Разница в том, что в Astryx эти правила не остаются только на странице с принципами. Например, стилизация компонента может идти через xstyle, интеграцию с Tailwind, className или тему, но системный путь всё равно ведёт через токены. Для StyleX доступны типизированные токены, сопоставление Tailwind завязано на те же значения, а темы собираются в CSS-переменные.

У команды есть выход за пределы базового API, но он не превращает систему в набор случайных решений. Это важный баланс: слишком закрытая дизайн-система быстро начинает раздражать продуктовые команды, а слишком открытая перестаёт быть системой. Astryx пытается дать несколько уровней кастомизации:

• использовать готовый компонент;

• изменить его через токены и тему;

• добавить локальную стилизацию через поддерживаемый механизм;

• при необходимости выполнить swizzle компонента и забрать исходники под свою ответственность.

Для AI это тоже важно. Агенту нужно понимать не только “как сделать”, но и “какой путь предпочтителен”. Если такой иерархии нет, он почти всегда выберет самый короткий локальный хак.

Темизация без угадывания CSS-селекторов

Система темизации в Astryx тоже хорошо показывает этот подход. Темы описываются через defineTheme: можно наследоваться от базовой темы, переопределять токены, компоненты, иконки, типографику, анимацию и другие слои. Компонентные переопределения задаются семантическими ключами вроде base, variant:primary или состояниями, а не случайными CSS-селекторами.

Внутри theme build используются данные из документации компонентов. Сборщик знает визуальные пропсы, может предупредить об опечатках и сгенерировать TypeScript-декларации для кастомных вариантов.

Это ровно тот случай, когда дизайн-система становится удобной за счёт связки, которая помогает агенту не промахнуться в названии пропса и не записать CSS в обход контракта:

• токены;

• типы;

• генерация;

• проверка;

• документация из одного источника.

Проверки важнее надежды

Самая слабая версия готовности к агентам сводится к мысли: мы написали инструкцию для AI, теперь он будет делать правильно. В реальности этого недостаточно. Агенты ошибаются, контекст теряется, инструкции конкурируют друг с другом, а модель может уверенно придумать несуществующий API. Поэтому важные правила должны проверяться автоматически.

В Astryx для этого есть несколько слоёв. astryx doctor проверяет проект и отдаёт структурированный отчёт: что установлено, совпадают ли версии core и CLI, подключена ли тема, есть ли документы для агента с маркерами Astryx. В JSON-режиме это безопасно для CI и AI-агентов.

astryx upgrade запускает автоматические миграции кода (codemods) при обновлении версии и после этого обновляет документы для агента, если они уже есть в проекте. Это важная деталь: контекст агента не должен оставаться на старой версии библиотеки.

Внутри репозитория есть ESLint-плагин Astryx. Его философия прямо описана как двухуровневая: для людей локально правила могут быть предупреждениями, для агентов и CI — ошибками. Мне нравится эта формулировка. Людям во время разработки иногда нужна гибкость, а агенту, который генерирует код по задаче, не нужна “творческая свобода” нарушать токены, называть булевые пропсы как попало или ломать правила презентационных компонентов.

Если правило важно для архитектуры, оно должно быть проверяемым. Иначе агент рано или поздно его нарушит.

Vibe tests как отдельный сигнал зрелости

Отдельно отмечу стенд Astryx для vibe tests — сравнительных проверок того, как AI собирает интерфейсы в разных условиях. Один и тот же набор задач запускается в четырёх конфигурациях: чистый Astryx, Astryx с Tailwind, базовая связка shadcn/Tailwind и сырой HTML. Затем отдельный агент оценивает результат по корректности, доступности, качеству кода, эффективности, поддерживаемости и визуальному результату.

Авторы специально ушли от проверки “использовал ли агент Astryx так, как мы хотим”. Такая метрика заранее объявляла бы собственную систему правильным ответом. Текущая версия оценивает свойства хорошего результата одинаково для всех вариантов.

У тестов есть несколько важных ограничений:

• промпты описывают пользовательский сценарий, а не подсказывают компонент;

• агенты начинают со свежим контекстом;

• подзадачи изолированы друг от друга;

• результат оценивает отдельный агент;

• один и тот же детерминированный анализ применяется ко всем конфигурациям.

Самое симпатичное здесь — команда публикует не только удачные результаты. В одном ночном запуске Astryx получил 98 баллов против 95 у базовой связки. В другом упал до 77 из-за выдуманных импортов и пропсов и проиграл. По их собственному сводному журналу базовая конфигурация вообще выигрывает больше отдельных ночей.

Это делает эксперимент полезнее маркетинга. “Удобство для AI” здесь рассматривается не как постоянное свойство библиотеки, а как измеряемая гипотеза, которая может сломаться после изменения API или документации.

Тесты запускаются каждую ночь. Если появляется повторяемая ошибка, отдельный агент-разборщик классифицирует сбой, воспроизводит его и может открыть pull request к документации или CLI. Получается замкнутый контур: агент пользуется системой, тест находит место, где система оказалась непонятной, другой агент предлагает исправление, а человек проверяет изменение.

Агенты обслуживают саму дизайн-систему

После релиза стало видно ещё одно продолжение идеи: агенты могут не только пользоваться Astryx, но и помогать её поддерживать. Например, команда выпустила библиотеку Astryx для Figma. Её состояние на каждом небольшом релизе проверяет ночная задача Figma Librarian: она подключается к Figma через MCP, читает правила построения компонентов и синхронизирует библиотеку с кодом. Figma при этом остаётся средой для быстрых визуальных поисков, а не отдельным источником спецификаций, который нужно вручную догонять за реализацией.

Похожий подход использовали для локализации. AI подготовил первый перевод примерно 250 строк на 29 языков, детерминированный валидатор проверил ICU-синтаксис, плейсхолдеры и формы множественного числа, а вторая модель проверила смысл и тон. Команда при этом прямо оставляет последнее слово носителям языка.

Для поддержки письма справа налево одного линтера оказалось мало, поэтому Astryx рендерит истории компонентов в обоих направлениях и сравнивает геометрию элементов. Это хороший пример общей логики проекта: инструкция важна, но от сложных ошибок защищает только проверка реального результата.

Мне кажется, именно здесь термин “агентно-ориентированная дизайн-система” раскрывается полностью. Речь идёт о документации, поиске, проверках и процессах сопровождения, в которых агент может быть полноценным участником, но не последней инстанцией.

Что делает дизайн-систему удобной для AI

Если обобщить, Astryx показывает довольно понятный набор признаков agent-ready дизайн-системы:

1. Предсказуемый API. Компоненты должны называться и вести себя последовательно, пропсы должны быть типизированы, варианты — ограничены, импорты — стабильны. Чем больше исключений, тем чаще агент будет уходить в догадки.

2. Документация как источник данных. Если описание компонента можно использовать только глазами в браузере, агенту будет неудобно. Если из него можно построить CLI, MCP, поиск, плотный формат и проверки — это уже инфраструктура.

3. Инструментальный доступ. AI не должен прокручивать сайт как человек. Ему нужны команды build, search, get, component, template, doctor, JSON-ответы, стабильные коды ошибок и понятный манифест возможностей.

4. Маршруты сборки интерфейса. Шаблоны, каркасы и наборы для сборки уменьшают вероятность, что агент начнёт строить интерфейс из случайных блоков. Поиск должен возвращать не только совпадения, но и рекомендуемый следующий шаг.

5. Проверяемые правила. Токены, запрет сырых стилей, правила именования, структура тем, актуальность документов для агента и миграции между версиями должны быть подкреплены линтерами, типами, автоматическими миграциями и проверками состояния проекта.

6. Безопасные выходы за пределы базового API. Продуктовая команда всё равно захочет выйти за пределы базового компонента. Хорошая система делает этот путь явным: тема, токены, xstyle, className, swizzle. Чем ниже уровень, тем больше ответственности.

7. Измеримое удобство для AI. Сравнительные прогоны, свежий контекст, одинаковые задачи и публичные неудачи дают больше пользы, чем заявление “наш API понятен моделям”. Повторяемые ошибки должны возвращаться в документацию, инструменты и тесты.

Где не стоит обольщаться

При этом Astryx не доказывает, что AI уже способен самостоятельно и безошибочно проектировать интерфейсы. Готовность к агентам ещё не означает готовность к автономному дизайну.

Система может помочь агенту выбрать правильный компонент, не придумать проп, не уйти в style={{}} и подтянуть документацию через MCP. Но она не решает за него продуктовую задачу, не понимает бизнес-контекст глубже доступных данных и не заменяет дизайн-ревью.

Кроме того, Astryx сейчас находится в бете. API, подходы и инструменты могут меняться. Для небольших проектов всё это может быть избыточно: если у вас лендинг на несколько экранов, полноценный слой CLI, MCP, автоматических миграций и документов для агента может оказаться тяжелее самой задачи. Для больших продуктовых систем направление выглядит логичным, особенно если дизайн-система живёт как общий язык для десятков команд, внутренних инструментов и всё большего количества AI-ассистированной разработки.

Итог

Главная ценность Astryx выходит далеко за пределы новой библиотеки компонентов. Проект показывает момент, когда дизайн-система начинает разворачиваться от людей к AI-агентам.

Первое поколение дизайн-систем помогало людям договариваться. Дизайнер собирал макет из компонентов, разработчик открывал документацию, сверял пропсы, переносил решение в код, а команда проверяла, что результат соответствует правилам. Компоненты, токены и гайдлайны снижали стоимость этой коммуникации.

С агентами меняется не только скорость этого процесса, но и его основной исполнитель. Агент не листает Storybook, не запоминает устные договорённости команды и не догадывается, что скрывается за визуальным примером. Ему нужны структурированные документы, поиск по намерению, программные интерфейсы, стабильные контракты, эталонные шаблоны и проверки, которые не позволят незаметно выйти за пределы системы.

Astryx стоит рассматривать как ранний пример следующего поколения дизайн-систем, где AI-агент становится основным потребителем инфраструктуры. Человек задаёт принципы, проектирует хорошие примеры и определяет планку качества. Агент получает маршрут, собирает интерфейс, проверяет ограничения и участвует в сопровождении самой системы.

StyleX сделал стили предсказуемыми и анализируемыми для инструментов. Astryx продолжает эту линию на уровне всего процесса: от выбора шаблона до миграции, тестирования и синхронизации библиотеки в Figma. Оба проекта развивают одну идею на разных уровнях.

Для меня главный вывод такой:

Следующее поколение дизайн-систем будет проектироваться прежде всего для AI-агентов: не как каталог, который им разрешили читать, а как исполняемая среда, где они могут найти правильное решение, собрать его и доказать, что не нарушили правила.

И Astryx важен именно как сигнал этого разворота. Дизайн-система больше не заканчивается там, где человек открыл документацию. Она только начинается в тот момент, когда к ней обратился агент.