Собрал продукт на ИИ - что дальше: как дорабатывать и не сломать работающее

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки. Подпишись, чтобы быть в курсе.

Почему после запуска начинается самое дорогое?

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

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

Компания Entelligence разобрала больше миллиона изменений в коде из 2444 команд и посчитала, куда фактически уходят деньги на ИИ-разработку. Картина такая:

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

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

Что реально ломается: 5 катастроф после запуска

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

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

Основатель Moltbook сам описал, как всё было устроено.

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

Первая страховка - это git и откат «верни как было вчера»

Когда Claude что-то ломает, тебе нужна одна кнопка «верни как было вчера». Технически эта кнопка называется git, и устроена она проще, чем кажется.

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

1. Репозиторий - это папка твоего проекта, сохранённая в облаке (обычно на GitHub). Копия всего кода, которая живёт не только на твоём компьютере.
2. Commit - это точка возврата. Условно ты говоришь коду «сохранись вот в таком состоянии». Каждый commit - метка, к которой можно вернуться.
3. Deploy - это переезд. Код был локально, на твоём компьютере, работал только у тебя. Deploy отправляет его на внешний сервер, чтобы работало у всех.

Пока у тебя есть свежие commit-точки, любую поломку можно откатить одной фразой. Буквально.

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

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

• Репозиторий - приватный. Не публичный. Иначе твой код и всё, что в нём лежит, читает кто угодно.
• Файл с секретами в списке игнорирования. Ключи, пароли, доступы к базе живут в отдельном файле (обычно .env), и этот файл никогда не попадает в репозиторий. Строчка .env в файле .gitignore - и секреты остаются только у тебя.

Про то, как безопасно откатывать изменения именно в Claude Code, я собрал отдельный разбор - как откатить изменения в Claude Code. Без точек возврата ты идёшь по канату без страховки, и рано или поздно это заканчивается падением.

Что откатывает /rewind, а что нет?

Claude Code перед каждым своим изменением делает снимок состояния. Команда /rewind (или двойное нажатие Esc) откатывает и файлы, и переписку к выбранной точке. Удобно: сломал фичу пять минут назад - вернулся на пять минут назад.

Но есть ловушка, из-за которой новички теряют данные. /rewind откатывает не всё:

Сама Anthropic формулирует это прямо: снимки - это локальная кнопка «отменить», а git - постоянная история. Снимки дополняют контроль версий, но не заменяют его.

Практический вывод для непрограммиста: /rewind спасёт от «Claude сломал функцию только что». Но если он успел удалить строку в базе или отправить код в облако - вернёт только git и бэкап базы. Поэтому держи оба слоя: снимки для быстрого отката, коммиты как постоянную историю проекта.

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

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

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

Защита от дрейфа - одно правило, которое сформулировал Саймон Уиллисон. Оно простое настолько, что его можно повесить на стену.

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

Прежде чем менять код, сделай так:

Сохрани текущее рабочее состояние отдельной точкой возврата (commit).

Опиши словами, что именно ты собираешься изменить и в каких файлах.

Внеси минимальное изменение - только то, что решает мою задачу, ничего лишнего.

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

Ещё один принцип, который экономит недели, - дисциплина границ задачи. Одна боль, одна правка, быстрая реализация. Не проси ИИ переписать полпроекта одним запросом. Профессиональные разработчики иногда зачем-то начинают строить целый Uber там, где нужна была одна кнопка, - и растягивают это на месяцы. Тебе это не нужно.

Всё, что я описываю, держится на одном - на управлении контекстом. Чтобы ИИ не ломал соседнюю логику, он должен помнить правила твоего проекта. За это отвечает связка из трёх частей, которую я разбираю на практикуме: файл правил проекта (второй мозг), ИИ-клон твоего мышления и контекст-инжиниринг. Без неё ИИ галлюцинирует и правит вслепую. С ней - держится в границах задачи.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Как проверить правку перед публикацией?

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

1. Собрал и проверил изменение у себя (разработка).
2. Выкатил на staging - копию боевого, но без реальных пользователей.
3. Прогнал ключевые сценарии, убедился, что ничего не поехало.
4. Только теперь выкатил в прод.

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

