Vibe coding: когда магия заканчивается на проде

Буду откровенен: vibe coding — это мощно. Описываешь задачу, смотришь как агент пишет код, тесты зеленеют, релиз выкатывается. Ощущение, будто ты волшебник. Ровно до того момента, пока не станешь им.

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

Код был корректным. Он решал задачу точно по спецификации. Просто он предполагал бесконечную память и бесконечные ресурсы — потому что в промпте ничего другого не было.

Неявные допущения: тихий убийца

Вот что никто не обсуждает на конференциях. Когда пишешь код сам, ты везде носишь с собой ментальную модель ограничений. Ты знаешь, что на ноутбуке 16 гигов оперативки. Знаешь лимиты на файловые дескрипторы на продакшене. Понимаешь, что CSV на 400 гигов нельзя загрузить целиком в память.

А когда код пишет AI, этих ограничений не существует. AI видит «загрузи файл, отсортируй, запиши результат» и думает: отлично, загружу целиком. На тестах всё работает. Тестовый файл весит 50 килобайт.

Привычные code review тоже не спасут. Подозрительные строки выглядят совершенно нормально. Ничто не вызывает красных флагов при поиске логических ошибок — потому что их нет. Баг не в логике; он в невидимой коробке, которую логика использовала.

А что если компилятор знал бы больше?

Тут начинается самое интересное. Разработчик Nicolas Grislain экспериментирует с провокационной идеей: а что если ограничения ресурсов были бы типами, а не комментариями?

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

Это не абстрактная теория. Эксперимент использует Lean 4 — да, тот самый Lean, который сейчас штурмует мир формальной математики — чтобы вшить бюджеты ресурсов прямо в типы функций. Компилятор становится аудитором ресурсов, автоматически проверяющим, что код укладывается в лимиты, ещё до первого запуска.

Как это работает

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

Открыл файл — сигнатура типа меняется: вошёл в функцию с N открытыми файлами, вышел с N+1. Закрыл — вернулся к N. Компилятор отслеживает это на каждом шаге, и ты физически не можешь скомпилировать код, который открывает файл без закрытия или превышает лимит.

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

Магия случается на точке входа: программа должна начинать с нуля используемых ресурсов и заканчивать нулём. Ты не можешь течь handles или refs. Не можешь превышать капы. Компилятор просто не даст.

Почему это важно для vibe coding

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

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

Реализация работает не просто «по счастливой случайности» — она доказуемо укладывается в бюджет.

Практическая сторона

Будем честны: это пока не production-инструмент для большинства команд. Подход с Lean 4 требует серьёзной подготовки, и мышление в терминах индексированных типов добавляет когнитивную нагрузку. Но базовая идея ценна независимо от реализации.

Когда занимаешься vibe coding, ты доверяешь AI не только написание кода, но и ментальную модель системы. Твой AI-ассистент не знает твоё production-окружение. Не знает, что в контейнере 512 мегабайт RAM. Не знает, что ядро Linux ограничивает файловые дескрипторы до 1024.

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

1. Будь конкретным в промптах — «Входной файл может содержать до 10 миллионов строк» лучше, чем «эффективно обрабатывай большие файлы»

2. Тестируй на данных продакшен-размера — Если тренировочные данные крошечные, AI не увидит паттернов работы с ресурсами

3. Используй bounded APIs — Архитектура, которая естественно ограничивает потребление (connection pools, стриминг вместо загрузки) сложнее для злоупотребления

4. Следи за инструментами с осознанием ресурсов — Индустрия начинает исследовать способы делать ограничения явными в AI-генерируемом коде

Итог

Грязный секрет vibe coding не в том, что он пишет багованный код — а в том, что он пишет код, корректный внутри невидимого пространства ограничений. Это пространство включает твой ноутбук, тестовое окружение и, может быть, первую тысячу пользователей. Но точно не включает «продакшен при масштабе».

Ресурсные системы типов вроде этого эксперимента с Lean 4 указывают на будущее, где «корректный» значит больше, чем «логически верный». Это значит «доказано укладывается в реально существующие границы».

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

Твой будущий дежурный по on-call скажет спасибо.