Разработка интерфейсов мобильных приложений — одна из самых дорогих стадий в проектах. Каждый экран проходит через дизайнеров, верстальщиков и ревьюеров, из-за чего растёт стоимость и замедляется релиз продукта. Бигтех уже снижает эти издержки с помощью ИИ — например, Яндекс ускорил аналитику на 30% с помощью агента. 

Я — Владимир Макеев, CEO Surf, автор ТГ-канала «Макеев всё оцифровал и доволен». Мы вместе с техлидом Flutter Марком Абраменко проверили, способен ли ИИ ускорить работу фронтендеров, и протестировали генерацию UI-компонентов в Claude 4 по методу one-shot UI — авторскому подходу Марка. В статье рассказываем, что получилось, какие ограничения есть и стоит ли уже внедрять ИИ в работу.

Методика: что и как я тестировал

Начал эксперимент с тремя рабочими гипотезами:

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

2. В сложных интерфейсах качество будет ниже, но даже там время на реализацию сокращается.

3. Контекст решает. Если дать модели правила, линтеры и подключить MCP, то код получится ближе к продакшену, а не к хаотичному черновику.

Какие инструменты использовал:

• Claude 4 для генерации кода.

• Figma MCP для передачи стилей, отступов и размеров.

Отдельно отмечу метод one-shot UI, который разработал Head of Flutter Марк Абраменко. Фишка в том, что нужно сразу загрузить в модель максимум ограничений. Идея простая: вместо десятка итераций с исправлениями модель должна выдать максимально чистый результат с первого раза.

Эксперимент: задачи для ИИ с разным уровнем сложности

Тест 1. Я начал с простого запроса — попросил Claude сверстать виджет с бонусами для аптечной сети. Закинул минимальный промпт и UI-компонент из Figma. Модель запуталась: стала спрашивать структуру проекта и компоненты, но результата не выдала.

Результат с оригинальным промптом на скрине ниже:

Как видите, здесь Claude не понял, что от него хотят, код низкого качества. ИИ так и не выдал то, что я хотел.

Тест 2. Дальше я расширил задачу. Загрузил карточку товара из уже существующего дизайна в Figma и запросил сделать идентичный вариант. В этот раз прописал детали: добавил требования и правила, как на скрине ниже.

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

Простые элементы — кнопки, текстовые блоки — Claude делает без ошибок. Я не исправил ни одной строки вручную. 

Тест №3. Теперь я усложнил задачу и попросил создать ленту рекомендуемых товаров на основе карточки товара. Добавил в промпт нюансы: отступы, зачёркнутые цены, изображение товара. Результат вышел так себе: у Claude не совпали детали карточки, зачёркивание он сделал иначе, а отступы не консистентными. 

Но даже с этим результатом работа заняла всего 10 минут вместо полноценной ручной вёрстки. 

Результаты эксперимента: насколько ИИ ускоряет разработку

Подведём итог с примерным подсчётом времени, насколько ИИ ускоряет разработчика:

• Простые компоненты (кнопки, текстовые блоки) ИИ генерирует чисто и без правок. Экономия времени — до 80%.

• Средняя сложность (карточки, профили) даёт мелкие ошибки в стилях и отступах, но исправления занимают ≤10 минут. Экономия — 40–60%.

• Сложные модули (корзины, многостраничные экраны) требуют правил, MCP и тестов. Экономия снижается до 25–30%, но ошибки быстро чинятся.

Теперь поделюсь, как именно достичь этих результатов. Как вы поняли, не абсолютно любой промпт подойдёт — нужна отдельная стратегия для работы с ИИ. Мы подробно расскажем и покажем рабочие кейсы на первой в России конференции про реальное ускорение разработки с ИИ AI Boost — вместе с экспертами из Яндекса, Сбера, T-Tech и других бигтехов.

Какие есть ограничения и как применить one-shot UI

Каждый пользователь ИИ должен осознать: нейросеть не понимает, что она делает, она просто оперирует вероятностями и паттернами.

