Сделали прототип с ИИ: когда этого хватает, а когда нужна разработка

Игорь, основатель Diaverse · 8 октября 2026 · 15 минут чтения

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

Для чего прототипа с ИИ действительно хватает?

Главное: если прототип делает свою работу — проверяет идею, приносит первые деньги или экономит часы команды, — торопиться в разработку не нужно. Разработка нужна, когда у прототипа появляются задачи, которые он не тянет.

Вайбкодинг (код по вашим описаниям пишет ИИ) и конструкторы с ИИ сильно снизили порог входа: рабочую версию можно собрать самому за несколько вечеров и показать живым людям.

Мы разобрали больше 500 открытых историй, отзывов, вопросов и заявок о заказе разработки, и голоса про ИИ в них расходятся. Одни владельцы бизнеса за несколько недель сделали с ИИ больше внутренних инструментов, чем раньше за годы с программистами. Другие собрали прототип сами и упёрлись: он перестал работать, и починить его не помог даже тот же чат-бот. Третьи пишут в заявках, что не хотят код, который сгенерировал ИИ и не посмотрел ни один человек. На мой взгляд, правы все трое — у них просто разные задачи.

Прототипа с ИИ обычно достаточно, чтобы:

• Проверить идею. Человек проходит живой сценарий сам, а вы смотрите, пользуется ли он им. Как устроить проверку по шагам — в статье «Как проверить спрос на идею приложения до разработки».
• Показать идею пользователям и партнёрам. Версия по ссылке объясняет идею лучше презентации.
• Собрать первые оплаты. Первые 10–20 клиентов платят по ссылке или по счёту, часть работы вы делаете вручную — это нормальный этап. Только принимайте деньги через готовую платёжную страницу сервиса, а не через самодельную форму с данными карты.
• Закрыть внутренние задачи. Калькулятор для менеджеров, удобный экран поверх таблицы заявок, бот для отчётов. Пользователи свои, ошибку замечают сразу.
• Понять, что вам на самом деле нужно. Прототип показывает, что важно, что лишнее и где люди путаются.

Как понять, что прототип упёрся в потолок?

Главное: потолок — это не «код некрасивый». Это момент, когда ошибка прототипа начинает стоить денег, данных или доверия людей, а надёжно исправить её вы уже не можете.

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

• Падает под нагрузкой или со временем. У вас всё летает, а при двадцати одновременных пользователях тормозит. Или работает день-два и останавливается.
• Правки ломают соседнее. Просите ИИ поправить кнопку — ломается оплата. Каждая правка дольше предыдущей, и вы боитесь что-то трогать.
• Деньги. Платежам нужны обработка сбоев, возвраты, чеки и история операций. Ошибка здесь — уже не баг, а чужие деньги.
• Персональные данные. Телефоны, адреса, документы, сведения о здоровье. Утечка бьёт и по людям, и по вам. Если пользователи из России, у закона о персональных данных (152-ФЗ) есть отдельные требования, в том числе к месту хранения данных. Это не юридическая консультация: проверяйте с юристом.
• Вход и роли. Клиенты, менеджеры и администратор должны видеть только своё. В прототипах права нередко проверяются только на экране, а не на сервере, и это незаметно, пока кто-нибудь не посмотрит внимательно.
• Публикация в App Store и Google Play. Apple ждёт, что приложение будет чем-то большим, чем упакованный сайт, и что созданный в приложении аккаунт можно в нём же удалить. У Google Play тоже есть требование об удалении аккаунта. Веб-прототип в обёртке приложения может проверку не пройти, а решение принимают Apple и Google.
• Интеграции. CRM, учётная система, склад, рассылки. Если никто не продумал, что делать при сбое, данные теряются или задваиваются.
• Поддержка без автора. Прототип понимает только тот, кто его собирал, а решения остались в переписке с ИИ. Если продуктом займётся кто-то ещё, это риск.

Один признак — ещё не повод всё переделывать. Но если совпадают три и больше, особенно деньги или персональные данные, я бы начал планировать переход.

Чем прототип отличается от продукта для пользователей?

Это не оценка «плохо — хорошо». У прототипа и продукта разные задачи, поэтому и требования разные.

Что проверить в прототипе прямо сейчас, если вы не технарь?

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

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

• Где лежат ключи и пароли. Ключи к платёжному сервису, ИИ-сервису и базе — это ключи от сейфа. Спросите ассистента, который собирал прототип, или разработчика: хранятся ли они отдельно от кода и не попадают ли в то, что загружается в браузер или приложение пользователя. Ключ, который хоть раз был в открытом доступе, меняют.
• Кто видит базу данных. Закрыта ли база для посторонних и видит ли пользователь только свои записи? В одной из разобранных нами историй по нужной ссылке любой мог попасть в базу, админку и ключи сервисов. Там это была работа подрядчика, а не ИИ, но в непроверенных прототипах встречается то же самое.
• Есть ли резервные копии. Когда сделана последняя, где лежит и восстанавливались ли из неё. Копия, из которой ни разу не восстанавливались, — это надежда, а не копия.
• Сколько стоят ИИ-запросы в месяц. В кабинете ИИ-сервиса посмотрите расходы за прошлый месяц, лимит и уведомления. Как посчитать на будущее — в следующем разделе.
• На ком всё оформлено. Платформа или хостинг, домен, ИИ-сервис, платёжный сервис — на вас или на знакомом, который помог настроить? И можно ли выгрузить код и данные, если решите уйти с платформы?

Сколько будут стоить ИИ-функции, когда придут пользователи?

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

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

