Как продакт без знания кода собрала сервис в Replit и Perplexity: разбираем вайбкодинг на реальных промптах

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

В этой статье расскажем:

1. Как пришла идея и зачем выносить фичу из монолита;

2. Как правильно ставить задачи AI-агентам, чтобы не израсходовать лимит токенов;

3. Какие ещё продукты удалось создать всего за один квартал с помощью вайбкодинга;

4. Заменит ли вайбкодинг классическую разработку и где его пределы.

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

Фокус инженерии vs скорость гипотез

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

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

• Планирование ресурсов. Добавлять новую разработку под гипотезу — рискованно. А выделять отдельную команду под регулярные эксперименты — долго и дорого.

• Скорость проверки. Чтобы понять, нужна ли фича рынку, не обязательно писать продуктовый код. Важно получить первый отклик как можно быстрее.

Полноценная разработка микросервисов для тестирования спроса отложила бы проверку идей на месяцы. Мы решили проверить гипотезы с помощью вайбкодинга, не нагружая IT-департамент.

Что такое вайбкодинг без маркетингового шума

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

Это не про замену инженеров и не про создание нового монолита. Это про автономию в проверке гипотез.

Ниже я разберу один из свежих кейсов — «Генератор ценников» для малого бизнеса.

Зачем выносить фичу из монолита и причём тут вайбкодинг?

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

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

Мы решили снять этот барьер и дать микробизнесу бесплатную автономную утилиту. Механика простая: загружаешь CSV или Excel, выбираешь размер ценника и скачиваешь готовый DOCX для печати на А4. Для базовых задач этого достаточно. Если же магазину нужно печатать сотни ценников регулярно, сервис предлагает автоматизировать весь учёт и перейти в экосистему Эвотора.

Мы решили вынести эту фичу в отдельный бесплатный сервис с простой механикой: [Загрузка CSV / Excel] ➔ [Настройка размеров и полей] ➔ [Экспорт в DOCX (A4)]. Остаётся только распечатать, разрезать и расставить новые ценники на полки.

Главная ловушка вайбкодинга: почему генерация из головы убивает бюджет

Самая распространённая ошибка при работе с AI-кодерами — открыть Replit Agent и написать абстрактный запрос в стиле: «Сделай мне красивый сервис для печати ценников из Excel».

Результат такой попытки предсказуем:

➡️ Агент сожжёт $50–100 кредитов на бесконечные циклы переписывания UI.

➡️ Запутается в обработке файлов и геометрии печатных форм.

➡️ Выдаст галлюцинацию, которую невозможно задеплоить в продакшен.

AI-агент — это не продуктовый дизайнер и не бизнес-аналитик. Ему нужны жёсткие рамки, точные вводные и заранее проработанный пайплайн.

Двухэтапный стек: как мы организовали рабочий процесс

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

1. Perplexity Pro ($20–200/мес)

После текстов нейросетей Perplexity Pro показал себя как наиболее продуктивный вариант. В нём продакт исследует требования законодательства к ценникам, изучает конкурентов, закладывает ограничения по размерам в миллиметрах и лимитам бесплатного тарифа. На выходе инструмент формирует бизнес-логику, правила работы сервиса и полный файл ТЗ в формате TXT. 

2. Replit Agent (~$100/мес в кредитах) 

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

Разбор цепочки промптов: от идеи до пейволла

Когда файл ТЗ готов, начинается финальный этап — сборка приложения в Replit Agent. Чтобы не перегружать нейросеть длинными полотнами текста и не тратить лишние токены на переделки, вся работа разбивается на три коротких последовательных шага.  

1️⃣ Стартовый запуск

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

Ниже — реальный фрагмент спецификации (Pasted--Replit-Agent...txt), который продакт загрузил в Replit Agent вместе со стартовым промптом:

Такая детализация даёт AI-агенту точные вводные: ему не нужно угадывать размеры ценников или придумывать формат экспорта — всё уже зафиксировано в инженерных единицах. 

