Figma AI Agent: нативный агент прямо в канвасе — что умеет и зачем дизайнеру

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

Звучит как фича из демо. На практике — это смена режима работы. Раньше Figma была холстом: ты двигаешь, она рисует. Теперь она ещё и исполнитель: ты формулируешь, она делает. И именно здесь начинаются интересные вопросы — не «вау, как круто», а «кому это реально экономит часы, а кому добавляет работы по подчистке».

## Почему это не «ещё один AI-плагин»

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

Нативный агент убирает этот шов. Разница в трёх вещах:

• Контекст файла. Агент видит твои компоненты, переменные, авто-лэйауты, стили. Он не генерирует «дизайн вообще», он работает в твоей системе.
• Прямое действие. Не «вот картинка, перенеси», а «я переименовал 84 слоя и собрал инстансы кнопок». Изменения происходят в твоём файле, отменяются через Cmd+Z.
• Многошаговость. Один запрос может включать чтение, анализ, генерацию и правку. Это уже не «команда → результат», а маленький воркфлоу.

Для дизайнера это значит, что часть рутины, которую раньше делал плагин-комбайн в три клика, теперь делается одной фразой. А часть творческой работы — наоборот, требует более чёткого ТЗ самому себе, потому что агент исполняет буквально.

## Что агент реально умеет сегодня

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

### Работа со слоями и структурой

• Переименовать слои по смыслу, а не «Frame 2847»
• Сгруппировать элементы в авто-лэйауты с разумными параметрами
• Найти все отвязанные инстансы и предложить починку
• Заменить случайные цвета на токены из библиотеки

Это та работа, на которую уходит полдня перед хэндофом и которую все ненавидят. Агент справляется с ней быстрее человека и почти без ошибок, если структура файла не катастрофа.

### Генерация вариантов

• Сделать 4 варианта карточки с разной плотностью
• Переписать тексты в кнопках на другой tone of voice
• Адаптировать макет под мобайл, сохранив компоненты
• Собрать пустые состояния под существующий список

Здесь важная оговорка: агент работает с твоими компонентами, но эстетику он не угадывает. Если хочется «как в Linear», нужно либо иметь референс прямо в файле, либо вручную доводить.

### Сборка прототипов

• Связать экраны по логике флоу
• Расставить триггеры и анимации по описанию
• Починить «битые» связи после рефактора

Прототайпинг — одна из самых нудных задач в Figma. Тут агент даёт ощутимый выигрыш, особенно на больших файлах с десятками экранов.

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

Чтобы не разочароваться на третий день, лучше сразу знать границы.

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

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

Тонкая визуальная отделка. Микро-интервалы, ритм, акценты, типографические нюансы — агент делает «приемлемо», а не «красиво». На презентации это видно сразу.

Файлы без структуры. Если у тебя 600 фреймов с именами по умолчанию и стилями вразнобой — агент в этом захлебнётся ровно как и новый дизайнер в команде. Garbage in, garbage out никто не отменял.

### Чеклист: стоит ли пускать агента в этот файл

• Компоненты вынесены в библиотеку, а не дублируются
• Используются переменные/токены, а не хардкод цветов
• Слои хотя бы примерно осмысленно названы на верхнем уровне
• Есть один источник правды для основных паттернов
• Файл не весит как небольшой город

Если по чеклисту больше двух «нет» — сначала наведи порядок, потом подключай агента. Иначе он усилит хаос, а не уберёт его.

## Как встроить агента в свой рабочий день

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

### Три режима использования

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

• Уборщик. Поручаешь рутину: переименование, токены, авто-лэйауты, починка инстансов. Делается фоном, проверяется глазами.
• Стажёр. Поручаешь черновую генерацию: варианты, пустые состояния, адаптация под другой брейкпоинт. Берёшь 1-2 идеи, остальное выкидываешь.
• QA. Поручаешь проверку: найти отклонения от системы, несогласованные отступы, тексты не по гайду. Получаешь список, чинишь сам.

Самая частая ошибка — пытаться использовать агента как «арт-директора». Просьба «придумай красиво» работает плохо. Просьба «приведи это к нашей системе» — хорошо.

## Как формулировать запрос

Агент исполняет буквально, и это меняет интонацию задачи. То, что в чате с коллегой звучит нормально, в запросе к агенту даёт мусор.

### Что точно работает

• Указывай объект: «во фрейме Checkout / Step 2», а не «вот тут»
• Указывай ограничения: «используя только токены из Core/Color»
• Указывай критерий готовности: «пока все слои верхнего уровня не получат осмысленные имена»
• Дробление на шаги: сначала «найди все отвязанные инстансы», потом «предложи замену из библиотеки»

