Figma Make получил двустороннюю интеграцию с GitHub: теперь сервис умеет не только собирать прототипы, но и работать с существующим репозиторием, вносить визуальные правки в интерфейс и отправлять их в командную разработку через pull request. Для русскоязычной IT-аудитории это важный сдвиг: Figma Make перестает быть игрушкой для мокапов и начинает претендовать на роль еще одного инструмента в production-цепочке, рядом с IDE, Git и CI.
Как пишет VentureBeat, обновление позволяет импортировать уже существующий Git-репозиторий прямо в десктопное приложение Figma. Дальше сценарий выглядит знакомо даже для тех, кто не живет в терминале: дизайнер, продакт или другой участник команды открывает интерфейс на канвасе, выделяет нужные элементы, добавляет текстовые инструкции, а встроенный ИИ меняет лежащий под ними код. После этого изменения не улетают сразу в прод, а складываются в локальные коммиты, оформляются в отдельную ветку и отправляются в GitHub в виде обычного pull request.
Ключевой момент здесь не в самом AI-редакторе, а в том, что Figma не пытается обойти инженерные правила ради красивой демо-сцены. Visual editing встроен в стандартный workflow контроля версий: код проходит те же проверки, что и любой другой коммит команды, включая code review, security checks и CI-пайплайны. Для корпоративных команд это, пожалуй, единственный способ вообще всерьез разговаривать о подобных инструментах. Никому не нужен «волшебный холст», который пишет фронтенд в обход процессов, а потом оставляет инженерам разбирать последствия.
С коммерческой стороны схема тоже достаточно прозрачная. Figma Make остается проприетарным продуктом внутри платных тарифов Figma для пользователей с Full seat: в материале упоминается диапазон от 16 долларов в месяц на Professional до 90 долларов на Enterprise. При этом Figma, по данным VentureBeat, не навязывает новых лицензионных ограничений на код, который генерируется через этот сценарий, и умеет работать как с open-source, так и с закрытыми репозиториями. Для компаний это не мелочь: вопрос владения кодом и лицензирования здесь обычно всплывает раньше, чем восторг от первого удачного промпта.
Новизна обновления лучше видна на фоне того, чем Figma Make был раньше. Когда продукт запустили в мае 2025 года, он уже закрывал понятную боль между статичным дизайном и интерактивным прототипом, но жил в изоляции от реальной разработки. Тогда можно было выгрузить AI-сгенерированный проект в новый GitHub-репозиторий, но нельзя было подтянуть существующий код, синхронизироваться с апстримом и работать в уже живой кодовой базе. Именно это и меняется сейчас: вместо параллельной песочницы появляется связка с тем, что команда действительно поддерживает, релизит и чинит.
Технически Figma делает ставку на то, что ИИ будет писать не абстрактный «красивый React», а код с учетом окружения проекта. В материале говорится, что модель читает окружающую архитектуру, применяет изменения к конкретным UI-элементам и старается держаться рамок существующей дизайн-системы: цветовых токенов, типографики, вариантов компонентов, auto-layout-структур. Для продуктовых команд это звучит куда интереснее, чем очередное обещание «сделаем приложение по описанию». Когда дизайн-система уже есть, самая дорогая часть работы часто не в том, чтобы придумать кнопку, а в том, чтобы провести ее через слои согласованности, не сломав интерфейс и не насобирав визуальный зоопарк.
Куда Figma идет в гонке AI-инструментов
На этом фоне Figma конкурирует уже не только с классическими дизайн-платформами. VentureBeat прямо ставит ее рядом с Lovable и Claude Design, но у этих продуктов разная логика. Figma Make играет в design-first: сильная сторона в привязке к существующим компонентам, брендовым правилам и командным процессам. Lovable, наоборот, выглядит как code-first инструмент для тех, кто хочет быстро собрать самостоятельное full-stack-приложение, часто с готовой связкой с базой данных и без тяжелой зависимости от векторного дизайн-слоя. Claude Design расположен еще ближе к быстрому AI-прототипированию: сгенерировать экран, проверить идею, передать дальше в coding agent — и двигаться дальше.
Из этого следует довольно трезвый вывод. Figma Make не превращает дизайнера в полноценного software engineer и не отменяет фронтенд-команду. Он скорее снимает часть рутинной прослойки между макетом и несложными UI-изменениями в уже существующем продукте. Если в компании зрелая дизайн-система, есть права доступа к репозиториям, а процессы ревью и тестирования не нарисованы для аудита, а реально работают, инструмент может ускорить итерации. Если же команда делает проект с нуля, еще не договорилась о компонентах и параллельно строит backend, то code-first платформы могут дать больше пользы и меньше церемоний.
Для разработчиков здесь новость двоякая. С одной стороны, часть задач по верстке, типографике, отступам и визуальным правкам действительно можно будет сбросить с инженерной очереди на дизайнеров и продактов. С другой, качество такого ускорения целиком зависит от того, насколько аккуратно у команды собрана архитектура фронтенда. Если UI-слой консистентный, токены названы внятно, компоненты не дублируют друг друга в шести папках, а pull request не превращается в археологическую экспедицию, то visual AI-редактор будет помогать. Если нет, он просто быстрее упрется в тот же хаос, только с более красивым интерфейсом.
У бизнеса свой интерес. Figma давно продавала удобство совместной работы вокруг дизайна, но рынок AI-инструментов заставляет такие платформы доказывать, что они полезны не только до передачи макета в разработку, но и после. На фоне генераторов кода и AI-агентов вопрос теперь звучит жестче: останется ли дизайн-среда обязательным узлом в процессе создания продукта или ее аккуратно объедут промптами, IDE и GitHub? Двусторонняя интеграция с репозиториями выглядит как попытка Figma занять именно этот узел и показать, что между «нарисовать» и «зарелизить» еще есть место для отдельного продукта.
Главный вопрос теперь не в том, смогут ли дизайнеры править код с холста, а в том, где компании проведут границу ответственности. Если Figma Make останется инструментом для быстрых и контролируемых UI-изменений внутри Git-процесса, у него хорошие шансы закрепиться в зрелых продуктовых командах. Если же рынок снова начнет продавать это как замену инженерии целиком, индустрия очень быстро вспомнит старое правило: красивый интерфейс еще не делает плохой workflow хорошим.