Vibe coding cleanup: что ломается после демо

Демо работало

Кто-то собрал CRM в Lovable за два выходных. Кто-то другой за год связал четырнадцать процессов в n8n, по одному в неделю. Директор по продажам открыл Claude Code в воскресенье вечером, и к понедельнику появилось приложение, через которое вся команда бронирует доставки. Каждое из них работало в день показа, и от каждого теперь зависит бизнес.

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

Что на самом деле ломается

Ломаются шесть вещей; ниже они в том порядке, в каком их находит осмотр.

Секреты лежат в коде. Сервисный ключ Supabase лежит в клиентской сборке, потому что его туда положил промпт. Ключ OpenAI - в файле, который попал в репозиторий в первый день и с тех пор не менялся. Любой, кто откроет в браузере инструменты разработчика, получит доступ к базе, а любой, кто прочитает репозиторий, - к вашему счёту.

Развёртывание работает только на одном ноутбуке. Система запускается там, где её собрали, с переменными окружения, которые задали один раз и нигде не записали. Когда развернуть её впервые придётся кому-то другому (обычно в ту неделю, когда автор в отпуске), окажется, что никто не знает как.

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

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

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

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

Почему покупать «чистку» - ошибка

У этой работы уже есть название. Наберите в поиске vibe coding cleanup, и на первой странице будут аутсорсинговые студии, которые предлагают ровно это: отрефакторить любой присланный репозиторий по смете. В обсуждении на Hacker News это назвали cleanup as a service. Работу студии понимают верно, а что именно нужно купить - нет.

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

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

Сначала осмотр, потом ремонт

Тот, кто продаёт чистку, подталкивает сразу чинить. Правильнее сначала осмотреть систему по постоянному списку вопросов.

• Где лежат секреты?
• Разворачивается ли система где-нибудь, кроме ноутбука автора?
• Есть ли резервная копия и восстанавливался ли из неё кто-нибудь?
• Пишутся ли логи и получает ли кто-нибудь оповещения?
• От каких API и версий моделей зависит система и когда они меняются?
• Можно ли восстановить систему без автора?

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

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

Сколько стоит, чтобы за систему кто-то отвечал

Работа идёт в три этапа, и заранее известен только первый.

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

Сравнивать нужно со стоимостью пятничного вечера, умноженной на число пятниц, которые остались у бизнеса до ухода того, кто систему собрал, а смета на чистку тут плохой ориентир. Та же арифметика стоит за строкой обслуживания в любом бюджете автоматизации. В нашем сравнении подрядчиков эта строка значится в графе «целиком ваше, включая обслуживание, которое никто не запланировал». Мы написали это про Zapier и Make ещё до того, как кто-то навайбкодил себе CRM, и это по-прежнему верно.

Систем будет больше

В начале 2025 года выражения vibe coding ещё не было. В ноябре Collins назвал его словом года. У компании, где было три IT-системы, скоро будут CRM, восемь внутренних инструментов, четырнадцать процессов, три агента, две базы и проект на Vercel, который директор по продажам написал в воскресенье вечером. Спорить с этим бессмысленно: такие программы дешевле, их собирают люди, которые знают процесс, и их будет становиться больше.

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