### Что почти всегда даёт боль

• «Сделай красиво» — критерий не определён, результат случайный
• «Перестрой всё под новую сетку» — слишком крупный шаг, нечего проверять
• «Догадайся» — агент не догадывается, он угадывает, и неудачно
• «И ещё заодно...» — каждый «заодно» удваивает риск, что что-то сломается незаметно

## Диагностика: агент что-то сделал не то

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

### Алгоритм разбора

1. Не откатывать сразу. Сначала посмотреть, что конкретно агент изменил.
2. Сравнить с формулировкой запроса. В 80% случаев проблема не в агенте, а в том, что ТЗ допускало такую трактовку.
3. Проверить, не поломалась ли система: инстансы, переменные, связи в прототипе.
4. Если поломалась — откат, переформулировка, повтор. Если просто «не то, что хотелось» — допилить руками, это быстрее, чем спорить.

Отдельно стоит держать в голове: агент иногда «галлюцинирует» структуру. Может придумать токен, которого нет, или сослаться на компонент, который удалили полгода назад. Это лечится одним правилом — всегда смотреть на список изменений до того, как закрыть файл.

## Анти-паттерны, которые встречаются на ревью

• «Агентский слой». Файл, где половина сделана руками, половина агентом, и видно стык: разные интервалы, разная плотность, разный голос текстов.
• Слепое доверие токенам. Агент назначил переменную, но не ту по смыслу: color/text/primary вместо color/text/inverse. Визуально совпадает, семантически — нет.
• Сломанный прототип после «починки». Агент перепривязал связи, но потерял условные переходы и переменные состояния.
• Имена на смеси языков. Половина слоёв на английском, половина — переведена обратно на русский. Хэндоф потом мучительный.
• Дубли компонентов. Агент собрал «новый» компонент вместо того, чтобы использовать существующий, потому что не нашёл его по имени.

### Вопросы для само-ревью перед коммитом

• Все изменения, которые сделал агент, я просмотрел поимённо?
• Токены и переменные назначены по смыслу, а не по цвету?
• Прототип всё ещё проходит от первого до последнего экрана?
• Имена слоёв и компонентов согласованы с тем, как принято в команде?
• Я могу за минуту объяснить коллеге, что именно тут делал агент, а что я?

Если хоть на один вопрос «нет» — файл ещё не готов к ревью, неважно, насколько красиво он выглядит.

## Короткий итог сегмента

Агент в канвасе — это не «дизайнер за тебя», это дополнительная пара рук, которая хорошо делает скучное и средне делает творческое. Выигрыш появляется там, где у тебя уже есть система и язык, на котором ты можешь поставить задачу. Там, где системы нет, агент честно отразит этот факт обратно — кашей в файле.

## Продвинутые сценарии: где агент реально окупается

Базовое «переименуй слои» — это разминка. Настоящая польза начинается там, где задача рутинная, но требует сквозного прохода по файлу или по нескольким файлам сразу.

### Сценарий 1: миграция на новую версию дизайн-системы

Библиотека обновилась — поменялись токены, переименовались компоненты, часть свойств стала вариантами. Руками это недели монотонной работы. Агенту можно дать карту соответствий («старый токен → новый токен», «старое имя компонента → новое») и попросить пройтись по конкретным файлам.

Что важно:

• Не запускать на всём проекте сразу. Один продукт, один флоу, проверка, дальше.
• Карту соответствий держать в отдельном документе и кормить агенту как контекст, а не как часть промпта.
• После каждого прогона — diff по компонентам и токенам, а не «на глаз».

### Сценарий 2: подготовка к хэндофу

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

### Сценарий 3: ревью соответствия гайду

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

### Сценарий 4: генерация состояний и краевых случаев

Готовый экран — основа. Агента просим собрать пустое состояние, ошибку, длинный текст, отсутствие данных, медленную сеть. Получается черновик, который быстрее довести до ума, чем рисовать с нуля.

## Командный контекст: как агент меняет работу в паре

Когда в файле работает не один человек, агент становится третьим участником — и это нужно проговаривать.

### Договорённости, которые стоит зафиксировать

• В каких файлах агенту можно работать без предварительного согласования, а в каких — нет (например, мастер-библиотека — нет).
• Кто отвечает за результат: тот, кто запустил агента, а не «агент сам».
• Как помечается работа агента в истории: отдельная ветка файла, отдельный коммит, комментарий в описании.
• Что делать, если двое запустили агента по одной и той же области одновременно (спойлер: ничего хорошего, нужен порядок).

### Как объяснить команде, что именно сделал агент

