Сильнее всего AI проявляет себя в роли ревизора и документатора уже существующего, а не генератора нового дизайна. Kirk, автор канала UI Collective, показывает это на живом примере. Стоит разобрать его пошагово — механика тут важнее вывода. Показательно, что тот же автор честно демонстрирует обратную сторону: попытка собрать дашборд через Figma Make, синхронизированный с дизайн-системой, на выходе даёт визуально похожий результат, который при вставке обратно в Figma не использует ни одной настоящей переменной — только скопированный внешний вид с произвольными числами вместо токенов spacing. Компоненты AI пока группирует, а не собирает через auto layout, и почти всегда быстрее построить экран с нуля самому, чем разгребать то, что сгенерировано. AI хорош там, где нужно свериться с уже существующей структурой, и заметно хуже там, где эту структуру нужно создать впервые.

Схема простая. Берёшь таблицу токенов дизайн-системы, скармливаешь её агенту через Claude, подключённый к файлу Figma по MCP. Дальше агент строит из таблицы токенов правило — отдельный файл-инструкцию, который постоянно лежит у него "в памяти". Его не нужно пересказывать заново при каждом запросе. Это правило превращается в переиспользуемую команду: даёшь ей ссылку на любой компонент или страницу, и агент построчно сверяет фактическое использование цвета, бордера, текста, иконки с тем, что предписано правилом. Если элементу с текстом назначен токен цвета бордера вместо токена цвета текста — команда это найдёт. И назовёт явно, с указанием, какой токен нужен вместо ошибочного. Kirk оценивает ускорение такого аудита примерно в 50 раз по сравнению с ручной построчной проверкой. Причём это не разовый фокус для одного демо — рабочая команда, которую можно гонять на каждый новый экран.

Тот же паттерн "правило + команда" работает и для документации дизайн-системы. Отдельное правило прямо запрещает агенту выдумывать use-case, которого нет в переданных компонентах. И требует переспрашивать, если для описания нужно сделать предположение о назначении элемента. Без этого запрета модель с высокой вероятностью выдаст правдоподобно звучащую, но придуманную документацию — просто потому что задача "опиши компонент" сама по себе провоцирует на выдумку.

А вот здесь стоит остановиться на распространённой ошибке: тезис "AI не умеет работать с переменными дизайн-системы" неверен в общем виде. Он верен только для одного конкретного сценария — когда AI получает текстовый промпт без прямого доступа к реальным Figma-переменным и вынужден визуально угадывать структуру. Именно так ведёт себя Figma Make, синхронизированный с дизайн-системой лишь номинально: он выдаёт визуально похожий результат, но при вставке обратно в Figma тот не использует ни одной настоящей переменной. Только скопированный внешний вид с произвольными числами вместо токенов spacing. Компоненты при этом собираются через группы, а не auto layout, так что их всё равно приходится пересобирать вручную.

Но стоит дать модели прямой доступ к переменным через API — а не заставлять угадывать по картинке — и та же задача решается иначе. У Figma-плагина для Claude Code есть готовый набор инструкций figma-generate-library: он строит дизайн-систему через реальные вызовы Plugin API, с настоящими привязками к переменным, а не текстовым описанием того, как система должна выглядеть. У Pencil MCP есть прямые функции get_variables/set_variables — можно буквально попросить агента "пройдись по файлу и приведи переменные в соответствие", и это будет не эвристика по скриншоту, а операция над реальными данными файла. Разница между "не умеет" и "не умеет без нужного инструмента" здесь принципиальная. Одно — фундаментальное ограничение модели. Другое — вопрос того, каким интерфейсом её снабдили.

За этим стоит более глубокая техническая причина, почему у обычного text-to-design в принципе плохо с токенами. У токенов есть иерархия: глобальные значения вроде blue-500: #3B82F6, семантические алиасы вроде color-action-primary, которые ссылаются на глобальные, и компонентные токены вроде button-color-primary, которые ссылаются на алиасы. Просто "посмотреть на скриншот кнопки" не даёт увидеть эту цепочку ссылок — она существует только в структуре файла, а не в его визуальном рендере. Инструмент, который читает структуру файла напрямую через API или MCP, видит всю иерархию токенов. Инструмент, который реконструирует дизайн по картинке, иерархии не видит вообще — и неизбежно придумывает случайные числа вместо ссылок на алиасы.

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

