Я один из организаторов конференции ДевФест. Исторически наш сайт был сделан на Тильде. После выхода Claude Design я решил пересобрать сайт с помощью ИИ-агентов. 

К концу эксперимента стало ясно: для маркетингового сайта конференции открытый стек на Claude Code оказался полностью самодостаточным — ни Тильда, ни Claude Design нам в итоге не понадобились.

1. Начало пути

Стартовал я с Claude Design. После анонса очень хотелось его пощупать. Но довольно быстро поймал тотальное разочарование. Первое - он жрёт токены: мне не хватало лимитов на подписке Max 5x. Второе, еще более неприятное – он работает как чёрный ящик.

Кидаешь промпт, получаешь результат, но что именно агент делает внутри, какими принципами руководствуется, как принимает решения — непонятно. При том, что под капотом это, по сути, просто пачка скиллов для Claude Code, обёрнутых в закрытый продукт.

Возможно, командам без подписки на Claude Code и без желания копать в скиллы Claude Design зайдёт. Мне — нет: я платил за обёртку и не видел, что внутри. В этот момент я и наткнулся на Open Design — открытую альтернативу, которая добавляет скиллы для Claude Code и делает из него управляемый Claude Design. Теперь и дизайн-система лежит у тебя в репо как обычный markdown, и ты сам видишь, по каким правилам агент её правит. Дальше про то, что из этого получилось.

2. Дизайн-система живёт в DESIGN.md, который коммитится в git

Главная архитектурная вещь, которую делает Open Design — он пишет дизайн-систему как обычный markdown-файл в твоём репозитории. Не в облако, не в свою БД, не в JSON у себя на сервере. Файл по стандарту TypeUI: палитра, типографика, эффекты, компоненты, правила Do/Don’t:

# DESIGN.md

## Color Tokens
| token            | hex     | role                          |
| ---------------- | ------- | ----------------------------- |
| brand-green      | #34A853 | success, day-3 chip           |
| brand-blue       | #4285F4 | links, info accents           |
| brand-red        | #EA4335 | destructive, error states     |
| brand-yellow     | #FBBC04 | primary CTA, focus rings      |


## Typography Tokens
- display: Google Sans, 56/64, weight 700
- body: Google Sans Text, 17/26, weight 400

## Rules: Don't
- Никаких прямых hex в компонентах. Всё через токены.
- Никаких пастельных вне определённых выше.

Что меняется? У дизайн-системы появляются git log, git blame, ветки и diff. Когда токен сдвигается — это коммит, на который можно посмотреть, обсудить в PR и при необходимости откатить. Не «последнее сообщение в треде с моделью», а конкретное изменение с автором и датой. Design as a Code в чистом виде. Ветки — как у кода. Смена какой-то части брендбука — feature-branch, а не «слегка перезатёрто среди ночи».

И ещё одно следствие: правило про «никаких прямых hex в компонентах» теперь живёт рядом с цветами, а не где-то в head’е дизайнера. Любой #34A853 в .tsx — это код-смелл, который ловится одним grep’ом.

3. Open Design редактирует реальные файлы репо через symlinks

Когда я заводил проект в Open Design, ожидал, что он попросит загрузить репозиторий или будет дёргать GitHub-API. Получилось проще и сильно лучше.

OD-проект на диске — это папка с symlinks на реальные пути моего репозитория сайта. UI открывает их и правит те же байты, которые видит Claude Code при npm run dev. Никакого пайплайна «выгрузить дизайн-систему — переложить в код — засинкать». Никакого формата import/export. Никакой развилки между «как было в туле» и «как лежит в проде».

Что меняется? Когда я в OD UI поправил пастельный жёлтый, а потом запустил next dev , он подхватил то же значение. Не нужно было ни мерджить, ни синхронизировать. Удивительно, насколько много проблем с синхронизацией отпадает, когда дизайнер перестает жить отдельно от кода! :)

