AI собрал мне сервис за 4 часа. Потом я два дня занимался тем, что раньше называлось DevOps.

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

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

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

Возьмем типичный сценарий. Нужно собрать небольшой внутренний сервис:

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

С AI-инструментами первая часть выглядит почти смешно.

Примерный тайминг:

Итого имеем примерно 4 часа до состояния рабочего на локале сервиса.

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

А потом начинается вторая часть. Следите за цифрами:

Я конечно сделал грубую оценку, но тем не менее.

И после всех этих манипуляций наш сервис (который мы планировали сделать типа за один вечер) превращается в сервис за два дня (которые уйдут на инфраструктуру).

И это не потому что ИИ такой плохой. Наоборот, он то свою часть сделал отлично. Просто продукт - это не только код.

Фраза «у меня работает локально» в эпоху вайб-кодинга стала еще опаснее. Раньше она хотя бы звучала как оправдание разработчика. Сейчас она звучит как победа.

Проект открылся. Бот отвечает. API возвращает данные. Таблица заполняется. Интерфейс не разваливается. AI даже написал README и сгенерировал Dockerfile.

Поднимаем ручки и радуемся. Все готово.

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

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

Именно в этот момент вайб-кодинг впервые сталкивается с DevOps.

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

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

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

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

ИИ ускоряет создание сложности. DevOps нужен, чтобы эту сложность удержать.

Для большинства таких сервисов не нужен Kubernetes. Не нужен сложный cloud-native контур. Не нужен отдельный SRE. Но нужен минимальный эксплуатационный слой.

Я бы описал его так:

Да звучит скучновато. Но именно это отличает игрушку от настоящего сервиса или что вы там создали.

Казалось бы, зачем в 2026 году вообще думать про VPS, если можно выложить проект на Vercel, Railway, Render, Fly.io, Supabase или Firebase?

И часто это хороший выбор. Почему бы и нет.

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

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

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

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

VPS в этом смысле скучнее, но честнее. Ты получаешь сервер и сам решаешь, что на нем живет.

При выборе VPS я бы смотрел не только на цену, а на практичные вещи: быстрый диск, запас по CPU, понятный трафик, локации серверов, поддержку и возможность нормально администрировать систему. Например, под такой сценарий я нашел для себя неплохой сервис PSB Hosting. Это мой личный опыт. У них хорошие отзывы, есть VPS в разных локациях (США и Европа), NVMe, root-доступ, безлимитный трафик и Hi-CPU-конфигурации для задач, если вам важны вычислительные ресурсы.

Для меня это не замена Vercel, Railway или Supabase. Просто я использую их под другой класс задач. Managed-платформы удобны, когда хочется быстрее выложить приложение и не думать о сервере. VPS удобен, когда вокруг приложения появляется своя маленькая инфраструктура, и ее нужно держать под контролем. Вот и все.

Если сравнивать по сценариям, получается примерно так:

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

1. Где живут данные? Если база исчезнет вместе с контейнером, это не продакшен.

2. Как сервис перезапускается? После падения процесса, reboot сервера или обновления.

3. Где логи? Можно ли понять, что сломалось, без гадания?

4. Есть ли бэкап? И главное, а проверялось ли восстановление?

5. Как обновлять код? Есть ли понятный деплой или все держится на ручных командах?

6. Где секреты? Они точно не в GitHub?

7. Что открыто наружу? Только 80/443 и SSH? Или еще случайно Postgres всему интернету?

8. Что будет ночью? Если сервис упадет в условные 03:20, кто об этом узнает?

9. Что будет после ошибки AI? Если модель предложила фикс, который ломает миграции, есть ли откат?

10. Сколько ручных действий нужно, чтобы поднять проект с нуля? Если ответ «я примерно помню», это плохой ответ.

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

Вайб-кодинг хорош для старта. Но продукт начинается после него.

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

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

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

AI помогает быстрее дойти до первой рабочей версии.

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

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

Главный навык - превращать этот код в систему, которая живет!