Хейни объясняет, чем это принципиально отличается от облачных no-code конструкторов вроде Lovable, v0 или Replit. В облачном инструменте стартовая точка — заново собранный клон интерфейса: экран, который уже есть в продакшене, приходится пересобирать с нуля внутри чужой песочницы, потому что настоящего приложения там просто нет. В форке продакшен-репозитория стартовая точка — реальный код. Экран уже существует, и агенту достаточно попросить внести в него изменение, а не воссоздать заново. Разница не в удобстве интерфейса, а в том, из какого состояния агент вообще начинает работу.

Хендофф разработчикам после этого никуда не делся — вопреки заявлениям, что "хендофф мёртв". Просто в спецификации стало на порядок больше информации про состояния и переходы. Раньше дизайнер рисовал три статичных кадра, чтобы объяснить hover-эффект. Теперь можно показать рабочий интерактивный прототип с реальным поведением фокуса при открытии модалки. Хейни приводит конкретный пример: дизайнер в Shopify, начавший работать в Cursor, впервые заметил и смог наглядно показать разработчикам, что фокус при открытии новых модалок в проде уезжает не туда. Раньше это была невидимая для инструментов проблема, которую можно было только описать словами.

Поддержание форка — отдельная инфраструктурная задача: нужно окружение (environment variables, локальная база данных), нужен линтинг, который для прототипа бессмысленен, но обязателен для долгосрочной поддержки кодовой базы. Сборка иногда просто падает по причинам, не имеющим отношения к дизайну. Получается забавно: компании десятилетиями поддерживали две копии дизайн-системы — одну в Figma, одну в коде. Теперь они поддерживают ещё и две копии самого приложения: настоящую и дизайнерскую песочницу, которая имеет свойство отставать от актуальной версии, если её никто явно не обновляет.

При этом на вопрос, стало ли это действительно быстрее, ни один из собеседников Хейни не смог дать уверенного "да". Сам он приводит пример прототипа, на детальную проработку которого ушли недели, — а в масштабе двух месяцев проекта выяснилось, что решалась не та задача. Ускорение производства прототипа не гарантирует ускорения самого продукта, если тратить его на то, что потом придётся выбросить. Хейни прямо говорит, что использует Opus и Claude ежедневно и всё равно не уверен, что стал быстрее: в сложном приложении вроде его собственного продукта приходится ревьюить весь сгенерированный код построчно, а это время, которое раньше просто не тратилось.

За этим паттерном стоит и более общий технический сдвиг: почему связка Claude Code / Cursor и модели вроде Claude Opus работают заметно лучше именно на стеке Tailwind + React + типовые компонентные библиотеки. Причина не эстетическая — это сетевой эффект обучающих данных. Модели натренированы на огромном количестве кода именно на этом стеке, поэтому именно на нём дают предсказуемый результат. Это делает стек ещё популярнее, а рост популярности даёт моделям ещё больше обучающих данных именно по нему. Хейни называет это риском "заморозки" технологического стека: индустрия может на годы застрять на нынешнем наборе примитивов (Tailwind, Radix и подобные) просто потому, что модели лучше всего умеют работать именно с ними — а не потому что это технически оптимальный выбор.

Отчёт AI in Design Report 2026 построен на опросе более 900 дизайнеров в 60+ странах и кейсах команд Anthropic, Framer, Linear, Notion, Shopify, Sierra и Stripe. Он добавляет к техническому слою ещё один — организационный. Успех внедрения определяется не набором инструментов, а тем, что происходит вокруг них.

Цифры здесь говорят сами за себя. За год доля обучения через коллег выросла с 24% до 70%, а доверие к рекомендациям сверху упало с 32% до 16%. Команды буквально учат AI друг друга быстрее, чем успевает сформироваться формальная экспертиза — потому что вчерашний эксперт по инструменту сегодня уже отстал от новой версии модели. При этом ожидания от AI выросли резче, чем сами процессы под них подстроились: только 28% руководителей внесли формальные изменения в рабочий процесс, и лишь 13% обновили под новую реальность перформанс-ревью. Не всем командам это далось безболезненно — доля тех, кто описывает совместную работу как более хаотичную, выросла с 5% до 20% за год, а 34% прямо говорят о размытых зонах ответственности.

