Два AI-агента собирают дизайн-систему, дизайнер занимается крафтом

Откуда взялась идея

Я собирал дизайн-систему для личного кабинета покупателя: токены, variables, компоненты. В компании для этого есть понятный процесс, этапы и правила оформления и нейминга. На ручную сборку дизайнеру выделяют целый рабочий день. Я подумал, что работа с такими чёткими правилами подходит агенту.

Первая проба в Claude Code через Figma MCP дала неплохую основу, но оформление сильно отличалось от принятого в компании.

Как получил поддержку

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

Как строил

1. Канон компании. Разобрал эталонные системы вместе с агентом, отвечал на его вопросы. Записали, что используем, что нет и как оформляем.
2. Первый прогон. Дизайн-система собирается после согласования главной страницы, поэтому я дал агенту главную реального проекта. Типографику и цвета он описывал хорошо, но ошибался: додумывал то, чего нет в макете, и сдавал недоделанное как готовое. Финальной проверки не было.
3. Второй агент — ревьюер. Он проверяет каждый этап до показа дизайнеру и сверяет с макетом числами: состав, отступы, эффекты. Без его отчёта сдавать нельзя. Со второго прогона результат стал хорошим.
4. Каждая ошибка становится правилом. За 4 прогона накопился учебник агента: разбор 114 ошибок, около 15 документов правил и 54 описанные ловушки Figma. Закрытые ошибки больше не повторялись.

Как это работает для дизайнера

• Вопросы до работы. Агент изучает макет и сначала спрашивает: почему здесь такой отступ, такой размер, этот элемент. Несоответствия находятся до сборки, а не после.
• Ссылки прямо в тексте. Каждый элемент в сообщении агента — ссылка на узел в Figma. Дизайнер кликает по слову и сразу видит элемент.
• Точки участия. Дизайнер даёт входные файлы, отвечает на вопросы, утверждает спецификацию, принимает работу по отчёту ревьюера и публикует библиотеку. Остальное делает агент: токены, стили, компоненты, а затем модули страниц.
• Описания для разработки. У каждого компонента есть описание: зачем он, где используется, как ведёт себя при fill и hug и чего избегать. Его читают и разработчики, и их AI-агенты.

Агент не просто заводит токены, а объясняет каждый: зачем он, где применяется и сколько раз встречается в макете. Если назначение неясно, он не додумывает, а помечает: «добавлен другим дизайнером, назначение не зафиксировано — уточнить или удалить».

Результат (замер на реальном проекте)

• Около 1,5 часа дизайнера вместо 8–10 часов ручной сборки дизайн-системы с модулями.
• 23 компонента, 143 токена, 12 стилей, 8 секций главной для desktop и mobile.
• Ревьюер нашёл 17 дефектов, 10 из них критичных, до того как работу увидел человек.
• Вмешательств дизайнера стало 2 вместо 12 циклов правок.
• Слепая сверка с дизайн-системой того же проекта, собранной руками (агент её не видел): 0 пропущенных состояний против 59, описания у 100% компонентов против 0%, ни одной опечатки и дубля.

Где остаётся человек

Публикует библиотеки только дизайнер, и он же остаётся последним контуром проверки: «кнопки беднее макета» по-прежнему замечает глаз. Агент сдаёт работу так, чтобы проверка занимала минуты: со скриншотами, таблицами и отчётом ревьюера.

Главный вывод

Работу сделали не «умная модель», а записанные правила: канон, роли агентов, обязательная проверка, реестр ошибок. Поэтому систему можно передать команде, она не живёт в одном чате.