1. Цена одного действия. Прогоните через прототип 30–50 типичных запросов и посмотрите в кабинете ИИ-сервиса, сколько они стоили. Разделите сумму на число запросов. Цена зависит от модели, длины текста, минут аудио и числа картинок.
2. Действия одного пользователя в месяц — в обычном случае и отдельно для самых активных.
3. Умножьте на число пользователей из плана и сравните с тем, сколько пользователь платит вам. Если ИИ съедает заметную часть выручки, модель нужно менять до роста, а не после.

Кроме расчёта, заложите защиту.

• Лимит расходов в кабинете ИИ-сервиса и уведомление, когда потрачена большая часть месячного бюджета.
• Лимит на пользователя, особенно на бесплатном тарифе. В одной из заявок выборки прямо просят защитить бота от тех, кто будет без конца нажимать кнопку и расходовать оплаченный баланс.
• Ограничение длины. Длинный документ или час аудио стоят намного дороже короткого вопроса.
• Проверка ответов. ИИ иногда уверенно выдумывает ссылки, цены, номера документов. Если ошибка стоит денег или репутации, нужна проверка правилами, второй моделью или человеком — так и описывает одна из заявок выборки.
• Доступность и данные. Работает ли ИИ-сервис там, где живут ваши пользователи, и какие данные вы ему передаёте? Персональные данные клиентов отправляйте туда, только понимая, где они обрабатываются, — и обсудите это с юристом.

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

Как перейти к разработке и не выбросить то, что уже сделано?

Главное: прототип — это живое ТЗ. Он уже показывает, как должен работать продукт, где путаются люди и что им действительно нужно. Это знание нельзя выбрасывать, даже если код придётся пересобрать.

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

1. Сохраните всёкопия кода, базы, промптов и важных переписок с ИИ; все аккаунты — на вас
2. Опишите, что работаетвидео главного сценария, список экранов, данные, реальные вопросы пользователей
3. Разделите: оставить и пересобратьрешает разработчик, который посмотрел код, а не первое впечатление
4. Соберите главный сценарий на новой основепрототип пока работает для текущих пользователей
5. Перенесите пользователей и данныепо плану, с копией и возможностью вернуться
6. Развивайте продуктновые функции — после переезда, а не во время

Видео сценария, список экранов и страница о цели продукта — уже хорошее задание для команды; как собрать его, разбираем в статье «Как поставить задачу разработчику, если вы не технарь». Отдельно запишите, что после переезда должно работать так же, как сейчас. Встречается полезный приём: заказчик перечисляет части системы, которые после доработки должны работать как прежде, — это готовые критерии приёмки.

Что обычно стоит оставить

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

Что обычно пересобирают

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

Это частый расклад, а не правило: иногда код прототипа можно развивать, иногда проще собрать заново почти всё. Решайте после того, как независимый разработчик посмотрит код и составит список «оставляем / чиним / переписываем». Как устроить разбор и передачу проекта — в статье «Разработка стоит слишком дорого или подрядчик пропал».

Как работать с командой, которая тоже пишет код с ИИ?

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

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

• Люди проверяют каждое изменение до того, как оно попадёт в основную версию. Спросите, кто именно и где это видно в репозитории.
• За архитектуру и безопасность отвечает конкретный человек, с которым можно обсудить, почему сделано так.
• Показ работающей версии каждую неделю — ссылка, по которой вы сами проходите сценарий, а не отчёт о часах.
• Код в вашем репозитории с первого дня. История изменений видна вам и любому независимому разработчику.
• Автоматические проверки главного сценария. Правки с ИИ тоже ломают соседнее; тесты ловят это до пользователей.
• Аккаунты ИИ-сервисов и ключи — на вас, включая те, что работают внутри продукта.
• Документация и инструкция по запуску, чтобы продукт пережил смену команды.

Если команда не может простыми словами объяснить, как проверяется код, написанный с ИИ, — задайте ещё вопросы. Какие именно, разбираем в статье «Как выбрать подрядчика для разработки и не потерять предоплату».

Что делать, если прототип уже сломался при живых пользователях?

Главное: сначала остановите потери, потом чините. Самая частая ошибка в этот момент — десятки поспешных правок с ИИ прямо в работающей версии.

1. Остановите правки в работающей версии: каждая попытка «быстро поправить» может испортить данные.
2. Сделайте копию базы и кода как есть, даже сломанных.
3. Верните последнюю рабочую версию, если платформа хранит историю, и пройдите главный сценарий сами.
4. Предупредите пользователей коротко и честно.
5. Проверьте деньги и данные: прошли ли платежи, не видны ли чужие записи. Если могли утечь персональные данные, у закона есть требования, кого и в какие сроки уведомлять, — посоветуйтесь с юристом.
6. Только потом решайте, чинить точечно или переходить к разработке.

Чек-лист: пора ли переходить от прототипа к разработке

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

Частые ошибки

• Считать прототип игрушкой и выбрасывать его вместе со знанием о пользователях.
• Думать, что раз прототип работает у вас, он выдержит и тысячу человек.
• Чинить сломанное поспешными правками в работающей версии.
• Запускать рекламу, не посчитав цену ИИ-функции на одного пользователя.
• Переносить в продукт всё подряд, включая функции, которыми никто не пользовался.
• Оформлять аккаунты, домен и платёжный сервис на человека, который помог настроить.
• Выбирать команду по ответу «используем ИИ», а не «вот как мы проверяем результат».

Читайте также

• Как проверить спрос на идею приложения до разработки
• Как поставить задачу разработчику, если вы не технарь
• Как принять работу у разработчика, если вы не разбираетесь в коде
• Словарь заказчика: MVP, ТЗ, деплой и другие слова простым языком