Я Артем Гамбицкий, сооснователь маркетплейса «Флаувау».
Четыре месяца назад мы разрешили коллегам без инженерного бэкграунда выкатывать в прод приложения, которые им пишет ИИ-агент. После этого получили более 260 проектов от 150 человек, и весь этот код не читал ни один программист.
Да, мы могли бы вообще запретить использование ИИ и оставить разработку только профессионалам. Но для нас этот путь был бы заведомо тупиковым. Отбирать инструмент, который уже помогает людям делать свою работу, глупо, а пресекать инициативу вообще не соответствует нашим принципам. Логичнее было не бороться с реальностью, а дать процессу безопасные рельсы и понятные правила игры.
Мы ждали, что вайбкодеры будут ронять прод, но проблемы пришли с другой стороны. Например, сборки у всех разом начали падать, когда мы приблизились к 200 раннерам на одной машине и исчерпали квоту ключей ядра. А во время планового обновления сеть повисла на сотнях docker-интерфейсов, оставив всю машину без DNS.
Дальше о том, как устроена наша песочница, что мы узнали за эти четыре месяца, где ошибались и что из этого получилось.
Зачем это вообще
Вайбкодинг в компании начался стихийно и хаотично. Кто-то собирал себе приложения и лендинги, кто-то автоматизировал рутину, кто-то внедрял созданные с нейросетью интерфейсы в процессы своего отдела. Проекты жили на ноутбуках и сомнительных виртуалках, о которых знал только их автор.
Разработка такие локальные запросы не берет и правильно делает: инструмент для экономии времени одного отдела в приоритизации проигрывает любой задаче, влияющей на выручку.
А потребность все равно остается.
С гипотезами та же история: путь от идеи до MVP через бэклог занимает недели, а прототип, собранный продакт-менеджером за пару часов, можно показать команде сразу ссылкой. Это экономит массу времени на проверке этих теорий.
Запрещать вайбкодинг не хотелось, а оставлять как есть было опасно. Вопрос свелся к классическому «запретить нельзя возглавить». Так и появилась Продуктовая песочница Флаувау.
Как все устроено
Песочница живет отдельно от инфраструктуры маркетплейса: свои машины, свои домены, свой деплой. Основной код платформы проекты не трогают. Автор проекта создает репозиторий из нашего шаблона, в котором уже лежат все правила для агента и текстов, дизайн-система, защитные хуки. Дальше ИИ-агент уточняет требования, пишет спецификацию, план реализации, логику и тесты, отдает результат на ревью субагенту и показывает его на локальном превью. После этого self-hosted-раннер собирает образ, наш Deploy API поднимает контейнер, и через минуту приложение доступно на своем поддомене внутри корпоративного VPN.
Под капотом ничего экзотического: Traefik, Deploy API на FastAPI, отдельный docker-agent, SQLite, cron и systemd-таймеры. Все это поднято на виртуалке с 8 vCPU и 32 ГБ памяти за 20 тыс. рублей в месяц.
Контейнер каждого проекта получает половину ядра и 512 МБ памяти. На типовом стеке шаблона (Node 24, Fastify, better-sqlite3) такой контейнер держит 500–1 000 запросов в секунду: около 500 RPS на API, который читает из SQLite, и около 1 000 RPS, если это статика SPA. Но в реальности нагрузки куда скромнее. Один из наших самых посещаемых проектов собирает 5–10 тыс. визитов ежедневно и в пике держит около 60 RPS. До того, как он съест все лимиты, ему еще очень далеко.
Две сотни работающих контейнеров занимают 9–10 ГБ памяти, это в среднем по 50 МБ. Поэтому виртуалка вытянет до 500 подобных проектов.
Такие цифры — заслуга в том числе и выбранного стека. Преднастроенный агент по умолчанию берет легкие инструменты: Fastify вместо NestJS, FastAPI вместо Django, SQLite вместо отдельного Postgres, легкий фронт вместо серверного рендеринга на Next.js. Тяжелый фреймворк он возьмет, только если автор настаивает и обоснует, для чего ему это нужно.
Код всех проектов ежедневно зеркалируется в отдельный приватный репозиторий, а данные всех проектов — в S3-бакет. Если автор удалит репозиторий или уйдет из компании вместе с аккаунтом, его детище останется.
К внутренним корпоративным данным по умолчанию доступа нет. Но если приложению нужно, это отдельно согласовывается через отдел ИБ: под проект создается учетная запись, которая дает права строго на чтение конкретного списка таблиц из запрошенной базы Флаувау.
Run, Forest, run!
Песочница доступна только под корпоративным VPN, входящих соединений извне она не принимает. Облачный раннер до нее не достучится, поэтому сборка идет self-hosted-раннером прямо на виртуалке. Код проектов в основном лежит в личных аккаунтах авторов, а там раннер регистрируется только на уровне репозитория. Как итог — один раннер на один проект. С этим решением мы и запустили песочницу четыре месяца назад.
Пока проекты исчислялись десятками, проблем не было. К концу августа раннеров стало 165, и мы увидели: две трети занятой памяти и половину диска держал их флот. Огромный кусок ресурсов уходил на процессы, которые просто ждали работы!
Решение нашлось в open source: chimera — переписанная с нуля на Rust реализация протокола GitHub Actions. Один демон держит все регистрации машины как задачи внутри своего процесса: каждая долго опрашивает брокер, а воркеры появляются, только когда приходит джоба. Мы форкнули этот раннер, дошлифовали под себя и перевели на него все проекты.
После переезда две сотни раннеров теперь живут в одном процессе на 100 МБ против прежних 13 ГБ.
Виртуальные потолки
Вся песочница обвешана системами мониторинга и алертами. Если что-то идет не так, то диск, память и процессор предупреждают об этом заранее. Только вот в процессе работы часть выстроенных потолков подкинула нам не самые приятные сюрпризы.
Например, мы не ожидали такого бурного роста количества проектов. За четыре месяца существования песочницы сотрудники Флаувау зарегистрировали 262 проекта и провели порядка 5000 деплоев, и эта цифра продолжала расти в геометрической прогрессии.
На старте мы ограничили пул docker-сетей 256 адресами — думали, что до таких цифр на одной машине вряд ли доживем. Это заблуждение оказалось очень даже приятным. Обнаружив приближающийся лимит, мы добавили второй пул на 2048 сетей. По дороге узнали, что порядок пулов в daemon.json ни на что не влияет: docker сортирует их по базовому адресу. Теперь ждем, пока закончится первый пул.
Еще веселее получилось с квотой ключей ядра Linux. По умолчанию у каждого пользователя их всего 200 в keyring, а все раннеры работали от одной учетки и держали по ключу.
На отметке 198 из 200 сборки начали падать с unable to create session key: disk quota exceeded, а агенты пользователей, увидев слово disk, предлагали почистить диск. Он здесь был ни при чем. Мы сначала подняли квоту, а потом переехали на chimera, где на весь флот один системный юнит вместо двухсот.
С инфраструктурными лимитами мы разобрались, но оставался главный вопрос — безопасность самого кода, который пишут нейросети…
Агенты и безопасность
Безопасность в песочнице строится вокруг непривычной модели угроз: злоумышленника в ней почти нет. Есть честный коллега, который хочет сделать хорошо, и нейросеть, которая иногда галлюцинирует, выполняет rm-rf не в той директории или идет читать .env, «чтобы было удобнее». Поэтому сделать песочницу безопасной было ключевой задачей: дать людям свободу экспериментов, но исключить даже случайный вред инфраструктуре. Мы выстроили слои защиты так: чем глубже, тем меньше у агента возможностей что-то изменить.
Первый слой — инструкции. Короткий AGENTS.md в шаблоне работает как оглавление «если делаю X → читаю Y» и 14 инвариантов, которые нарушать нельзя. Это базовые ориентиры для агента: как именно решать задачу и какие границы переходить нельзя. Детальные контракты (правила безопасности, дизайн-система, редполитика) он подгружает, когда до них доходит дело, а не держит в контексте постоянно.
Второй слой — хуки. На PreToolUse висят шесть блокирующих: destructive-command, git-destructive, git-no-verify, command-injection, secret-leak и working-directory. На PostToolUse висит детектор утечки API-ключей. Пять из семи мы взяли из репозитория AnastasiyaW/claude-code-config и доработали так, чтобы одни и те же скрипты понимали разные агенты. Благодаря этому он не сможет выйти из папки текущего проекта и попытаться удалить что-то по соседству. Ключевая деталь, почему обход этих правил не сработает «в лоб», заключается в том, что хук запускается как соседний процесс, а не как потомок проверяемой команды. Агент может сколько угодно прописывать в свое окружение такие разрешения, как CLAUDE_ALLOW_X=1, — скрипт этой переменной просто не увидит.
Но хуки живут в репозитории проекта, и нейросеть при желании может их отредактировать. Поэтому для нас этот уровень — только базовая защита от случайностей.
Третий слой — сервер. Автор полностью владеет своим Dockerfile, но не тем, как запускается образ. Параметры старта контейнера сервер подставляет сам — они читаются из внутренних правил платформы, а не приходят из вебхука. Задать собственные лимиты или получить root-права пользователь не может. Новая версия контейнера сначала запускается рядом со старой, проходит проверку и только потом получает трафик.
Четвертый слой — регулярная проверка кода. Все проекты песочницы подключены к нашей общей security-консоли. ИИ регулярно анализирует сгенерированный код на уязвимости и, если находит, готовит полноценный промпт для агента. Автору остается только вставить его в новую сессию. Человек, который не читает код, получает исправление уязвимости, так и не заглянув в исходники.
Такой многослойный контроль позволяет нам не переживать за сохранность инфраструктуры. Ну, или как минимум переживать чуть меньше.
Техническая поддержка
Несмотря на такой поток проектов от коллег без технического бэкграунда, люди в поддержке песочницы не перегружены запросами о помощи. И во многом дело в самом подходе: мы изначально сделали так, чтобы человек подключался только в крайних случаях.
Первой линией выступает агент автора. Он обучен всем типовым проблемам, с которыми когда-либо сталкивались другие пользователи песочницы. Более того, он умеет забирать и читать хвост логов своего контейнера (через API, запрос подписан HMAC, секреты в ответе вырезаются). Поэтому большую часть проблем агент чинит сам.
Если ИИ сдается, он просит пользователя написать в канал поддержки. Там отвечает общий бот песочницы, который находится в самой гуще событий на виртуалке. Он работает под отдельным пользователем с урезанными правами и через персональный сокет с собственным API. Смотрит состояние контейнеров, логи и историю деплоев нужного проекта или их связки. Дальше бот отвечает, если разобрался в проблеме, либо эскалирует задачу человеку.
По завершении каждого дня бот автоматически обучается на тредах с решенными проблемами пользователей, в которые призывался сотрудник поддержки, чтобы в будущем самостоятельно подхватить этот вопрос. А еще он раз в неделю выбирает самый медленный проект и формирует автору письмо с рекомендациями по его оптимизации. Судя по реакции, авторы довольно оперативно и дружелюбно реагируют на подобные рассылки.
Что строят и что выживает
Четыре месяца показали: песочница работает именно так, как мы и задумывали. В каталоге созданных проектов есть продуктовые MVP, инструменты для автоматизации рутины и совсем случайные, казалось бы, вещи. Но именно такие спонтанные эксперименты и помогают людям впервые вживую пощупать вайбкодинг без страха что-то сломать или уронить.
Задачи при этом решают абсолютно разные. Кто-то собирает дашборд для офлайн-магазина «Флаувау», чтобы в реальном времени следить за динамикой категорий и выполнением плана. И это без очередей к аналитикам. Другие делают инструмент для анализа конкурентов на новых рынках, третьи — единое окно заявок для закупок и снабжения склада.
При этом далеко не всем сервисам суждено жить месяцами. Проект могут собрать под проверку одной шальной гипотезы, короткую акцию или двухнедельный спринт, а потом спокойно выключить. Прототип, который прожил неделю, — это не провал. Провал, когда он год ждет своей очереди в бэклоге и умирает там.
Что получила компания
Главное изменение не техническое. Мы ушли от хаоса на личных ноутбуках и безымянных виртуалках к управляемой системе. Все проекты собраны в нашем контуре, стандартизированы, регулярно проверяются на безопасность, а доступы выдаются системно, а не по памяти.
Сервис в песочнице не обязан оставаться проектом одного человека. Владелец может позвать любого коллегу в соавторы: тот получает доступ к репозиторию, работает со своим агентом и деплоит наравне с автором. У трети пользователей песочницы в активе, кроме своего проекта, еще и участие в других. Так мы научились собирать вайбкодеров в стаи, и скоро проведем на базе песочницы первый внутренний продуктовый хакатон Флаувау.
Вайбкодинг не отменил инженерию. Он перенес ее из кода вайбкодера в платформу, на которой этот код живет.
А как вы контролируете этот процесс в вашей компании? Делитесь в комментариях!
Автор: Gambik
