Вы собрали MVP с помощью ИИ. Оставить, доработать или переписать?

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

КОРОТКО

Оставить, доработать или переписать

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

Термин vibe coding появился в начале 2025 года: так Андрей Карпаты назвал разработку, при которой вы описываете ИИ-модели, что хотите получить, и принимаете написанный ею код. Спустя полтора года платформы, которые генерируют, тестируют и разворачивают приложение по текстовому описанию, стали обычным инструментом. Если задача достаточно узкая, владелец может собрать работающую версию за выходные, дать её клиентам или сотрудникам и посмотреть, что произойдёт.

Этот сдвиг удешевил скорее попытку, чем сам софт. А для владельца, который собирается потратить на следующий этап от $50,000 до $100,000, он меняет и вопросы, которые стоит задать до того, как деньги будут вложены.

НОВЫЙ РАЗГОВОР

Разговор стал другим

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

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

Часть таких экспериментов закончится вообще без агентства. Гипотеза может не подтвердиться, а инструмент может оказаться достаточно хорошим для своей небольшой задачи. Это нормальный результат, и владелец сэкономил деньги, которые подрядчик взял бы за то, чтобы выяснить то же самое. О более ранней версии этого решения мы писали в статье «Нужен ли мне разработчик, или хватит ИИ?», и с тех пор ответ ещё больше сместился в сторону «сначала попробуйте».

ЧТО ДОКАЗАНО

Что ваш MVP уже сделал

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

Что обычно переживает следующий этап, даже когда код его не переживает:

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

ИИ сделал софт дешевле в разработке и намного дешевле в попытке.

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

ГДЕ ЛОМАЕТСЯ

Где ломаются MVP, собранные на ИИ

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

Исследования здесь сходятся. В отчёте GenAI Code Security Report за 2025 год компания Veracode протестировала больше 100 языковых моделей на 80 задачах и обнаружила, что 45% сгенерированного кода содержали уязвимости из списка OWASP Top 10, а защита от межсайтового скриптинга не срабатывала в 86% соответствующих случаев. В том же 2025 году исследователь обнаружил, что больше 170 проектов, собранных на платформе Lovable, открывали данные наружу, потому что в базе не было правил доступа: email, телефоны, статус оплаты и API-ключи были доступны любому, кто знал, где искать. Уязвимость зарегистрирована как CVE-2025-48757.

Ни одна из этих находок не говорит, что код от ИИ плох по своей природе. Они говорят о том, что модель пишет то, что у неё попросили, а о правилах доступа её никто не спросил.

Слабые места, которые мы проверяем первыми, почти всегда одни и те же:

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

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

ПРИХОДИТЕ РАНЬШЕ

Когда приносить MVP

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

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

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

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

РЕШЕНИЕ

Оставить, доработать или переписать

Решение зависит не от вкуса и не от того, что подрядчику удобнее строить. Оно следует из того, что продукту предстоит делать дальше.

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

Работающий MVP служит доказательством. Его код представляет отдельный вопрос.

КОМАНДЫ МЕНЬШЕ

Команды меньше, предложения другие

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

Здесь часто смешивают два разных выигрыша. «В пять раз меньше людей» и «в пять раз быстрее» означают разные вещи, и их нельзя просто перемножить. Когда одновременно сокращаются и команда, и срок, честно сравнивать можно только одинаковый объём, качество, интеграции и ответственность после запуска. Даже аккуратные измерения неоднородны: в начале 2025 года METR обнаружила, что опытные разработчики с ИИ-инструментами решали реальные задачи на 19% медленнее, хотя считали, что работают быстрее, а в обновлении за февраль 2026 года сама назвала новые, более позитивные данные очень слабым доказательством.

Наши собственные цифры скромные, и поэтому мы им доверяем. Внутреннюю систему продаж Peretz с лидами, проектами и счетами примерно за месяц сделали один senior-разработчик, тестировщик и Claude, а работу проверял архитектор. Переход этого сайта с Laravel 7 на Laravel 13 занял три дня. В обоих случаях скорость дали люди, которые знали, что строить, и могли проверить то, что написал ИИ, а именно там и находится настоящая цена ИИ.

Меньше людей и быстрее сдача проекта дают два разных выигрыша.