Если вы не дадите нейросети контекст, то увидите случайный набор действий на боковой панели агента: он может лезть не туда, открывать десятки файлов, искать Figma Component Data, совершать необъяснимые действия, и в итоге выдаст что-то совсем не похожее на оригинал. 

Но даже если агент справится, это не будет продакшен-левел. Вы уже видели это на примерах выше:

• Стили из макета. По скриншоту или описанию модель может только гадать, какие стили должны быть у компонента. У неё нет доступа к ресурсам проекта: ни иконок, ни шрифтов, ни вашей темы оформления. Нет привязки к реальным файлам. AI выдаёт случайный результат, не соответствующий макету.

• Статичные vs динамичные данные. Модели их путают. ИИ может захардкодить всё подряд, без зависимостей, или наоборот — ничего не привязать. В любом случае нужно потом привносить логику вручную.

• Архитектура и нейминг. Названия виджетов, файлов, расположение компонентов в проекте, публичный API — всё это у каждого проекта своё. Модель об этом не знает. В 99% случаев ИИ подставит случайные варианты.

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

5 шагов для идеального интерфейса 

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

Шаг 1. Загружаем правила в AI-IDE

Контекст работы модели — это набор правил: стиль кода, структура проекта, имена файлов, использование готовых компонентов. Удобнее всего формировать их в одном markdown-файле и подгружать в AI-IDE вроде Cursor. Пример привожу ниже.

## Examples

### ✅ Correct implementation:

```dart
Text.rich(
  TextSpan(
    ...
  )
)
```

### ❌ Incorrect implementation:

```dart
RichText(
  text: TextSpan(
    ...
  )
)
```

# Полупрозрачность

Задавай полупрозрачность корректно. Метод `withOpacity` был объявлен deprecated, должен использоваться `withValues`.

## Examples

### ✅ Correct implementation:

```dart
color: colorsTheme.textInverse.withValues(alpha: 0.5),
```

### ❌ Incorrect implementation:

Правила можно добавлять двумя способами:

• Сразу загрузить полный свод требований команды.

• Пополнять постепенно, фиксируя ошибки модели и превращая их в новые пункты. Второй вариант эффективнее: агент учится на ходу, а цикл исправления занимает 1–2 минуты.

Важно объяснять не только что делать, но и почему — это работает как обучение стажёра. Нужно вложиться в него так, чтобы он всё запомнил и не повторял ошибок. Так и с агентами. 

‼️ Правила для разных моделей могут отличаться. Если вы натаскали под себя Claude 4, а потом попробовали тот же набор правил скормить Google Gemini — готовьтесь к сюрпризам. Gemini может подбросить свои ошибки. Многое зависит от того, как модель обучена на вашем языке, и от её внутренних механизмов. Поэтому универсальных правил нет.

Шаг 2. Используем строгие линтеры для проверки стиля

Даже при наличии правил код ИИ часто остаётся «средним». Чтобы довести его до стандарта команды, подключаем линтер:

• Автоматическую проверку стиля.

• Исправление мелких ошибок.

• Единообразие в кодовой базе.

Алгоритм работы:

1. Сгенерировать код с ИИ.

2. Пропустить через линтер.

3. Вернуть ошибки агенту и попросить исправить.

4. Повторять до полного соответствия.

В итоге получаем код, готовый к интеграции.

Шаг 3. Настраиваем master rule

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

Вот что получается:

• ИИ не тратит время на выбор стратегии.

• Код становится ближе к реальному решению.

• В процессе агент может автоматически запускать анализаторы и исправлять баги.

Пример:

---
description: 
globs: 
alwaysApply: false
---

Этот файл описывает правила для реализации компонента по изображению.

---

# Порядок исполнения задачи

❗ ОБЯЗАТЕЛЬНО: Действуй в этом порядке. Сообщай, если по какой-то причине ты отклонился от него. 