Показателен разброс конкретных практик. Stripe даёт ежеквартальное время на эксперименты с AI вне обычных задач и подчёркнуто празднует сам факт эксперимента на встречах с фаундерами — установка "прогресс важнее совершенства". DoorDash поставил общекорпоративную цель по числу PR, сгенерированных с помощью AI, и за один двухдневный хакатон получил 200 pull request'ов с последующим разбором находок в общих каналах. Ramp с первого дня даёт всем сотрудникам доступ к AI-инструментам для кодинга по умолчанию. Samsara выделяет каждому дизайнеру по $50 в месяц на AI-инструменты. Разница между этими компаниями и теми, где просто закупили лицензии и ждут результата, — не в бюджете. А в том, что первые сознательно строят культуру эксперимента, а не полагаются на то, что она возникнет сама.

Заметный сдвиг произошёл и в найме. 72% руководителей, не выбравших "продуктовый дизайнер" как обязательную роль в команде, выбрали вместо неё "дизайн-инженера". 44% — отдельного "AI design specialist". Это не сокращение дизайна как функции, а перестройка её внутренней структуры: роль не исчезает, но перестаёт быть монолитной.

Ровно об этом же, но с другой стороны, пишет в своей статье на Хабре Алексей Кирдяев. По его наблюдению, AI мало что меняет в ролях команды сам по себе — он просто обнажает, было ли в ней доверие изначально. Пример из статьи предельно конкретный: продакт-менеджер за пару часов в Claude Code собирает рабочий прототип дашборда без участия дизайнера и разработчика. После юридического ревью он смог доработать прототип сам, без дополнительных итераций с дизайнером. Дизайнер и разработчик в этой истории не становятся не нужны — они просто перестают быть привратниками первой итерации. Кирдяев называет психологический паттерн, который включается там, где доверия не было изначально: "музыкальные стулья". Люди начинают защищать позицию вместо того, чтобы двигать продукт вперёд, потому что боятся остаться без роли. В командах с достаточным доверием та же самая техническая возможность работает ровно наоборот — она просто убирает узкое место и ускоряет всех сразу.

Самый конкретный и измеримый пример успешного внедрения в этой подборке принадлежит обычной розничной компании, а не стартапу, экспериментирующему с новым процессом. Дизайн-команда X5Tech решала узкую техническую проблему — непредсказуемость результата генерации, — а не абстрактный вопрос "как использовать нейросети". Решение здесь интересно именно техническими деталями, а не общим направлением.

Голый текстовый промпт в генеративной модели — это лотерея. Одна и та же формулировка на разных прогонах даёт разный композиционный, цветовой и стилистический результат, а значит генерация не годится для продакшена с требованиями к консистентности бренда. X5Tech решили проблему не более длинным и подробным промптом — это снижает случайность, но не устраняет её. Решили набором технических ограничителей, каждый из которых контролирует свой аспект результата.

ControlNet фиксирует структуру композиции: он извлекает из референсного изображения карту глубины, контуры или позу и заставляет генерацию следовать этой геометрии, а не придумывать её заново. LoRA — это дообучение базовой модели на небольшом наборе примеров конкретного стиля или персонажа, например набора металлических иконок в фирменном стиле бренда. После такого дообучения модель воспроизводит стиль стабильно, а не приближённо. Style transfer переносит эстетику референса — палитру, текстуру, уровень детализации — на новый сюжет, отдельно от вопроса структуры и стиля персонажей. Команда также использует мультимодальные модели вроде ChatGPT Image и Gemini "Nano Banana" в режиме итеративного диалога: не одна генерация с нуля, а последовательные правки поверх предыдущего результата с сохранением консистентности между итерациями. Это ближе к тому, как правки вносит человек, чем к классическому "промпт → картинка".

Вместе эти инструменты превращают генерацию из лотереи в производство предсказуемых вариаций. Роль дизайнера при этом смещается от подбора промптов к позиции арт-директора, который итеративно правит и утверждает результат, а не пишет всё с чистого листа. Цифры по итогу: 40-45% визуального контента для брендов "Пятёрочка" и "Чижик" теперь создаётся с участием AI, часть команд полностью отказалась от стоковых фото, а скорость дизайна выросла почти вдвое. Легко упустить важную деталь: этот результат стал возможен именно потому, что задача была узкой и технической — зафиксировать стиль, — а не абстрактной вроде "внедрить AI в дизайн".