Как сопровождать продукт на ИИ после запуска

Подробнее о работе с моделями — в документации Ailoot.

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

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

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

Отраслевой анализ более миллиона изменений кода от 2 444 команд оценил распределение затрат на ИИ-разработку:

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

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

Что может сломаться: пять проблем после запуска#

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

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

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

Первая защита — Git и возможность вернуть вчерашнее состояние#

Если Claude что-то испортил, пригодится простая возможность «вернуть, как было вчера». Она основана на Git и устроена проще, чем может показаться.

Вот три понятия, которые полезно знать даже без опыта программирования:

1. Репозиторий — папка проекта, копия которой хранится в облаке, например на GitHub. Код доступен не только на твоём компьютере.
2. Коммит — сохранённая точка в истории. Ты фиксируешь состояние проекта, чтобы при необходимости можно было к нему вернуться.
3. Деплой — публикация кода на внешнем сервере. До этого он работает на твоём компьютере, а после становится доступен другим пользователям.

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

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

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

• Репозиторий должен быть приватным. В публичном репозитории любой желающий может прочитать код и всё, что в него попало.
• Исключи файл с секретами из репозитория. Ключи, пароли и данные доступа к базе хранят отдельно, обычно в файле .env. Он не должен попадать в репозиторий. Добавь .env в .gitignore, чтобы секреты оставались только у тебя.

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

Что команда /rewind отменяет, а что остаётся?#

Перед каждым собственным изменением Claude Code сохраняет снимок состояния. Командой /rewind или двойным нажатием клавиши Esc можно вернуть файлы и переписку к выбранной точке. Это удобно, если функция сломалась несколько минут назад и нужно вернуться к прежнему состоянию.

Однако /rewind отменяет не все действия:

Anthropic описывает назначение снимков так: это локальный способ отмены, а Git — постоянная история. Снимки дополняют систему контроля версий, но не заменяют её.

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

Как вносить изменения, сохраняя то, что уже работает?#

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

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

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

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

Прежде чем менять код, выполни следующие шаги:

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

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

Внеси минимальную правку — только необходимую для решения моей задачи.

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

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

Чтобы ИИ не нарушал соседнюю логику, он должен учитывать правила проекта. Указывай эти правила и границы задачи в контексте запроса; после этого проверяй результат.

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

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

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

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

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

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

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

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

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

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

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

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

Один из инцидентов со списаниями на 87 500 долларов показывает, насколько опасно раскрытие ключей. В конце концов списания отменили, однако комиссии и потраченное на разбирательство время остались. Попроси ИИ проверить проект:

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

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

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

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

Другая опасная ошибка — проверять права доступа только в браузере. Если решение о показе административной панели принимается в коде страницы, пользователь может его обойти. Права нужно проверять на сервере. База данных должна выдавать информацию только тем, кому разрешён доступ. Для этого включают защиту строк (RLS) во всех таблицах.

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

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

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

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

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

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

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

Где разместить продукт: уровни хостинга#

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

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

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

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

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

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

Частота резервного копирования зависит от допустимого объёма потерь. Если для сервиса с подпиской недопустимо потерять час платёжных записей, интервал должен быть короче часа либо нужны проверенные журналы транзакций и восстановление на момент времени (PITR). Для блога может быть достаточно ежедневной копии. Выбери интервал по допустимой потере данных и отдельно проверь время восстановления сервиса.

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

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

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

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

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

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

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

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

Для мониторинга понадобятся два разных инструмента:

1. Проверка доступности сайта — сервис мониторинга, например UptimeRobot. Он проверяет продукт с заданной периодичностью и уведомляет, если сайт перестаёт отвечать. У сервиса есть бесплатный тариф.
2. Сбор ошибок приложения — инструмент вроде Sentry. Он записывает ошибки, возникающие внутри приложения, и помогает выяснить, где и почему что-то перестало работать.

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

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

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

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

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

Для принятия решения можно использовать такие сроки:

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

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

Сопровождение помогает продукту оставаться полезным для людей. Git, резервные копии и мониторинг — инструменты, которые помогают поддерживать его, пока он нужен пользователям.

Создать продукт с помощью ИИ за вечер — только часть работы. Его нужно поддерживать и защищать по мере роста. Именно это означает взрослый вайб-кодинг.

Для дальнейшей работы — Ailoot.