1. Изучи блок "CONTEXT" в этом файле, добавь всю необходимую информацию в свой контекст. 
2. Изучи блок "RULES" в этом файле, чтобы понять, как правильно реализовать компонент. 
3. Обратись к MCP Figma, сначала изучи доступные тебе переменные и соотнеси это со значениями из темы приложения, которую ты ранее изучил в пункте 1. 
4. Изучи код компонента в Figma, соотнеси это с переданными параметрами в класс, а также с доступными иконками/изображениями.
5. Изучи изображение компонента. 
6. Изучи зависимости компонента, если они есть. 
7. Реализуй UI-компонент. 
8. Проведи код-ревью своей реализации. 
    1. Для начала вызови команду `make autofix SCOPE=<путь/к/файлу>`, чтобы исправить автоматические проблемы.
    2. Вызывай команду `make analyze SCOPE=<путь/к/файлу>` для анализа кода
    3. Если команда analyze показала ошибки, сначала используй `make autofix SCOPE=<путь/к/файлу>`, чтобы исправить, а не пытайся исправить вручную. Если после вызова autofix есть ошибки, попробуй уже исправить сам. 
    4. Проверь себя по разделу "Код-стайл Dart", что ты соблюдаешь все правила оттуда.
    5. Проверь себя по разделу "Правила реализации Flutter-виджетов"

# CONTEXT 

## Артефакты

Для начала реализации компонента должно быть доступно: 
1. Ссылка на компонент в Figma 
2. Путь до класса UI компонента

❗ Если пользователь забыл передать их, напомни ему об этом перед стартом генерации.

## Ресурсы

1. [Иконки](../../lib/assets/assets.gen.dart)
2. [Текстовые стили](../../lib/uikit/theme/app_text_styles.dart)
3. [Цветовая тема](../../lib/uikit/theme/app_colors_theme.dart)
4. [Базовая тема](../../lib/uikit/theme/app_base_theme.dart)

## Rules

Внимательно изучи правило: [flutter-widgets](common_flutter/flutter-widgets.mdc)

## Makefile

Изучи Makefile, чтобы корректно вызывать команды: [Makefile](../../Makefile)

# RULES 

## Код-стайл Dart

Используй все новые фичи Dart: pattern-matching, switch-case, если это необходимо.

## Правила реализации Flutter-виджетов

Следуй правилам `flutter-widgets.mdc`

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

• Где этот виджет располагается (в каком экране, модуле)?

• Как он называется?

• Какие данные в него приходят?

• Что он должен уметь?

Например, скелет компонента может выглядеть так:

Шаг 4. Подключаем MCP для Figma, чтобы получить точные стили и размеры

Мы получили код, который нас устраивает, структура логичная, багов минимум. Однако сам UI-компонент всё ещё не очень похож на оригинал из дизайна: страдают отступы, шрифты и цвета. Чтобы этого избежать, используют Model Context Protocol (MCP) — стандарт, позволяющий интегрировать модель с инструментами вроде Figma.

Почему так? Не каждый ИИ-ассистент умеет считывать стили по картинке. Нейросеть может угадать расположение иконок и текста, а точные шрифты, отступы и цвета — не может. У неё недостаточно «зрения», чтобы сопоставить элементы и перенести их в код.

Через MCP модель получает реальные параметры: размеры кнопок, отступы, иконки, шрифты и цвета. Это превращает результат в точную копию исходного дизайна.

Вот так, например, Claude повторил слайдеры:

MCP, подключённые в Claude, будут работать и в Windsurf, Cursor и других совместимых средах. Подключение в Cursor проходит так: нужно открыть Tools → Integrations, нажать «Add new MCP» и вставить JSON-описание интеграции.

Чтобы находить MCP, я использую сервис Smithery — это агрегатор MCP-пакетов. Там есть подборки, поиск по ключевым словам и десятки интеграций для Figma. Но стоит учитывать, что не все они полезны — их нужно тестить.

Официальная Figma MCP: рабочая интеграция для разработчиков