2️⃣ Передача дизайн-системы и UI-кит

После генерации базовой сетки идёт работа над интерфейсом. Если оставить визуал на усмотрение нейросети, она сверстает стандартные дефолтные формы. Продакт выгружает из Figma макеты и скриншоты интерфейсов компании с готовой палитрой, кнопками и логотипами. В чат Replit Agent отправляется второй промпт с изображениями:

Агент считывает картинки, адаптирует UI-кит компании и перекрашивает элементы в нужном стиле. Шрифты из картинок агент не всегда подтягивает корректно, поэтому правила для заголовков первого и второго порядка пришлось дополнительно прописать текстом.

3️⃣ Отладка и проверка фримиум-лимитов 

Когда приложение собрано, продакт начинает работать в роли тестировщика и бизнес-заказчика. В Replit Agent отправляются точечные промпты для исправления ошибок и доработки логики:

• Проверка генерации DOCX-файла: загрузка реального прайс-листа и контроль правильности расположения карточек на листе А4.

• Отладка отображения штрихкодов: проверка, чтобы код читался и не съезжал за границы ценника при скачивании.

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

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

Какие решения выбрал AI в технической части

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

Архитектура и стек

Вместо плоской структуры в одном каталоге Replit Agent сгенерировал монорепозиторий на базе pnpm workspaces. Это позволило вынести контракт API, типы и генерацию кода в отдельные пакеты, изолировав логику бэкенда от клиентской части:

artifacts/
  price-tags/       # React 18 + Vite фронтенд
  api-server/       # Express 5 бэкенд
lib/
  api-spec/         # OpenAPI 3.1 спецификация и codegen
  api-client-react/ # Сгенерированные React Query хуки
  api-zod/          # Сгенерированные Zod-схемы валидации
  db/               # Drizzle ORM схема и подключение к PostgreSQL

На базе этой структуры Replit Agent собрал TypeScript-стек, в котором тяжёлая работа с документами вынесена на клиент, а бэкенду оставлена только сервисная логика:

• Frontend (artifacts/price-tags). React 18 + Vite + TypeScript. Интерфейс включает компоненты shadcn/ui (Radix UI + Tailwind CSS) и анимации Framer Motion. Для внешней аналитики подгружается Amplitude SDK. 

• Парсинг и генерация на клиенте. За парсинг таблицы отвечает SheetJS (XLSX/XLS/CSV), а за генерацию DOCX — библиотека docx (v9). Приложение обрабатывает файлы в браузере пользователя, без участия сервера.

• Backend (artifacts/api-server). Node.js 24 + Express 5 + TypeScript. Drizzle ORM работает с PostgreSQL под управлением Replit. esbuild собирает проект в CJS bundle.

• Контракт API (lib/api-spec). Из файла openapi.yaml через Orval codegen генерируются клиентские хуки React Query и Zod-схемы для бэкенда.

Такая связка закрывает сразу две задачи: полностью изолирует пользовательские данные на клиенте и обеспечивает сквозную строгую типизацию между фронтендом и бэкендом. В результате серверная часть получается предельно компактной, например, роут для сбора продуктовой аналитики src/routes/track.ts укладывается всего в несколько строк: 

router.post('/track', async (req, res) => {
  const { event_type, properties, session_id } = req.body;
  await db.insert(eventsTable).values({
    event_type,
    session_id: session_id ?? null,
    properties: properties ?? {},
  });
  res.json({ ok: true });
});

Поскольку обработка файлов полностью вынесена на фронтенд, простой сценарий «загрузил на сервер → обработал → скачал» здесь отсутствует. Весь цикл трансформации данных проходит внутри браузера в рамках одного пайплайна: 

Единственное, для чего задействована база PostgreSQL, — сбор продуктовой аналитики в таблицу events: event_type, session_id, JSONB-поле properties и created_at.

Парсинг заголовков