На ревью полезно отделять «руками» от «агентом» не для самооправдания, а чтобы коллеги понимали, где смотреть внимательнее. Простая формулировка работает лучше длинных объяснений: «эти экраны я собрал сам, состояния и переименования слоёв — агент по моему запросу, я проверил инстансы и токены».

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

## Как проверять качество результата

Визуальная проверка обманывает: пиксели на месте, а под капотом — каша. Полезно завести себе минимальный набор проверок, который проходишь всегда, независимо от того, насколько простая была задача.

### Базовый чеклист после агента

• Слои верхнего уровня и ключевые группы — имена осмысленные и согласованные.
• Все цвета и типографика — через переменные/стили, локальных значений не осталось (или они осознанные).
• Инстансы компонентов не отвязаны без причины; переопределения только там, где они нужны.
• Прототип проходится от входа до выхода, переменные состояний живы.
• Экспортные настройки и аннотации соответствуют тому, как принято в команде.
• Имена компонентов и свойств не задвоились (нет Button и Button 2).

### Что проверять при сомнениях

Если задача была крупная и не хочется идти по всему чеклисту вручную — попроси самого агента сгенерировать отчёт об изменениях: что переименовал, какие токены назначил, какие компоненты тронул. Дальше прогон по отчёту занимает пару минут, и это честнее, чем «вроде нормально».

## Вопросы для ревью с командой

• Где в этом файле работал агент, а где — человек?
• Какие гарантии проверил автор перед тем, как звать на ревью?
• Есть ли решения, которые агент принял «за нас» по умолчанию (например, выбрал токен из двух близких)?
• Если откатить агентскую часть, сломается ли файл — и насколько быстро восстановим?

Последний вопрос особенно важен. Если файл стал зависим от агента так, что без него не разобраться — это технический долг, и он догонит на следующем спринте.

## Итог сегмента

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

## Анти-паттерны, которые сжирают всю выгоду от агента

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

### «Запустил и забыл»

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

### Агент как замена принятию решений

Когда «пусть он сам выберет» становится способом не думать. Из двух близких токенов агент возьмёт любой — и это нормально для черновика, но не для финального макета. Если регулярно перекладываешь на агента развилки уровня «какой именно вариант компонента тут уместен», через полгода в системе появится случайность, которую уже не объяснить.

### Промпт на полстраницы вместо подготовки файла

Попытка компенсировать беспорядок в файле длинной инструкцией. Агент работает на том, что видит: если слои называются Frame 432, а половина компонентов локальная, никакой промпт не спасёт. Пять минут на наведение порядка в исходнике экономят полчаса разбора результата.

### Использование агента для того, что должен делать линтер

Поиск отвязанных стилей, проверка типографики, аудит контрастов — это задачи для плагинов и линтеров, у них предсказуемый результат и понятная стоимость. Гонять агента по этим задачам можно, но это как заколачивать гвозди микроскопом: дороже, медленнее и без гарантий повторяемости.

### «Агент сделал — значит, как-то правильно»

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

## Чеклист перед тем, как звать агента

• Файл приведён в минимальный порядок: ключевые фреймы названы, компоненты из библиотеки подключены.
• Задача сформулирована одним предложением, которое ты сам понимаешь без оговорок.
• Понятно, что считается успехом: какие именно слои/токены/состояния должны быть в результате.
• Заранее ясно, как ты будешь проверять результат (чеклист, отчёт от агента, прогон прототипа).
• Есть точка отката: отдельная ветка файла или копия фрейма.
• Если файл общий — коллеги знают, что ты сейчас запускаешь агента в этой области.

## Вопросы для самостоятельного ревью

Перед тем как закрыть задачу, стоит честно ответить на несколько вопросов. Если хоть на один ответ — «не уверен», работа не закончена.

• Могу ли я в двух предложениях объяснить, что именно сделал агент и где я это проверил?
• Есть ли в файле решения, которые я не принимал сознательно — и принял ли бы их сам?
• Если завтра агент перестанет работать, смогу ли я поддерживать этот файл руками?
• Не появилось ли в системе новых сущностей (стилей, компонентов, переопределений), которых там быть не должно?
• Что из сделанного агентом я готов защищать на ревью, а что — нет?

Последний вопрос отрезвляет лучше всего. Если ты не готов отстаивать конкретное решение перед командой, значит, это не твоё решение — и его нужно пересмотреть, а не пропускать дальше.

## Короткий практический итог

Нативный агент в Figma полезен ровно настолько, насколько вокруг него выстроен процесс. Сам по себе он не делает дизайн лучше и не заменяет ни систему, ни вкус, ни ответственность за результат. Он ускоряет конкретные операции — рутину, состояния, приведение к системе, черновики — и в этом качестве отлично экономит время.

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