У этого сдвига есть человеческая цена. Сокращения бьют в первую очередь по джуниорам и мидлам, чья работа как раз и состояла в реализации понятных функций, которую ИИ теперь делает быстрее всего. Stanford Digital Economy Lab по данным платёжных ведомостей ADP выяснила, что занятость специалистов от 22 до 25 лет в профессиях, сильнее всего затронутых ИИ, включая разработку, к октябрю 2025 года снизилась примерно на 16% по сравнению с менее затронутыми профессиями, а у старших коллег на тех же должностях осталась стабильной. Авторы оговаривают, что ИИ не единственная причина. Часть этих людей переквалифицируется, потому что рынок теперь платит за суждение больше, чем за набор кода. Другие начнут делать собственные продукты в нишах, которые хорошо знают, а значит, владельцев, приходящих с готовой первой версией, станет больше.

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

ДО ОПЛАТЫ

Вопросы до оплаты

Прежде чем вкладывать следующий бюджет, нам или кому-то ещё, эти вопросы стоит задать вслух:

1. Какие части моего MVP вы оставляете и почему? Команда, которая предлагает переписать всё, ещё не посмотрев, продаёт разработку, а не решение.

2. Что именно переписывается и какую проблему решает каждое переписывание?

3. Кто проверяет код, который пишет ИИ, и как? Фраза «мы используем ИИ» ничего не говорит о проверке.

4. Где будет лежать репозиторий и кому он принадлежит, вместе с доменом, хостингом и данными?

5. Что будет с моими пользователями и их данными во время переезда? Хороший план оставляет старую версию работающей, пока новая не докажет себя.

6. Что входит в цену после запуска? Поддержка, исправления и обновления входят в то, что вы покупаете.

7. Если команда большая, чем занят каждый человек? В этом вопросе нет враждебности, сейчас его задаёт весь рынок.

С подрядчиком, который спокойно отвечает на эти вопросы, стоит разговаривать. Тот, кто на первый вопрос отвечает «придётся начинать с нуля», ещё не увидев код, уже сказал вам кое-что важное.

КАК МЫ РАБОТАЕМ

Что мы делаем с MVP основателя

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

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

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

Для нас это ещё и новый тип клиента. Раньше к нам приходили с идеями, которые только предстояло проверить. Теперь всё чаще приходят с небольшими продуктами, которые уже проверены и которым нужна помощь, чтобы стать надёжным инструментом для бизнеса. Для всех это лучшая отправная точка. Для первой версии начинать стоит с оценки MVP. Если продукт уже работает как бизнес и вопрос в том, куда его развивать, лучше подходит стратегическая сессия. А если продукт становится ядром того, как работает компания, это уже проект цифровизации бизнеса, а не приложение.

ОЦЕНКА MVP

Почему сначала оценка

Самая дорогая ошибка на этом этапе редко оказывается багом. Гораздо дороже вложить от $50,000 до $100,000 в следующую версию продукта, который рынку в таком виде не нужен, или строить на основе, которую через год придётся заменить. Тот, кто собрал первую версию, хуже всех может оценить оба вопроса, и это естественно: он потратил на продукт недели и уже видит, каким тот может стать. Внешняя оценка стоит малую часть следующего этапа и отвечает на оба вопроса до того, как деньги вложены.

Поэтому мы сделали оценку MVP отдельной услугой со своей командой. Она смотрит на продукт с трёх сторон:

• Техническая. Наши разработчик и архитектор проверяют код, безопасность и инфраструктуру: правила доступа, ключи и платёжные данные, резервные копии, репозиторий и то, выдержит ли структура больше пользователей, функций и рынков.
• Продуктовая. Продуктовый стратег разбирает, что показывают данные об использовании, какие сценарии работают, где люди останавливаются и стоит ли менять логику продукта или его интерфейс.
• Рынок и бизнес. Валерия Чумаченко, наш советник с более чем десятилетним опытом в M&A технологических компаний, оценивает, нужен ли продукт рынку, кто и сколько за него заплатит и как его увидит инвестор или покупатель.

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

На выходе вы получаете письменный отчёт с вердиктом по каждой части продукта (оставить, доработать или переписать), критичные риски, которые нужно устранить до прихода реальных клиентов и платежей, рекомендации по логике продукта, оценку объёма и бюджета следующего этапа и созвон, на котором мы всё это разбираем. Оценка стоит от $3,000, чаще всего от $3,000 до $5,000 в зависимости от объёма кода, количества интеграций и того, проходят ли через продукт деньги и персональные данные. Она оплачивается заранее и не засчитывается в стоимость дальнейших работ, потому что над каждой оценкой работают несколько специалистов, а отчёт полезен независимо от того, продолжите ли вы работу с нами. С ним можно прийти к любой команде.

FAQ

Источники

• Veracode: 2025 GenAI Code Security Report
• Superblocks: Lovable vulnerability explained (CVE-2025-48757)
• Stanford Digital Economy Lab: Canaries, interest rates and timing (February 2026)
• METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity