Вайб-кодинг: почему без понимания инфраструктуры не обойтись

Вайб-кодинг: почему без понимания инфраструктуры не обойтись

Вы когда-нибудь коммитили секреты в репозиторий, потому что AI-инструмент так предложил, а код работал? Это классическая ловушка вайб-кодинга: код работает, но система — нет. В этой статье разберём, почему за красивым приложением скрывается инфраструктура, которую AI не видит, и как это исправлять.

Что такое вайб-кодинг и в чём его опасность

Термин «вайб-кодинг» ввёл Андрей Карпаты в начале 2025 года: отдаться потоку, не смотреть на код, позволить ему расти за пределы понимания. Он описывал одноразовые проекты выходного дня. Но интернет запомнил «забудьте, что код существует» и тихо апгрейдил до «забудьте, что система существует». А это не одно и то же. Код можно игнорировать, систему — нет, потому что система — это то, что реально работает.

Что AI не видит: примеры из практики

Каждый пример ниже — реальное предложение AI-инструмента, которое пришлось переопределять. Не потому, что я пишу код лучше, а потому что я уже стоял на том слое, который модель не видит.

Выбор операционной системы

AI предложил Windows для security-приложения. Технически норм, но по стоимости и ресурсам — нет: лицензионный Windows Server против бесплатного Ubuntu делает ту же работу легче. У модели нет понятия счёта, потому что счёт живёт слоем ниже кода.

Выбор базы данных

AI потянулся к MySQL. Технически тоже норм. Но я буду эксплуатировать это долго и в масштабе, а мой опыт — в Postgres, не в MySQL. Модель не знает, кто владеет системой в 2 часа ночи через год. Выбор движка, который я могу уверенно вести под нагрузкой — операционное решение, а операции невидимы из кода приложения.

Аутентификация и безопасность

AI настроил auth и остановился на «логин работает». Работает — это лёгкие 20%. Защищённая версия включает единый вход через Microsoft Entra ID (бывший Azure AD) с Conditional Access — так «аутентифицирован» означает доверенное устройство, разрешённое местоположение, правильные условия, а не просто любой с валидным токеном. Conditional Access не обнаружить, вайб-кодя форму логина.

Сеть и открытые порты

В ранних версиях уверенный ход был всегда один: открыть порт.

# что заставляет соединение работать
ufw allow 22
# SSH, открыт всему интернету

# что должно было быть
ufw allow from 10.0.5.0/24 to any port 22
# ограничено управляющей сетью

Оба варианта соединяются. Но только один безопасен, и разница невидима из слоя приложения — она живёт в сети, которую модель считает чужой проблемой.

Как не коммитить секреты: правильный подход

Это возвращает нас к секретам, которые AI пытался хардкодить. Исправление несложное, но это слой, который модель не достигает сама:

import os

DATABASE_URL = os.environ["DATABASE_URL"]
API_KEY = os.environ["API_KEY"]

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

Почему ничто не изолировано

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

Почему я спорю с машиной

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

Это меняет и то, как я начинаю. Я не открываю «сделай мне X» — это порождает демо, которое взрывается в продакшене. Я трачу полчаса, обсуждая проблему сначала: ограничения, компромиссы, где зарыты тела. Затем прошу модель написать лучший промпт для того, что мы только что выработали, и передаю это кодинг-агенту. Он пишет лучшую спецификацию для себя, чем я мог бы на холодную, но только после того, как человек сделал мышление, которое спецификация должна отражать. Тридцатиминутный разговор — не накладные расходы. Это то, что удерживает следующие два часа от превращения в уборку.

Практический вывод: что делать прямо сейчас

1. Не доверяйте AI выбор инфраструктуры. Всегда проверяйте, какую ОС, БД, сетевые настройки он предлагает — и выбирайте то, что вы сами сможете поддерживать.
2. Никогда не хардкодьте секреты. Используйте переменные окружения или хранилища секретов. Запретите коммиты с паролями через pre-commit хуки.
3. Обсуждайте задачу с AI перед тем, как просить код. Потратьте 30 минут на описание контекста и ограничений — это сэкономит часы переделок.
4. Изучайте инфраструктуру. Даже если вы джун, понимание сети, базы данных и деплоя превратит вайб-кодинг из опасной игрушки в мощный инструмент.

Разделительная линия — не талант и не то, сколько кода вы пишете. Это понимание того, на чём ваш код стоит. Всё остальное — просто вайбы, а вайбы не держат вес. Какое переопределение вам приходится делать постоянно — то, что модель ошибается в вашем стеке каждый раз?