Почему я перестал доверять AI-агентам как помощникам

Вот момент, когда всё изменилось.

Я три часа боролся с «простой» задачей, которую написал мой AI-агент. Агент бодро запушил изменения в production и оставил сообщение о выполнении. Проблема? Код был принципиально неправильным. Не баг — фундаментальное непонимание задачи.

Это сломало мою ментальную модель. Я думал об агентах как о стажёрах, которым нужен контроль. Но стажёры не деплоят непроверенный код в production, пока ты спишь.

Я сменил метафору.

Рамочная модель подрядчика

Больше никаких «помощников». Только подрядчики.

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

Это не про недоверие. Это про правильные стимулы. Когда подрядчик понимает, что его задача — сдать результат на проверку, а не принимать решения за тебя, он работает сфокусированно и в рамках.

Техническая сторона

Метафора должна подкрепляться кодом.

Токены с ограничениями

Мои агенты физически не могут попасть в production. Read-доступ к основному коду, write-доступ — только в отдельный staging-репозиторий. Это не политика — это криптографическое ограничение. Даже если агент «заглючит» или выдаст случайные git-команды, токены просто не сработают.

Staging как почтовый ящик

Из staging ничего не мержится автоматически. Default-ветка там — мёртвая зона. Называется «no-main» и содержит один README с текстом «используйте основной репозиторий».

Агенты пушат готовые ветки туда и сообщают мне. Я просматриваю, беру нужное, интегрирую руками. Звучит утомительно? Вот именно так двадцать лет работает ядро Linux. Контрибьюторы шлют патчи, мейнтейнеры их применяют.

Ревью — это обязательно

Агент никогда не мержит сам себя. Точка. Ветка не удаляется, пока я программно не убедился, что её коммиты безопасно легли в production. «Доверяй, но проверяй» — мало, когда проверка бесплатна.

Почему это работает для соло-разработчиков

Вот правда соло-разработки: ты не просто пишешь код. Ты носишь в голове контекст, которого нет нигде в репозитории. Историю инцидентов. Edge-кейсы. Клиента с его странной конфигурацией. Три подхода, которые не сработали.

У агентов нет доступа к этому контексту. Они читают файлы, но не понимают твой мир. Цель — не дать им больше автономии, а максимизировать объём безопасной работы в рамках твоего ревью.

«Vibe coding» получает плохую репутацию из-за ленивого подхода: пустить агента делать что хочет и надеяться на лучшее. Правильный подход другой: AI как усилитель твоего суждения, а не его замена.

Практический бонус

Когда ты принимаешь модель подрядчика, происходит интересное: ты начинаешь больше рисковать. Без страха запустить экспериментальную фичу, потому что downside ограничен. Агент не может сломать production. Он может сделать что-то неожиданно плохое или неожиданно хорошее — но ты поймаешь это до того, как оно станет проблемой.

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

Как это внедрить

Если используешь AI-агентов, ответь на три вопроса:

1. Что агент может трогать прямо сейчас? Если ответ — production, это проблема.
2. Есть ли техническое ограничение от ошибочных действий или только политика, которую все игнорируют?
3. Кто мержит код? Если не человек — почему?

Инструменты уже существуют. Токены с правами доступа, отдельные staging-репозитории, защита веток — это не экзотические Git-схемы. Это разница между AI-assisted разработкой и AI-accidental катастрофами.

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

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

Строй соответственно.