У нас случилась классика: бэкенд уже отдает данные, бизнес ждет экран “вчера”, а фронтендера в команде нет и ближайшие фронты заняты.

Я Александр Бунтов, тимлид в Ви.Tech - IT-дочки ВсеИнструменты.ру. В этой статье расскажу, как мы рискнули и собрали MVP-интерфейс за неделю - без выделенного фронта, но на корпоративном стеке (Vue/TypeScript) и с дизайн-системой.

Это не история “AI все сделал”. Это история про то, как правила + дизайн-система + ревью как для джуна превращают AI-ассистента в нормальный инструмент, а не генератор мусора.

Контекст: что именно болело

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

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

И вот тут мы уперлись в простое: фронтендера нет.
Риск тоже простой: нет интерфейса > нет использования > ценность бэкенда растворяется > OKR горит.

Два пути и почему выбрали “авантюрный”

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

Путь 1 — старый и понятный

“Давайте на бэке нагенерим HTML”: Go + шаблоны, серверная страница, минимум JS.
Работает. Но бэкендеры и так были в огне. Это означало сдвинуть другие критичные задачи - а нечего было сдвигать.

Путь 2 - новый и авантюрный

Собрать UI через AI-ассистента на корпоративном фронтовом стеке.
Да, это тоже ресурс - мой тимлидский. Но мне было реально интересно проверить: можем ли мы решать такой блокер иначе и сделать команду автономнее.

Я выбрал второй путь.

Мы заранее договорились, что MVP считается успешным, если:

И отдельно: код всё равно ревьюим. AI - не авторитет, а ускоритель.

Подготовка: правила важнее промптов

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

Поэтому я начал с правил. Прямо в Cursor положил Markdown-док, который ассистент видит как контекст:

• стек: Vue + TypeScript (+ Nuxt, если он реально у вас используется)

• что можно/нельзя из библиотек

• как устроена наша дизайн-система и какие компоненты надо использовать

• соглашения по коду: линт/форматирование/структура проекта

• формат работы с API: где лежат клиенты, как обрабатываем ошибки, где типы

Пример (сильно укороченный, но по смыслу как надо):

## UI-правила проекта

Стек: Vue 3 + TypeScript. UI — только через нашу дизайн-систему.

### Запрещено
- Добавлять сторонние UI-библиотеки.
- Писать inline-стили без необходимости.
- Делать запросы к API прямо из компонентов без слоя client/service.

### Обязательно
- Используй компоненты DS: Table, Input, Select, DateRange, Button.
- Все поля и ответы API типизируй.
- Фильтры должны быть синхронизированы с query-параметрами URL.
- Ошибки API показывай через стандартный toast.

Это скучная часть, но она экономит тонну времени. AI начинает работать в рамках, а не “как он сегодня решил”.

Инструменты и процесс

База: Vue - корпоративный стандарт.
AI-инструменты: Cursor + Claude (в нашем случае он стабильно генерил адекватный TypeScript и Vue-код).

Почему дизайн-система решает половину задачи:

• UI не надо “придумывать”

• компоненты уже решают accessibility/стили/часть состояний

• ассистенту проще собрать страницу из блоков, чем рисовать заново

Цикл работы был такой:

1. я формулирую задачу как для разработчика (“сделай страницу задолженностей: таблица + фильтры + сортировка + пагинация”)

2. AI генерит каркас + компоненты

3. я руками проверяю/правлю интеграцию с API, фильтры, edge-cases

4. прогоняем ревью “как джуну”

5. фиксим → мержим

Первый экран собрали за пару дней, дальше пошло быстрее.

Реализация: что делал AI, а что делали мы

Если грубо:

• AI: каркас страниц, верстка на компонентах DS, типы, бойлерплейт, базовая логика отображения

• человек: дебаг API-обмена, фильтры, пограничные кейсы, согласование поведения с пользователями, ревью

Что вошло в MVP:

• таблица задолженностей по ордерам

• фильтры по клиенту/срокам/статусу

• базовая сортировка и пагинация

• отображение ошибок/пустых состояний

Важно: “AI обучился контексту” — это не магия. Это просто то, что вы даёте ему:

• правила проекта

• примеры существующих компонентов

• требования “как у нас принято”

Грабли

Вот где реально приходилось вмешиваться:

• контекст иногда “уезжает”: ассистент забывает про ограничения и начинает тащить лишние библиотеки / другой паттерн. Ловится ревью и жесткими правилами “запрещено”.

• фильтры и URL-синхронизация: AI любит сделать “просто локальный state”, но в реальном интерфейсе пользователи хотят “скопировать ссылку” и получить тот же набор фильтров. Это пришлось прям отдельно проговаривать.

• ошибки API и пустые состояния: по умолчанию генерит “happy path”. Мы руками добавляли нормальную обработку.

• типизация: на простых DTO - ок, но на сложных ответах всё равно нужно проверять, иначе получаешь красивый TS-код, который врет.

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

Результат: что получили на выходе

• По времени: вместо ожидаемого “месяца ожидания фронта” MVP был готов за неделю.

• Релиз случился в срок (к концу квартала) - без переносов.

• На проде не было критичных инцидентов, были мелкие доработки по валидациям.

• Самое полезное: команда перестала бояться трогать фронт-задачи. После релиза я показал процесс, и ребята уже сами допиливали UI с теми же правилами и инструментами.

Мини-плейбук: “AI в помощь фронту”

• Сначала правила: стек, запреты, дизайн-система, соглашения по коду.

• Потом инструменты: IDE-ассистент + доступ к докам + память/контекст (если используете).

• Начинай с дизайн-системы. Пусть AI собирает из готовых компонентов, а не “делает красиво”.

• Формулируй задачи конкретно: компонент, API, поля, состояния, ограничения.

• Ревью как джуна: работает ≠ хорошо сделано.

• Рутину отдавай AI (бойлерплейт, типы, верстка), архитектуру держи в голове сам.

• После релиза - учи команду на реальных задачах. Это быстрее всего снимает страх.

Когда подход не подходит

• Если у вас нет дизайн-системы и всё рисуется “с нуля” - AI будет постоянно “изобретать UI”.

• Если нет минимальных соглашений по проекту (структура, линт, слой API) - вы утонете в разношерстном коде.

• Если интерфейс критичный по безопасности/комплаенсу - без строгого ревью и тестов лучше не начинать.

Выводы и что дальше

Главный вывод: AI реально усиливает команду не как “замена фронтенду”, а как ускоритель, когда у вас есть:

• готовая дизайн-система

• правила проекта

• нормальное ревью

Что дальше мы хотим сделать:

• оформить правила в шаблон для других команд

• завести небольшой набор “эталонных” страниц/паттернов для ассистента

• формализовать чеклист ревью AI-кода