Привет, Хабр! Меня зовут Екатерина Ионова и я руковожу проектами и продуктами экосистемы «Лукоморье». Когда-то программировала на Java и C#, но последние шесть лет занималась управлением — продуктами, командами, сроками, бюджетами и всем тем, что обычно находится вокруг кода, а не внутри него.

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

Поэтому прототип пришлось собирать самим. Сначала в Lovable, потом в Cursor. В этой статье расскажу, как мы собрали рабочий ИИ-прототип за выходные, какие грабли поймали, что пришлось «накостылить» и почему даже работающий прототип всё ещё нельзя путать с продуктом. 

Это кейс о vibe coding в боевых условиях: когда надо быстро проверить гипотезу, а идеальной команды, инфраструктуры и времени у тебя нет.

Задача: проверить идею UX-ассистента без разработчика

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

Всего на хакатон зарегистрировалось более 280 человек, было подано 60 продуктовых идей. После нескольких этапов отбора до финала дошли 8 команд. Мы не стали победителями, но вошли в число команд, получивших поддержку жюри и бюджет на развитие продукта.

Меня позвали в команду ребята из Департамента дизайна. У них уже была идея продукта — нейроассистент для UX-проектировщика, который автоматически оценивает макеты на соответствие методологии: эвристикам, гайдлайнам, требованиям к доступности и внутренней документации. Такой ассистент должен помогать быстрее находить проблемы в интерфейсах, формировать рекомендации и снижать нагрузку на экспертов при первичной проверке макетов.

Для реализации идеи команде нужна была экспертиза в работе с LLM. Я уже участвовала в нескольких проектах, связанных с ИИ, поэтому подключилась к этой части. Заодно мне достался привычный для РП и продуктового менеджера набор задач: оценка затрат, P&L, границы MVP, черновая архитектура и анализ того, что именно мы можем успеть собрать в рамках хакатона.

В команде были дизайнеры, UX-исследователь и методолог. Дизайнеры отвечали за концепцию, макеты и финальную презентацию, а также за коммуникацию с потенциальными бизнес-заказчиками и финальную защиту. UX-исследователь занимался оценкой рынка, исследованиями и опросами потенциальных пользователей. Методолог и UX-проектировщик собирал и тестировал систему оценки макетов — основу, на которой должен был работать ассистент.

Проблема была в одном: разработчика в команде не было.

Мы немного поколебались, сможем ли вообще сделать рабочий прототип без инженерной поддержки. Но идея была слишком интересной, а инструменты для vibe coding выглядели слишком соблазнительно, чтобы не попробовать. Так начался эксперимент: можно ли силами менеджера, дизайнеров, методолога, Cursor, Lovable и LLM собрать прототип, который не просто красиво выглядит, а действительно помогает проверить продуктовую гипотезу.

Что должен был делать прототип

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

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

Подробности методологии ребята уже описали в отдельной статье на Хабре.

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

То есть в минимальной версии прототип выглядел так:

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

Именно такой прототип мы и попытались собрать: не полноценный продукт, а рабочую проверку основной гипотезы.

Попытка №1: Lovable

Первым инструментом для прототипирования я попробовала Lovable.dev. Это сервис для vibe coding: описываешь в чате, какое приложение хочешь получить, а он генерирует интерфейс, логику, подключает нужные сущности и сразу показывает результат в браузере.

На старте всё выглядело почти идеально. Сервис был доступен без VPN, регистрация через Google заняла пару минут. В бесплатной версии можно было создать один проект, и для первого эксперимента этого хватало.

Начинается всё просто: пишешь в чат, например, «создай страницу с заголовком “Нейроассистент UX-проектировщика Uxa”, добавь поле для загрузки скриншота и кнопку отправки скриншота на анализ». Можно сразу уточнить визуальный стиль, например, попросить тёмную тему или приложить скриншот желаемого интерфейса. Lovable пытается повторить структуру, подобрать похожие элементы и иконки, хотя результат, конечно, не всегда совпадает с ожиданием.

Даже без подробного описания или референса интерфейс получается довольно симпатичным. Например, в одном из экспериментов я написала буквально «создай одностраничный лендинг и добавь его в раздел “О продукте”». Lovable сам собрал страницу с блоками, карточками и визуальным оформлением. 

Работа строится как диалог. Справа остаётся чат, где можно писать, что добавить или исправить, а слева сразу виден интерактивный прототип. Лучше всего Lovable справляется, когда задачи сформулированы небольшими шагами: добавить поле, переименовать кнопку, изменить экран, поправить текст, сделать новый раздел. Если отправить сразу длинный список требований, часть деталей может потеряться или отработать не так.

При этом стандартные задачи он умеет закрывать довольно широко. Например, на просьбу «добавь авторизацию пользователей» Lovable не просто нарисовал формы входа и регистрации, а подключил внутреннюю базу данных, хранение пользователей, паролей и пользовательской информации, сам добавил в интерфейс кнопку logout. Если попросить добавить отправку результатов на почту, он предлагает сторонние сервисы, объясняет, где получить API-ключ, запрашивает его в чате и затем сам реализует интеграцию.

Ух, как мне понравился этот опыт! Ты не пишешь код руками, не собираешь проект с нуля, не настраиваешь окружение, а просто описываешь нужное поведение и через несколько минут видишь работающий сценарий. Человека, который последние годы занимался управлением, а не разработкой, это действительно окрыляет.

У Lovable есть и удобные мелочи. Например, приложение можно опубликовать одной кнопкой: оно разворачивается на домене lovable.app, и его можно показать другим людям. Мой экспериментальный проект до сих пор доступен: https://uxa-heuristic-buddy.lovable.app/ (на первой странице он попросит авторизацию, можно зарегистрироваться с любой почтой и паролем).

У Lovable есть и интеграция с GitHub: подключаешь аккаунт, и исходный код проекта сохраняется в репозитории. И всё это доступно в бесплатной версии.

Но довольно быстро проявились ограничения.

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

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

Во-вторых, редактирование исходного кода доступно только в платной версии. Поначалу это не кажется проблемой. Но когда 3 раза попытаешься объяснить нейронке, как тебе нужно поправить конкретное место в коде, то приходит понимание, что руками сделать некоторые вещи быстрее.

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

Для проекта это стало хорошим напоминанием: если прототип полностью живёт внутри внешней платформы, сама платформа становится частью ваших рисков.

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

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

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

Попытка №2: Cursor

К моменту, когда эксперименты с Lovable закончились, до финального гейта хакатона оставалось чуть больше недели. Мы ещё хотели успеть обкатать прототип на реальных пользователях, а методолог как раз закончил дорабатывать систему оценки макетов. Нужно было добавить новую методологию в продукт, проверить её на реальных скриншотах и подготовить что-то, что можно показать не только на защите, но и потенциальным пользователям.

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

Я переключилась на Cursor. Это IDE на базе VS Code со встроенным ИИ, который работает с контекстом проекта: видит файлы, может предлагать изменения, создавать новые модули, объяснять ошибки и помогать запускать приложение локально.

Работа в Cursor требует больше вовлечённости и понимания, чем Lovable. Но, всё же, моих скилов хватило. Сначала я создала для Cursor файл с правилами проекта: описала технологический стек (React для фронтенда и Python для бэкенда), желаемую структуру, разделение фронтенда и бэкенда, требования к папкам и общую логику приложения. В промпте отдельно указала, что нужно опираться на этот файл: что-то вроде «обрати внимание на информацию в readme.mdc».

Дальше я попробовала давать ему довольно крупные задачи. Например: создать базовую структуру приложения, собрать страницу загрузки скриншота, сделать отдельный бэкенд для обработки запроса, добавить сервис для будущего обращения к LLM, подготовить место для промптов и результатов проверки. Cursor в таких случаях сначала планирует шаги, предлагает, какие файлы изменить или создать, а потом показывает правки. Их можно принять, отклонить или попросить переписать.

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

Зато Cursor оказался очень полезен там, где Lovable становился непрозрачным. Я могла спросить, какие зависимости нужно установить, как запустить фронтенд и бэкенд отдельно из командной строки, почему один сервис не видит другой, что означает ошибка в логах и как её исправить. Я добавила логирование, чтобы видеть, на каком этапе всё ломается, а потом просто копировала ошибки обратно в Cursor и спрашивала: «что не так и как это поправить?»

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

Запущенные отдельно фронт и бэк:

Скриншот, похожий на тот, что был у Lovable, но теперь это собрано в Cursor:

Добавляю LLM

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

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

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

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

Следующей попыткой было подключение локальной модели через Ollama. Я попробовала qwen3-vl:8b и gemma3:27b, запущенные на своём ноутбуке: 32 ГБ RAM, без GPU. Сначала установила Ollama, скачала модели и проверила, что они в принципе способны анализировать скриншот и выдавать приемлемый ответ прямо в интерфейсе Ollama (тут на скриншоте очень короткий промпт для быстрой проверки). 

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

Само подключение получилось, но быстро стало понятно, что для отладки такой вариант почти не подходит. Модель опрашивалась до получения ответа HTTP 200 OK. Но этого оказалось недостаточно, пришлось добавить бесконечный опрос не просто до получения 200, а до получения полного ответа. Идентифицировала вот по такой ошибке:

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

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

После этого я подключила внешний API. Через VPN посмотрела доступные модели и тарифы OpenAI, пополнила баланс на минимальные $5 и сгенерировала API-ключ. Для нашей задачи подходила GPT-4o: она умеет работать с изображениями, а стоимость токенов для короткого пилота выглядела приемлемой.

Дальше я написала в Cursor примерно такой промпт: «добавь конфигурацию для GPT-4o и используй её для всех проверок, если пользователь выбирает такую модель». Cursor добавил новый вариант конфигурации и вызовы к API. API-ключ я на этапе прототипа положила прямо в конфигурацию. Это плохая практика: в нормальном проекте ключи должны храниться в переменных окружения или секрет-хранилище, а доступ к ним должен быть ограничен. Но мне нужно было быстро запустить локальный прототип к пилоту, поэтому я сознательно выбрала быстрый путь и отдельно зафиксировала, что перед любым развитием это место надо переделывать.

Отдельно пришлось повозиться с передачей изображения. GPT-4o не принимала файл так, как я сначала пыталась его отправить, а ожидала доступную ссылку на изображение. Так я дошла до ngrok — инструмента, который позволяет временно открыть локальный файл или сервис наружу через внешний адрес. Я попросила Cursor прикрутить ngrok к проекту, чтобы модель могла скачать изображение с моего локального компьютера и обработать его.

К вечеру всё наконец заработало быстро. Вместо двух часов на один макет анализ стал занимать примерно две-три минуты. Это резко ускорило отладку: можно было менять промпт, запускать проверку, смотреть результат, править формат ответа и снова запускать сценарий. Баланса в $5 хватило и на тестирование, и на короткое пилотирование в рамках хакатона.

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

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

Пилотирование на костылях: отчёты вместо доступа в прототип

К понедельнику прототип работал у меня на локальной машине: либо через внешний API с подключенным VPN, либо через локально запущенную модель. Но до нормального пользовательского тестирования было ещё далеко. У нас не было инфраструктуры, на которой можно было бы быстро развернуть решение и дать к нему доступ пользователям. В рамках хакатона была только виртуальная машина без доступа в интернет, а значит, вариант с внешней моделью там сразу отпадал. Установить VPN на такую ВМ, конечно, тоже никто бы не дал.

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

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

Cursor прикрутил для этого стандартный сценарий Print to PDF.

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

Конечно, это не было полноценным UX-тестированием. Мы не видели, как пользователи взаимодействуют с интерфейсом, где они теряются, какие формулировки им непонятны и насколько удобно им было бы работать с таким инструментом самостоятельно. Но для текущей стадии нам было важнее проверить не интерфейс, а основную продуктовую гипотезу: может ли модель по нашей методологии выдавать полезные замечания к реальным макетам.

И эту часть мы проверить смогли. Модель генерировала осмысленные отчёты, дизайнеры узнавали в них реальные проблемы и подтверждали, что такой формат может быть полезен в работе. Где-то рекомендации были спорными, где-то требовали уточнения, но некоторые рекомендации были «прям в точку». Это уже была предметная обратная связь на уровне конкретных макетов, замечаний и пользы для UX-процесса.

Для полноценного продукта такой способ запуска, конечно, не годится, но для проверки концепции его оказалось достаточно. Мы не построили пользовательский сервис, зато быстро получили главное: доказательство, что методологию можно упаковать в работающий сценарий, а LLM использовать как инструмент первичной оценки интерфейсов.

Мои выводы: прототип — это ещё не продукт

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

Cursor, Lovable и похожие инструменты действительно сильно ускоряют путь от идеи до первого сценария. Они помогают быстро собрать интерфейс, проверить механику, подключить модель, показать результат пользователям и получить обратную связь. Для хакатона, внутреннего демостенда или проверки гипотезы это работает: вместо презентации с красивыми слайдами можно показать работающий прототип и обсудить конкретный пользовательский опыт.

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

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

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

Первый уровень — демо. Нужно быстро показать идею, собрать красивый интерфейс, проверить, что сценарий вообще понятен. Здесь Lovable и Cursor отлично помогают.

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

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

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