Вынос обработки на клиент решает проблему приватности, но сразу обнажает другую — непредсказуемость пользовательских данных. Excel-файлы из разных CRM или 1С редко соответствуют строгому формату: шапка может начинаться со случайной строки, а названия колонок постоянно варьируются. Чтобы сервис не падал от каждой нестандартной таблицы, AI добавил модуль для умного парсинга заголовков src/lib/smart-parser.ts.

Модуль работает в два этапа:

1. Алгоритм сканирует первые 8 строк и выбирает ту, где максимальная плотность строковых значений:

function detectHeaderRow(rows: unknown[][]): number {
  let bestScore = -1, bestRow = 0;
  for (let i = 0; i < Math.min(8, rows.length); i++) {
    const score = rows[i].filter(c => typeof c === 'string' && c.trim().length > 1).length;
    if (score > bestScore) { bestScore = score; bestRow = i; }
  }
  return bestRow;
}

2. Затем он автоматически соотносит найденные заголовки с нужными полями по словарю синонимов:

const SYNONYMS: Record<FieldKey, string[]> = {
  name:    ['наименование', 'товар', 'продукт', 'название', 'номенклатура'],
  price:   ['цена', 'стоимость', 'розница', 'price'],
  barcode: ['штрихкод', 'штрих', 'barcode', 'ean', 'код товара'],
  unit:    ['ед', 'единица', 'упак', 'unit'],
  // ...
};

В результате пользователю не нужно скачивать шаблоны или вручную привязывать колонки в интерфейсе — парсер обрабатывает сырые выгрузки как есть. 

Оценка безопасности и технический аудит

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

Даже для быстрого эксперимента код после AI нужно проверять вручную. Аудит показал, где Replit Agent справился отлично, а где оставил баги.

Где AI сработал хорошо

С базовой гигиеной валидации агент справился достойно. В компоненте UploadZone.tsx он предусмотрел двойную проверку формата:

const validTypes = [
  'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet',
  'application/vnd.ms-excel',
  'text/csv'
];
const extension = file.name.split('.').pop()?.toLowerCase();

if (!validTypes.includes(file.type) && !['csv', 'xlsx', 'xls'].includes(extension || '')) {
  setError('Пожалуйста, загрузите файл формата Excel (XLSX, XLS) или CSV.');
  return;
}

Это важное решение: браузеры часто передают пустой file.type. Проверка MIME-типа вместе с расширением защищает от ложных блокировок корректных таблиц.

Аналогично в file-parser.ts агент заложил первичную валидацию обязательных полей и безопасную очистку данных:

const errors: string[] = [];
if (!name) errors.push('Отсутствует наименование');
if (!price || price <= 0 || isNaN(price)) errors.push('Некорректная цена');
if (!unit) errors.push('Отсутствует ед. измерения');

Каждая строка получает флаг _isValid и массив ошибок, а функция parseNum вычищает лишние пробелы и нормализует запятые при парсинге чисел. 

Где пришлось дорабатывать

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

1. Отсутствие лимита на размер файла

В функции processFile полностью отсутствует проверка file.size. Загрузка тяжёлой таблицы, например, на 100 МБ заставит SheetJS парсить её в едином синхронном потоке, что моментально заблокирует main thread и заморозит вкладку браузера. Чтобы исправить, добавили жёсткий фильтр до начала чтения:

if (file.size > 10 * 1024 * 1024) { setError('Файл слишком большой (максимум 10 МБ)'); return; }

2. Риск Excel-инъекций (Formula Injection) 

Вредоносные ячейки вида =CMD|'/C calc'!A1 или =HYPERLINK(...) считываются парсером как обычные строки. В текущей версии сервис генерирует файлы .docx, поэтому вектор атаки неактивен. Однако если в будущем добавить функцию обратного экспорта данных в XLSX, эти строки потребуют обязательной санитаризации: 