Особенно хорошо работает официальная MCP для Figma:

• Снимает ограничения API, позволяя выгружать стили и HTML-вёрстку.

• Снижает объём ручных правок.

• Обеспечивает идентичность макета и итогового кода.

‼️ Стандартное API Figma не позволяет вытянуть стили без дорогого тарифного плана. MCP решает эту проблему: мы можем получить готовые стили и HTML-вёрстку.

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

Что это меняет:

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

UPD. Обновления в Figma

Недавно Figma добавила встроенный ИИ для прототипирования — теперь можно генерировать экраны прямо в редакторе. Тоже слегка потестил: попросил собрать главный экран приложения для селлеров маркетплейсов на основе UI-компонента — с разделением по выданным средствам и сумме к погашению. Получилось неплохо:

Здесь можно не прописывать код, но всё равно необходимо добавить ограничения и правила, и тогда получится нужный результат. По моему мнению, для точных стилей MCP по-прежнему надёжнее. 

Шаг 5. Применяем golden-тесты для финальной вёрстки

Даже с MCP и правилами остаётся проблема Pixel Perfect. Чтобы избавиться от мелких расхождений (паддинги, шрифты, пиксели), можно использовать golden-тесты.

Во Flutter это реализовано особенно просто: тест генерирует PNG компонента и сравнивает с эталоном. Например, агент видит: «Тут блок сдвинут на 2 пикселя, а здесь другой цвет текста» — и сам исправляет код, пока различия не станут минимальными. Это похоже на TDD (test-driven development), только вместо тестов логики мы пишем тесты внешнего вида.

Чтобы отдать агенту задачу сделать pixel-perfect UI, пишем дополнительный промпт:

Для ИИ это понятная задача. Причём, как я заметил, с этим он справляется лучше, чем с генерацией с нуля. 

Ограничения подхода:

• Данные. В Figma, в коде и в тест-кейсах должны быть проставлены одни и те же данные и названия.

• Разрешение. Нужно следить за тем, чтобы разрешение сгенерированных изображений и картинок в Figma было идентичным.

• Скорость. Сравнение картинок и исправление кода может занимать очень много времени, особенно если тест-кейсов 10 и больше.

Поэтому golden-тесты применимы для базовых атомов и ключевых экранов, а не для огромных веб-систем.

Выводы: ИИ ускоряет процессы до 80% 

Если подытожить, картина такая:

• ИИ ускоряет вёрстку интерфейсов. Нейросеть берёт на себя до 80% рутины, оставляя человеку 20% творчества и проверок. Это сокращает время на создание интерфейсов: агент выдаёт скелет кода, а специалист доводит его до идеала.

• Простые задачи уже готовы к продакшену. На уровне атомов и молекул ИИ выдаёт достаточно чистый код, который можно сразу запускать в работу.

• Сложные экраны требуют доработки. На уровне сложных интерфейсов автопилот пока невозможен. Однако модель снижает нагрузку на команду и ускоряет релизы.

• Подготовка процесса критична. Без правил, контекста и MCP модель генерирует хаотичный код. Нужно грамотно применить метод one-shot UI, описать нюансы, и тогда результат становится стабильным: меньше багов, выше качество стиля, у команды больше времени на стратегические задачи.

• Pixel Perfect возможен, но дорог по времени. Тесты позволяют добиться идеального совпадения с макетом, однако процесс пока затратный. Метод рационально применять для базовых атомов и ключевых экранов.

Мы в Surf уже давно исследуем и применяем ИИ: он сокращает время разработки и ускоряет запуск новых продуктов. Опытом и деталями поделимся 3 октября на AI Boost — первой в России конференции по ускорению разработки с ИИ. Собрали на одной сцене экспертов из бигтеха — Яндекса, T-Tech, Альфа-Банка, Ozon и других компаний. Вместе с вами обсудим реальную стоимость внедрения, потенциал ИИ в сложных задачах и защиту данных в высокочувствительных проектах.