Как собрать работающий продукт или внутренний инструмент для бизнеса с помощью ИИ-инструментов — быстро, дёшево и так, чтобы через месяц не пришлось всё выбрасывать и переписывать с нуля? Без иллюзий, что ИИ заменяет разработчика, но и без снобизма, что «настоящий софт так не делают».
Ко мне регулярно приходят с одной историей: «собрал приложение сам, без программистов — а теперь его взломали, оно падает и его невозможно доработать». ИИ действительно позволяет человеку без технического бэкграунда собрать рабочий продукт за вечер. Проблема не в инструментах, а в самом подходе и правильном порядке действий. Почти все начинают с середины — открывают ИИ-сервис, пишут «сделай мне CRM» и потом месяцами воюют с результатом.
Ниже — инструкция, которая сэкономит эти месяцы. Проходите по порядку: первые три пункта занимают полчаса и определяют всё остальное.
1. Решите, что вы строите
Прототип или продукт — это разные виды работы и к ним нужен разный подход.
Определитесь с тем, что именно вы строите. Вариантов всего три, и они требуют разного:
— Прототип. Нужен, чтобы проверить гипотезу и выбросить. Вайбкодинг здесь незаменим.
— Внутренний инструмент. Пять своих пользователей, сбой переживём. Вайбкодинг / zerocoding — подходит.
— Продукт для клиентов. Чужие данные, деньги, годы жизни. Здесь в одиночку с вайбкодингом — точно не справиться.
Если ответ неочевиден, расставить всё по местам помогают три вопроса:
— Что будет, если это сломается в пятницу вечером? - «Ничего страшного, на следующей неделе починим» — работайте смело. - «Потеряем деньги и клиентов» — планируйте участие инженеров с самого начала.
— Сколько оно должно прожить? Решение на месяц и решение на пять лет проектируются по-разному, и сэкономить здесь не получится.
— Как вы поймёте, что получилось? Критерий успеха нужно назвать до начала работы, и он должен быть измеримым: время операции, число ошибок, конверсия, стоимость. «Менеджер оформляет заявку за 5 минут вместо 30» — это критерий. «Станет удобнее» — нет.
Стоп-сигнал: если сценарий нельзя объяснить в двух предложениях — его ещё рано отдавать ИИ.
И ещё:
- Не превращайте прототип в боевую систему незаметно для себя — это самая дорогая ошибка из всех.
- Проверьте, нужно ли вам вообще приложение: очень часто настоящая задача звучит как «связать почту, CRM и таблицы и перестать копировать данные руками» — а это автоматизация, которая делается за вечер и без единого экрана в том числе с помощью инструментов zerocoding.
2. Выберите инструмент под задачу
Инструментов десятки, но категорий всего четыре. Сначала задача — потом платформа: один и тот же промпт не превращает разные классы систем в одинаковые проекты.
Приложение из промпта. Lovable, Base44, Bolt.new, v0, Replit. Описал словами — получил веб-приложение с базой данных, авторизацией и вполне приличным интерфейсом. Lovable выдаёт первую рабочую версию минут за пять. Территория людей вообще без IT-бэкграунда.
Автоматизация и агенты. n8n, Make, Zapier. Здесь не строят приложения — здесь связывают то, что уже есть: почту, CRM, таблицы, мессенджеры. Заявка упала на почту → разобрана ИИ → занесена в CRM → менеджеру ушло уведомление. Скучная рутина умирает пачками, и это прекрасно.
Внутренний сервис. Retool, Glide, Softr, Bubble. Рабочее место для команды: админка, реестр, дашборд, каталог. Данные обычно уже есть в базе или таблицах — нужен удобный интерфейс к ним и разграничение прав, а не новый продукт.
ИИ в руках разработчика. Claude Code, Cursor, Windsurf, GitHub Copilot. Работают с настоящим кодом в настоящих проектах и раскрываются в руках того, кто понимает, что делает. Зато раскрываются так, что опытный инженер успевает за день столько, сколько раньше — за неделю.
Выберите один инструмент и не перепрыгивайте между разными. Прыжки удваивают работу и ничего не ускоряют.
Берите генератор под приложение, автоматизатор — под рутину. Собирать полноценный сервис там, где хватило бы связки из n8n, — самая частая переплата временем.
Посчитайте стоимость на горизонте года, а не по бесплатному тарифу. Бесплатного лимита хватает на демо, а настоящий счёт приходит, когда появляются живые пользователи.
Проверьте, отдаёт ли платформа код целиком. Об этом — следующий пункт, и он важнее, чем кажется на старте.
3. Убедитесь, что сможете забрать своё
Приложение, которое живёт только внутри чужого сервиса — вам не принадлежит!
На витрине три главных платформы выглядят одинаково: «опиши словами — получи приложение». Разница всплывает в момент, когда игрушка становится бизнесом.
Выясните, что именно вы сможете забрать, если решите уйти. У Base44 экспортируется только внешняя часть (frontend, интерфейс), при этом база, авторизация и серверная логика остаются внутри платформы. Это честная плата за самый быстрый старт — но знать об этом нужно до, а не после.
Помните, что переносимость кода — это не то же самое, что переносимость бэкенда, данных и эксплуатации. Забрать исходники и получить работающую систему на своём сервере — две разные задачи. И даже при полном экспорте кода сама среда разработки с ИИ-агентом остаётся облачным сервисом: развивать проект по-прежнему придётся у них или потом переписывать с нуля уже руками разработчиков.
Узнайте, где физически лежат данные пользователей. Вопрос всплывёт на первом же корпоративном клиенте или при первой проверке.
Если данные не должны покидать контур — выбирайте платформу с возможностью self-host (с возможностью развернуть у себя). Задним числом это не исправляется, только переписыванием.
Ответьте себе: что станет с приложением, если вы перестанете платить? Для внутреннего инструмента — это приемлемый риск, для продукта с клиентами — нет.
Если продукт живёт неделю — берите то, что быстрее. Если появятся клиентские данные или реальная выручка — берите то, откуда есть выход.
4. Соберите ТЗ до начала реальной разработки
Модель не телепат — на запрос «сделай мне CRM» она выдаст «среднее по интернету».
Разница видна на одном примере:
- Плохая формулировка: «Сделай CRM для компании».
- Рабочая формулировка: «Менеджер загружает запись звонка и получает резюме, договорённости и следующую задачу».
Первая описывает класс систем, вторая — конкретное действие конкретного человека. ИИ хорошо справляется со второй и плохо с первой.
Начните не с конструктора приложений, а поговорите с LLM. Попросите её собрать с вами спецификацию: пусть она задаёт вопросы, а вы отвечаете. Получившийся документ и станет вашим первым промптом.
Запишите ТЗ текстом, а не держите в голове. Полчаса здесь экономят неделю переделок: ИИ не «правит», а часто перестраивает, ломая по пути то, что раньше работало. Поэтому нужно ТЗ / спецификация.
Перечислите все экраны и роли пользователей. Пока роли не выписаны, права доступа никто не спроектирует — ни вы, ни модель.
Опишите, что происходит при ошибках. Что видит человек, если данные неверны, файл не того формата или внешний сервис недоступен. ИИ по умолчанию проектирует только основной путь, а пользователи могут ходить другими.
Заложите журнал действий сразу. Кто, что и когда изменил — настолько же важно, как пользователи или основные бизнес-процессы. Добавить журнал потом гораздо дороже, а без него не разобрать ни один спорный случай: ни ошибку сотрудника, ни жалобу клиента, ни утечку.
Выпишите отдельно, чего в первой версии НЕ будет. Такой список дисциплинирует ИИ сильнее, чем список пожеланий «что надо».
Определите, какие данные вы храните и какие из них чувствительные. Персональные и платёжные данные меняют требования ко всему проекту.
Промпт для сборки ТЗ — скопируйте и вставьте
Ты — опытный продуктовый аналитик.
Помоги составить техническое задание на приложение, которое я буду собирать в ИИ-конструкторе.
Задавай мне вопросы по одному блоку за раз и не переходи дальше, пока ответ неполный.
Блоки:
1. Какую одну главную задачу решает продукт;
2. Кто пользователи и их роли;
3. Список экранов с их функционалом;
4. Что происходит по каждой кнопке и при взаимодействии со значимыми элементами интерфейса;
5. Какие сущности и поля храним;
6. Кто что имеет право видеть и менять;
7. Будет ли подключение к внешним сервисам и/или платёжным сервисам;
8. Что показываем при ошибках: неверные данные, недоступный внешний сервис;
9. По какому измеримому критерию поймём, что продукт работает;
10. Чего в продукте НЕ будет в первой версии (чтобы ограничить scope).
В конце выдай готовое ТЗ структурированным текстом и отдельно — список рисков и вопросов, на которые я не ответил.
5. Постройте запрос по структуре
Хороший промпт — это техзадание, а не пожелание.
Роль ИИ и стек разработки. Кем выступает модель и на чём собирает: «Ты — senior-разработчик. React, Tailwind, база — Postgres».
Контекст. Что за продукт? Для кого? Какую задачу решает? — два-три предложения из вашего ТЗ.
Одна конкретная задача на заход. Не «приложение», а «экран списка заявок с фильтром по статусу».
Данные и права. Какие сущности и поля, кто что видит. ИИ сам не догадается, что менеджер не должен видеть чужие сделки.
Критерий готовности. Что именно вы проверите руками, чтобы принять работу.
Ограничения. Чего не делать? Например, «не менять другие экраны», «не добавлять новые библиотеки», «не трогать структуру базы без спроса».
Порядок работы. Сначала план, структуры данных и допущения — и никакой реализации до вашего согласования. Это единственный способ поймать неверно понятую задачу до того, как она превратится в код или сервис.
Шаблон запроса на один экран
Контекст: сервис учёта заявок для небольшой сервисной компании. Роли: менеджер, администратор.
Задача: сделай экран «Заявки» — таблица со столбцами: номер, клиент, статус, дата, ответственный.
Фильтр по статусу, поиск по клиенту, кнопка «Новая заявка» открывает модальное окно.
Данные: сущность «Заявка» с полями (...). Менеджер видит только свои заявки, администратор — все.
Ошибки: что показать при пустых обязательных полях и при недоступности базы.
Успех: менеджер создаёт заявку и видит её в списке без перезагрузки страницы.
Ограничения: не меняй другие экраны и структуру базы, не добавляй новых зависимостей.
Сначала покажи план, структуру данных и свои допущения. Ничего не реализуй до моего согласования.
Если для задачи не хватает данных — сначала задай мне вопросы, не придумывай сам.
Главная фраза, которую стоит держать в каждом промпте: «Если для задачи не хватает данных — задай мне вопросы, не придумывай сам». Без неё модель заполнит пробелы догадками и уверенно сообщит, что всё готово.
6. Итерируйте мелкими шагами
Принцип «сделай всё сразу» работает плохо.
Стройте вертикальным срезом. Сначала один пользователь проходит весь путь целиком для решения конкретной задачи — от входа до результата и проверки. Настройки, аналитика, остальные роли и красивый дизайн появляются только после этого.
Пока сквозной путь не работает, любые дополнительные экраны только увеличивают то, что потом придётся переделывать.
Один заход — один экран или одна функция. Работает — фиксируете версию. Не работает — откатываетесь к последней рабочей и переформулируете запрос, а не наслаиваете исправления на сломанное.
Если вы пользуетесь кодинг-агентами — подключите GitHub в первый день, а не «когда понадобится». Это бэкап, история версий и страховка от привязки к платформе одновременно.
После каждой итерации проверяйте, что старое не сломалось. Заведите список из 5–7 тестовых действий и прогоняйте его каждый раз: вход, создание записи, редактирование, удаление, выход.
Разделите тестовые и настоящие данные. Экспериментировать на живой базе клиентов — способ потерять её целиком. Известны случаи, когда ИИ-агент во время объявленной заморозки кода удалял боевую базу, а затем сгенерировал фальшивые записи и отчитался, что всё в порядке.
Ловите момент, когда правки начинают ломать друг друга. Просите поправить кнопку — отваливается оплата; чините оплату — ломается регистрация. Это не полоса неудач, а сигнал: проект перерос размер, который модель удерживает его «в голове» целиком.
7. Попробуйте сломать продукт
Основной сценарий проверяет, что система может работать. Пограничные показывают, будет ли она работать в реальности.
Пройдите каждый пункт руками — именно здесь вайбкоженные приложения ломаются чаще всего:
- пустое обязательное поле → понятная подсказка, введённое не теряется;
- неверный формат файла или значения → операция отклонена без падения;
- двойное нажатие кнопки → нет дублей и двойных списаний;
- внешний сервис недоступен → показана ошибка и предусмотрен повтор операции;
- первый вход, когда данных ещё нет → рабочее пустое состояние, а не пустой экран;
- чужая ссылка или чужой ID записи → доступ запрещён;
- обновление страницы посреди работы → состояние и результат сохранены;
- мобильный экран → главный сценарий выполним.
Дайте пройти сценарий человеку со стороны. Новый пользователь должен выполнить главное действие без ваших подсказок и объяснений. Всё, что придётся объяснять голосом, в реальности станет отвалившимся клиентом или письмом в поддержку.
Проверьте по одному тесту на каждую роль. Менеджер, администратор, клиент — у каждого свой набор того, что он может и чего не должен.
8. Пройдите проверку безопасности до публикации
ИИ пишет код, который работает, а не код, который нельзя взломать — вторую задачу ему никто не ставил.
Демо обманчиво: кнопки нажимаются, данные сохраняются, и кажется, что всё готово. Но видимая часть — только небольшая часть системы.
Массовое сканирование 5600 таких приложений нашло более 2000 уязвимостей и около 400 ключей и паролей, лежащих прямо в открытом коде. Это не редкость, а норма для непрофессиональных разработчиков.
Проверьте, кто может открыть админку и чужие данные.
Откройте приложение в другом браузере без входа и попробуйте адреса вида /admin. Затем создайте двух обычных пользователей и под одним из них попробуйте открыть данные другого — и через адрес страницы, и через API, если он есть.
Уберите пароли, ключи и токены из кода. Их место — в хранилище секретов платформы (или в отдельных файлах, не попадающих в систему контроля версий). Если ключ хоть раз попал в код или репозиторий — удалите репозиторий и создайте новый (или «перепишите историю», если вы умеете это делать).
Сделайте бэкап базы и проверьте восстановление руками. Не просто доверяем платформе, которая «вроде бы делает бэкапы», а пробуем восстановиться хотя бы раз, чтобы проверить, что всё работает.
Проверяйте данные из форм на сервере, а не только в браузере. Проверка в браузере обходится за десять секунд.
Поставьте ограничение частоты запросов. Иначе за ночь выжгут ваши платные API-ключи — известны случаи, когда именно так продукт превращался из источника дохода в источник счетов.
Требуйте подтверждения на удаление и массовые изменения. Одна кнопка, стирающая всё без вопросов, рано или поздно будет нажата.
Собирайте только те персональные данные, которые реально нужны. Данные, которых у вас нет — невозможно потерять и они не утекут.
Попросите модель проверить собственную работу — «Найди в этом проекте уязвимости, открытые эндпоинты, отсутствующие проверки прав доступа и секреты в коде; перечисли по степени опасности». Аудит это не заменяет, но верхний слой проблем снимает за десять минут.
9. Настройте прод и владение
У всех этих платформ приложение по умолчанию живёт в их облаке — для прототипа это подходит, для бизнеса — не очень.
Помните: свой домен ≠ свой сервер. Подключённый домен меняет адрес, но не обязательно меняет место, где физически работает приложение и лежат данные. Разберитесь отдельно, где живут фронтенд, бэкенд, база и файлы.
Узнайте цену хостинга при десятикратном росте пользователей. У Replit это либо автомасштабирование с оплатой за фактическое потребление, либо выделенная машина от десяти долларов в месяц. Lovable отдаёт обычный проект, который разворачивается где угодно, вплоть до вашего сервера.
Настройте оповещение о падении — раньше, чем позвонит клиент. Хотя бы простейший внешний монитор с уведомлением в мессенджер.
Отделите боевые данные от тестовых и экспериментов. Публикация не должна означать, что вы продолжаете пробовать новое на том же экземпляре, где работают люди.
Оформите домен и учётные записи на компанию. Не на личную почту сотрудника или подрядчика — иначе однажды выяснится, что продукт вам не принадлежит юридически.
Держите код не только внутри платформы. Минимум — синхронизация с GitHub. Максимум — проверенная возможность развернуть у себя.
10. Знайте свои стоп-сигналы
Инструмент не заменяет компетенцию, а умножает её. На что ноль не перемножай...
Нетехнический основатель с ИИ получает результат быстро — и ровно до первого столкновения с подводной частью. Опытный инженер с тем же ИИ получает результат тоже быстро, но с архитектурой, безопасностью и нормальным продом, потому что знает, что они должны там быть.
Между демо и работающей системой — три ступени, и каждая следующая отвечает не за новые экраны, а за новый уровень ответственности:
Production-ready — это не красивый интерфейс. Это тесты, миграции, мониторинг, резервное копирование, восстановление, модель угроз, документация и человек, отвечающий за эксплуатацию.
Пора звать инженеров, если верен хотя бы один пункт:
- в приложении появились чужие персональные или платёжные данные;
- продукт считает реальные деньги: платежи, цены, скидки, выплаты, комиссии;
- правка одной кнопки ломает три других места;
- пользователей стало больше сотни;
- продукт из эксперимента превратился в то, на чём стоит выручка и весь бизнес;
- вы больше не понимаете, что происходит внутри, и не можете это объяснить;
- простой на день означает реальные потери денег или репутации;
- нужны SLA, аудит, соответствие требованиям или хранение в конкретном контуре.
11. Подготовьте передачу
Рано или поздно проект передают: наняли разработчика, позвали подрядчика, ушёл сотрудник, который всё это собрал. Хорошая передача позволяет продолжить работу без «археологии» в чатах, промптах и случайных настройках — и стоит она в разы дешевле, чем разбор чужого «наследства».
Соберите пакет заранее, пока всё помните:
- короткое описание цели, пользователей и главного сценария;
- ссылка на репозиторий и зафиксированная рабочая версия;
- схема данных, роли и правила доступа;
- список интеграций, владельцев аккаунтов, ключей доступа;
- инструкция запуска и публикации обновлений;
- тестовые сценарии и список известных ограничений;
- схема резервного копирования, восстановления и отката;
- измеренный критерий успеха и стоимость эксплуатации.
Если этот пакет собран, передача инженерам занимает дни. Если нет — недели, и вы заплатите за них дважды.
Коротко: маршрут целиком
- Решите, что вы строите, назовите измеримый критерий успеха и признайте прототип черновиком.
- Выберите инструмент под задачу — возможно, вам нужна автоматизация, а не приложение.
- Убедитесь, что сможете забрать своё с платформы.
- Соберите ТЗ до первого промпта — со сценарием, ошибками и журналом действий.
- Постройте запрос по структуре и требуйте план до реализации.
- Итерируйте мелкими шагами, начиная со сквозного пути; фиксируйте версии.
- Попробуйте сломать продукт: пограничные случаи, а не только основной сценарий.
- Пройдите проверку безопасности до первого живого пользователя.
- Настройте прод и оформите владение на компанию.
- Держите в голове стоп-сигналы и не проходите их молча.
- Подготовьте пакет передачи, пока всё помните.
Пять вопросов, на которые нужен ответ «да»
- Пользователь получает измеримую ценность?
- Вы понимаете полную стоимость эксплуатации?
- Код и данные можно забрать с платформы?
- Ошибка не приводит к необратимому ущербу?
- Есть человек, отвечающий за прод (чтобы всё продолжало работать)?
Если хотя бы один ответ «нет» — у вас пока эксперимент, а не система. Это нормально, если вы это знаете.
Заключение
Сейчас лучшее время в истории, чтобы быстро проверять идеи самостоятельно. Раньше, чтобы узнать, что продукт никому не нужен, требовались месяцы работы и приличный бюджет. Теперь — одни выходные + стоимость подписки. Возможность «дешёвого ошибаться» — возможно, главный подарок, который технологии сделали предпринимателям.
Но у скорости есть граница, и проходит она там, где начинаются чужие данные, чужие деньги и годы жизни продукта. Вайбкодинг не заменяет инженерию — он снимает с неё рутину.
Если продукт перерос стадию «на коленке», могу порекомендовать своего партнёра по REG.RU, бывшего руководителя разработки Валерия Студенникова с его студией заказной разработки LLM Technology. Ребята также вооружены ИИ-инструментами, поэтому выходит быстрее и дешевле услуг классических компаний заказной разработки. При этом — за штурвалом опытные инженеры, которые отвечают за всю невидимую часть работы: архитектуру, безопасность, нагрузку, надёжность и отказоустойчивость.
Забирайте, адаптируйте под себя, пересылайте тем, кто прямо сейчас хочет быстро проверить гипотезы и что-то попробовать создать с помощью ИИ.