Песочницы для AI-агентов и новый Git: как я выпускаю kononov.dev через локальные проверки

За одну неделю октября вышло несколько новостей об одном и том же: AI-агенты пишут код быстрее, чем инфраструктура успевает его проверять и безопасно выпускать. Anthropic заменила Git своей системой, GitLab переписывает серверную часть Git под агентов, Docker и Pulumi показывают песочницы, из которых агент не дотянется до боевой базы. Владельцу бизнеса это важно по простой причине: если ваш разработчик или подрядчик уже пользуется агентом, вопрос «куда агент может дотянуться» касается ваших данных.

Что вышло и у кого

Simon Willison 13 октября разобрал статью Anthropic о собственной системе контроля версий Scion. В мае 2026 года в монорепозиторий компании вливалось около 2500 изменений в день, в сентябре больше 30 000. История главной ветки почти 100 ГБ, порядка 25 миллионов checkout в день только для CI. Систему сделала команда из семи человек, переезд с Git занял пять месяцев.

GitLab 13 октября ответил своей next-gen SCM: протокол Git остаётся, под ним новая архитектура с общим объектным хранилищем. По их данным, один вызов агента в обычном Git может означать 5–10 ГБ трафика и больше 30 секунд подготовки ради одного вопроса. В ранних внутренних тестах они получили до 50 раз быстрее и до 1000 раз меньше трафика, с оговоркой, что это пиковые значения в конкретных условиях. Продукт в закрытой бете.

Через два дня, 15 октября, GitLab описал автоматическое ревью Code Review Flow: оно запускается как задание CI на ваших же раннерах, стоит $0,25 за ревью и включается сразу на проект, группу или весь инстанс. В планах право агента одобрять изменения или просить доработку.

Docker 16 октября пересказал опрос Stack Overflow 2026 года, больше 30 000 респондентов из 169 стран. Только 7 % разработчиков доверяют результату AI в важных рабочих решениях, 48 % доверяют, только если могут проверить сами. На этом фоне Docker запустил Cloud Sandboxes и спецификацию Sandbox Kit, которую обещает передать в CNCF.

Pulumi 21 октября опубликовал запись воркшопа, и там самая полезная история. В апреле агент компании PocketOS на рутинной задаче в staging удалил боевой том данных за 9 секунд: взял API-токен из постороннего файла и предположил, что удаление ограничено staging. Данные хостинг восстановил через два дня. Основатель компании написал, что системный промпт агенту только советует. Поэтому в воркшопе агент Pulumi Neo работал в микровиртуалке Docker Sandbox, видел только разрешённые файлы и хосты, а настоящий токен подставлял прокси на выходе.

Vercel 19 октября показал durable-harness: журнал каждого шага агента, чтобы после сбоя задача продолжалась с места обрыва. Мне там важна одна деталь: каждый инструмент агента помечен, можно ли его повторять после обрыва. Чтение файла повторять можно, возврат денег клиенту нет.

Что это значит для компании с одним сервером

Возьмём сервисную компанию, где подрядчик правит сайт и интеграцию с CRM. Он подключил агента к репозиторию, а в репозитории лежит файл с токеном от CRM и доступом к базе. Агент получает задачу «почисти тестовые заявки», находит токен и чистит заявки там, куда дотянулся, как агент PocketOS, только в меньшем масштабе.

Вывод из новостей простой. Ограничение должно стоять там, где агент не может его обсудить: в правах токена и в порядке выпуска. Инструкцию в промпте агент PocketOS прочитал и всё равно удалил том.

Как это устроено у меня

Сайт kononov.dev работает на Next.js, Node.js 24 и SQLite в Docker, на общем сервере с 2 ГБ памяти за Nginx, рядом с сервисом «Кофе вместе». AI ускорил мою разработку в несколько раз, но архитектуру и ключевые решения я определяю сам, а результат инструментов проверяю. Для кода это выглядит так: изменение проходит локальный конвейер проверок в Docker, тесты и сборку, и только после этого попадает на сервер. На сервере старый экземпляр останавливается до запуска нового, а если сборке не хватает памяти, образ собирается вне сервера и загружается готовым.

У PDR-компании в США, где я с 2021 года технический партнёр, вопросы безопасности идут ко мне: у системы несколько контуров защиты и резервных копий, а с 2022 года, когда появился свой сервер на Debian в Google Cloud, серьёзных сбоев с восстановлением не было. Песочницы для агентов я бы проверил: задача та же, что у PocketOS, у меня она сейчас решается правами и порядком выпуска.

Что я бы сделал

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

Запускать агента в отдельном контейнере или песочнице без сетевого доступа к боевому серверу. Docker Sandboxes из новости один из вариантов, обычный контейнер с ограниченной сетью тоже подходит.

Пропускать изменения агента через тот же конвейер проверок, что и изменения человека: тесты и сборку.

Необратимые действия оставить человеку: выпуск на сервер и удаление данных. Это та самая пометка «нельзя повторять» из durable-harness, только на уровне процесса.

Держать резервные копии с проверенным восстановлением. PocketOS спасло то, что хостинг смог поднять данные через два дня. Я предпочитаю держать восстановление у себя.

Связанные материалы

О том, как выполнять длительные задачи вне запроса и контролировать повторы, я писал в статье Воркеры: фоновые задачи и повторные попытки. Направление: инфраструктура, которую можно выпускать и восстанавливать, живой пример в кейсе о техническом партнёрстве с PDR-компанией. Из других обзоров: что я разрешаю AI-агенту на боевом сервере и как я делю работу с агентом. Раньше я разбирал моки API и отдельные базы для проверки релиза и preview-окружения без доступа к рабочим данным. Если ваш подрядчик уже работает с агентом и вы не знаете, куда тот может дотянуться, расскажите, как устроен выпуск сейчас. Обсудить задачу.