Чтобы не проверять всё вручную каждый раз, дай ИИ промпт, который сам сравнивает поведение новой версии со старой по критичным местам.

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

Регистрация и вход нового пользователя.

Оплата и выдача доступа после оплаты.

Права доступа - обычный пользователь не видит чужие данные и админку.

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

Где лежат твои секреты? Главная дыра новичка

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

Основатель, которому мошенники выставили счетов на 87 500 долларов, сам сказал потом, что предотвратить это мог один промпт. Списания в итоге отменили, но невозвратные комиссии и потерянные нервы остались. Вот тот промпт.

Проверь весь проект и убедись, что ни один секретный ключ не попадает в браузер:

Найди все ключи от базы, платёжной системы и внешних сервисов.

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

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

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

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

Пройдись по проекту как атакующий и найди дыры безопасности:

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

Включена ли защита строк (RLS) на каждой таблице базы, проверяются ли права доступа на сервере, а не только в браузере.

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

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

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

Куда поселить продукт: лестница хостинга

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

1. Бесплатный хостинг (например, Vercel) - для себя, тестов и мелочи. Работает, если у тебя нет российской аудитории и ты не хранишь персональные данные людей.
2. Платформа с публикацией через одну команду (Amvera, Timeweb, Railway) - когда появилась серверная часть и база. Публикуешь одной командой, сервер настраивать не надо. Порог входа минимальный.
3. Свой (выделенный) сервер - когда нагрузка большая и нужен полный контроль. Сюда переезжаешь позже, когда упёрся в потолок платформы.

Реальные цены по российским провайдерам на середину 2026 года (диапазоны меняются, проверь актуальное перед выбором):

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

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

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

• Приложение и база - на разные машины. Сигнал: на пике нагрузки процессор и память стабильно выше 70-80 процентов, запросы тормозят, приложение и база дерутся за одни ресурсы. После разнесения ты можешь усилить базу, не трогая приложение, и наоборот.
• Бэкапы - по правилу 3-2-1. Три копии данных, на двух разных носителях, одна - вне основной площадки. Это защищает от отказа железа и от вирусов-шифровальщиков. Ключевое - бэкап должен быть автоматическим.

Частота бэкапа зависит от того, насколько дорого потерять данные за несколько часов. Для онлайн-сервиса с подпиской, где потеря даже часа платежей критична, бэкап нужен каждый час-два. Блогу хватит и раза в день. Логика простая: считаешь, сколько данных не жалко потерять, и настраиваешь под это.

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

Насколько загружены процессор и память на пике - выше 70-80 процентов держится или нет.

База и приложение сейчас на одной машине или на разных.

Настроен ли автоматический бэкап базы и проверял ли я восстановление из него.

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

Отдельный вопрос - управляемая база или своя. Для маленькой команды почти всегда выгоднее управляемая (managed): своя дешевле по железу, но съедает часы на обслуживание. Если ты один и твой продукт - не инфраструктура, эти часы дороже, чем разница в цене сервера.

Как поставить сопровождение на автопилот?

Ручное сопровождение выматывает. Его можно снять с себя двумя способами - мониторингом и агентом-обходчиком.

Мониторинг - это два разных инструмента под две задачи:

1. «Жив ли сайт» - монитор доступности (например, UptimeRobot). Пингует продукт каждые несколько минут и шлёт сигнал, если он упал. Есть бесплатный тариф.
2. «Что именно сломалось» - ловец ошибок (например, Sentry). Собирает ошибки внутри приложения, показывает, где и почему что-то отвалилось.

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

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

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

Когда продукт пора закрыть?

Самая недооценённая часть сопровождения - вовремя перестать сопровождать. У каждого, кто много строит, есть кладбище проектов: собрал, повозился, забросил. Это нормально, и это не провал. Провал - месяцами тащить то, чем никто не пользуется, из жалости к потраченному времени.

Пороги, по которым я принимаю решение:

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

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

Сопровождение - это работа ради того, чтобы продукт оставался живым и нужным людям. Всё остальное - git, бэкапы, мониторинг - лишь инструменты, чтобы дожить до момента, когда продукт начнёт работать на тебя каждый день.

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

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email