const sanitizeCell = (val: string) => /^[=+\-@]/.test(val) ? `'${val}` : val;

3. Отсутствие ограничения на количество строк

Если пользователь загрузит прайс-лист на 500 000 позиций, весь массив отпарсенных данных попадет в useState. Попытка отрендерить такую таблицу в предпросмотре вызовет переполнение памяти и обрушит DOM-дерево. Чтобы исправить, обрезаем массив данных сразу после парсинга:

(if (rows.length > 5000) rows = rows.slice(0, 5000))

4. Обработка ошибок чтения

Конструкция reader. обрабатывает сбой на уровне промиса, но не передает понятное уведомление в пользовательский интерфейс. При попытке загрузить битый или заблокированный файл приложение просто замирает в состоянии загрузки. 

Файлы обрабатываются локально через FileReader + SheetJS, поэтому эти недочёты не угрожают бэкенду. Они касаются исключительно стабильности вкладки и удобства пользователя. Ручная доработка лимитов и обработчиков ошибок закрыла эти риски.

Экономика проекта: вайбкодинг vs классическая разработка

Главный аргумент за использование AI-инструментов в продуктовой работе — оптимизация ресурсов и времени на этапе проверки гипотез, а не погоня за трендами.

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

Вот как выглядит сравнение реальных затрат:

*Стоимость проверки гипотезы, без учёта последующей инженерной поддержки

А что по бизнес-метрикам?

Мы запустили серию таких микросервисов для проверки гипотез. За время эксперимента через все сервисы-лидмагниты прошли около 1500 целевых пользователей. Результаты следующие:

➡️ 53% пользователей полностью прошли встроенные продуктовые опросы и дали качественные данные для аналитики.

➡️ 35% пользователей протестировали интерактивное демо.

➡️ 14% пользователей скачали готовые шаблоны и документы.

Один из аналогичных экспериментов (сервис проверки и сверки КУДиР) показал высокий спрос и стал полноценной точкой входа в продуктовую экосистему. Через этот бесплатный инструмент мы привлекаем клиентов в нашу основную товароучётную систему — конверсия из микросервиса в итоговую продажу вышла на результативный уровень (NDA).

Где вайбкодинг пасует ⚠️ 

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

1. Legacy и архитектура: Replit Agent пока не способен адекватно работать с монолитом компании, тяжёлой архитектурой и специфическими API.

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

3. Поддержка и развитие. Вайбкодинг не предназначен для продуктов со сложным планом доработок. Мы применяем его только в автономных сервисах, где не планируется регулярная доработка. Переносить такой код в разработку не нужно: поддержка и точечные правки делаются в Replit. Это выходит бюджетно — 20 $ за подписку на все проекты плюс 20–30 $ на кредиты, когда нужно внести небольшие изменения.

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

Вайбкодинг — в первую очередь про устранение трения между гипотезой и её проверкой. Заменить полноценного программиста он всё-таки не сможет.

Чек-лист: как продакту ставить задачи нейросети

1. Задавайте роль. Начинайте диалог с определения квалификации: «Ты Senior Frontend-разработчик на React».

2. Давайте твёрдый контекст. Подгружайте ссылки на ГОСТы, нормативку, формулы из законов и скриншоты дизайна.

3. Формулируйте Definition of Done. Чётко описывайте финальный артефакт: «В результате должен получиться файл DOCX с таблицей ценников под печать на A4».

4. Разделяйте аналитику и код. Не пытайтесь заставить кодинг-агента проводить кастдев. ТЗ пишите в текстовой нейросети, а сборку делайте в специализированном агенте.

Теперь на разработку микросервисов уходит пара дней

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

Делитесь в комментариях: пробовали собирать сервисы с помощью AI-агентов или всё ещё ждёте свободных ресурсов разработки?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

100%👍 Отличный способ быстро проверять идеи без траты ресурсов команды.1

0%🤔 Нормально для прототипов, но в продакшен такое пускать нельзя.0