4. Брендбук и веб-система — два разных файла, общий источник цветов

Брендбук конференции у нас сделан под социальные посты 1080×1080: типографика заточена на квадрат, есть прописанные плакатные размеры, агрессивные сетки. Это нормально для постов, но не работает для веба. На лендинге другой rhythm, другой scale, другие пропорции hero и body.

Я долго пытался запихнуть брендбук в одну дизайн-систему. Получалось плохо. Open Design подсказал решение, которое выглядит очевидным, но мы его сами почему-то не сделали раньше: держать брендбук и веб-систему разными файлами.

В OD-проекте теперь два BRAND.md (брендбук, source of truth для палитры и фирменных шрифтов) и DESIGN.md (веб-система, со своим type-scale, своими spacing-токенами и своими component-rules). Веб-файл импортирует токены цветов из брендбука и дальше живёт самостоятельно.

Что меняется? Когда дизайнер сдвигает оттенок зелёного в брендбуке — он сдвигается и на сайте, и в социальных постах автоматически. Когда я меняю кегль h1 на лендинге, это не ломает плакатные размеры. Один источник правды для бренда, два разных контекста использования.

5. Один файл использует много агентов: теперь у нас design-as-code

Это следствие первой практики, но достаточно важное, чтобы вынести отдельно.

Когда дизайн-система — это plain-text файл в репо, её одинаково читают любые AI-агенты. Я прошу Claude Code собрать карточку доклада: он читает DESIGN.md. Открываю Cursor, чтобы переписать тестимониалы - он читает тот же файл. Переключаюсь на Codex для эксперимента - он читает тот же файл.

Что меняется? Никакого лок-ина на конкретный инструмент. Если завтра Anthropic выкатит новую модель, я переключаюсь на неё одной строкой, и контекст сохраняется. Если друг пишет на Cursor, я делюсь репозиторием, и его агент знает мою дизайн-систему через тот же DESIGN.md. Если хочется на одном проекте параллельно гонять две разные модели — без проблем.

Это в каком-то смысле возвращает дизайн-систему в ту же категорию, что и код: версионируемый текстовый артефакт, который универсально читается любым инструментом. Design-as-code в буквальном смысле, а не в маркетинговом.

7. Голосовые вместо WYSIWYG

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

Также при работе с ИИ-агентом мы не ограничиваемся каким-то набором блоков. Мы можем придумать любой нужный нам блок, и любую нужную нам интеграцию. Claude Code ловит идею с полуслова и быстро реализует ее. По сравнению с Тильдой это ощущается как магия. 

8. Чего не хватает до автопилота

Было три места, где работать пришлось руками.

Перформанс. Мобильный Lighthouse у меня сейчас 61. Дизайн и логику ИИ-агент тянет в автоматическом режиме, а про перформанс не думает. Было бы здорово, если он сам умел тестить перформанс и делать на 90+ баллов.

Насмотренность. Агент отвечает на вопрос «как», но не на «зачем именно так». Решение «hero — это видеотизер в кинокресле, а не баннер с заголовком» было принято нашим шоураннером, а не инструментом. ИИ-агент может нарисовать пятнадцать вариантов hero, для него они все будут классные, выбирает он плохо.

Дисциплина ведения дизайн системы. DESIGN.md сам по себе не запрещает писать инлайн-цвета. Это делаешь ты, ты ревьюишь. Если расслабиться, через две недели в коде накопятся хардкоженные hex’ы и появятся «удобные» токены вроде surface-1 / divider-soft, которые используются один раз и захламляют систему.

8. Бонус: исходный код проекта

Код сайта открыт: https://hub.mos.ru/devfest-ru/site/website.
Open Design: https://github.com/nexu-io/open-design.
Если соберёте у себя - расскажите в комментариях, какой блок переделали и сколько ушло времени. А ещё интересно: где у вас сейчас лежит источник правды дизайн-системы: в Figma, в чате с дизайнером или в конфиге scss?