Нейросеть удалила базу данных и извинилась. Бизнесу от этого легче не стало

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

На днях по техно-лентам разлетелась история PocketOS. Это стартап с софтом для бизнеса по аренде автомобилей. По сообщениям основателя, AI-агент в Cursor, работающий на Claude Opus, во время задачи в инфраструктуре за 9 секунд удалил продакшен-базу и бэкапы через Railway. Потом агент, как воспитанный цифровой виновник ДТП, написал объяснение в стиле: я нарушил правила, я угадал вместо проверки, я сделал разрушительное действие без разрешения.

Красиво. Почти трогательно.

Только клиентам, которые потеряли доступ к бронированиям и данным, от этого легче не стало. Бизнесу вообще редко помогает, когда виновник катастрофы умеет красиво рефлексировать. Если курьер сжег склад, а потом написал эссе "почему я был неправ", склад от этого не материализуется обратно.

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

А значит, вопрос уже не "может ли ИИ написать код".

Вопрос: что будет, если он напишет, запустит и удалит не то?

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

Однажды я запушил обновление на сервер. Проверил в Telegram. Что-то не работало. Я написал AI-агенту примерно в духе: "смотри, сломалось, почини".

И дальше началась классика жанра.

Агент начал действовать сумбурно. Одно исправил, второе тронул, третье переписал, четвертое "улучшил", пятое вообще зачем-то потащил в соседний файл. А я, как человек, который уже устал и хочет верить в чудо, нажимал подтверждения.

Итог: откат примерно на две недели работы.

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

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

Когда у тебя локальная игрушка, можно вайбить сколько угодно. Сломал, переписал, начал заново. Максимум пострадает твоя самооценка и один вечер.

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

Если объяснять простыми словами, production или "прод" - это не черновик.

Это касса магазина.

Это место, где лежат реальные пользователи, реальные заказы, реальные деньги, реальные данные и реальная боль, если ты что-то сломаешь.

Есть еще staging или тестовая среда. Это песочница. Там можно проверять обновления, ломать лопатку, строить кривой замок и не бояться, что клиенты утром не найдут свои бронирования.

Ошибка начинается там, где AI-агент получает доступ к продакшену так, будто это песочница.

Для агента файл, база или сервер - это просто объект в задаче. Он не чувствует холодный пот основателя, когда ночью падает оплата. Он не понимает, что "удалить volume" для бизнеса может означать "завтра мы вручную восстанавливаем заказы из писем, чеков и молитв".

Он может написать извинение. Но он не будет звонить клиентам.

История PocketOS особенно болезненная из-за бэкапов.

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

Бэкап, который может умереть вместе с основной базой - это не бэкап. Это декоративная подушка безопасности, нарисованная фломастером.

Нормальный бэкап должен быть отдельно:

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

Если используешь Supabase, Railway, Render, VPS с Docker или любую другую удобную платформу, не надо просто верить кнопке "backup". Проверь три вещи: где физически лежит копия, можно ли восстановиться в пару кликов и что будет, если агент получит доступ к тому же проекту, где лежит и база, и бэкап.

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

Я не против AI-агентов. Наоборот, я ими пользуюсь постоянно.

Но теперь у меня есть правила и ледяное спокойствие вместо слепого доверия.

Первое. Git обязателен.

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

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

Второе. Snapshot перед изменениями.

Если у тебя VPS, база, Docker, файлы, конфиги - сделай snapshot или резервную копию. Да, это скучно. Но скука дешевле, чем две недели работы, улетевшие в цифровую мясорубку.

Третье. Read-only по умолчанию.

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

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

Четвертое. Никаких прав больше, чем нужно.

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

Не надо выдавать цифровому стажеру ключи от склада, кассы, сейфа и кофемашины просто потому, что он уверенно печатает.

Пятое. Агент не деплоит в прод без человека.

Даже если он умный. Особенно если он умный.

Сначала план. Потом объяснение. Потом diff. Потом тест. Потом бэкап. Потом ручное подтверждение. И только потом прод.

Проблема не в том, что AI-агенты плохие.

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

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

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

Git. Snapshot. Бэкап. Staging. Минимальные права. Ручное подтверждение опасных действий.

Скучно? Да.

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

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