Полный доступ нейросети — вопрос отката, а не смелости

В ролике я сказал, что убрал у нейросети кнопку «спросить разрешение», и что дело не в смелости, а в откате. Здесь — как эта сетка устроена и в каком порядке её ставить.

Почему разрешения не защищают

Разрешения выглядят как защита. На деле они защищают ровно до сотого окна.

Первые десять раз ты читаешь, что именно тебя спрашивают. Дальше начинается кликанье «да» на автомате — потому что двадцать вопросов подряд были безобидные, и двадцать первый ты пропускаешь не глядя. Это не разгильдяйство, это усталость от подтверждений, и она приходит ко всем.

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

Настоящая защита работает иначе: не «не дать сломать», а «сделать поломку дешёвой». Как только любое действие отменяется одной командой, вопрос «а вдруг испортит» просто перестаёт стоять. Не потому что не испортит. А потому что цена испорченного упала до пары секунд.

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

Узел 1. Вся система под контролем версий

Первое и главное. Папка проекта — это не просто папка, это репозиторий: каждое состояние зафиксировано, к любому можно вернуться.

Что это даёт на практике: нейросеть переписала двадцать файлов, результат тебе не нравится — одна команда, и всё как было пять минут назад. Не «восстанавливать по памяти», а именно как было.

Как поставить:

• в папке проекта выполнить git init — один раз
• сказать Claude, чтобы фиксировал изменения после каждой законченной задачи
• перед крупной затеей делать отдельную ветку, чтобы основная оставалась нетронутой

Без этого узла остальные четыре не имеют смысла. Это фундамент, и он ставится за пять минут.

Узел 2. Бэкап уезжает сам

Локальный репозиторий спасает от нейросети, но не спасает от диска. Второй узел — копия за пределами машины.

У меня система уходит в приватный репозиторий по расписанию, без моего участия. Не «когда вспомню», а по таймеру — потому что бэкап, который надо не забыть сделать, это не бэкап.

Что стоит вынести за скобки: то, где лежат открытые развилки и чувствительное. У меня в облако едет не всё — часть папок сознательно остаётся только на машине.

Приватный репозиторий, ключ доступа, задание в планировщике — вечер работы. Дальше оно живёт само.

Узел 3. Файл правил проекта

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

Файл правил лежит в корне проекта и читается в начале каждой сессии. Автоматически, без напоминаний.

Что туда идёт:

• кто ты и что за проект — чтобы не объяснять при каждом запуске
• где лежит контекст: какие папки за что отвечают
• как с тобой работать: что делать самостоятельно, а что выносить на обсуждение
• чего не делать никогда

Последний пункт — самый недооценённый. Одна строка «эти папки не трогать без спроса» стоит сотни всплывающих окон, потому что она работает всегда, а не только когда ты внимателен.

Узел 4. Память между сессиями

Четвёртый узел — то, из-за чего полный доступ вообще окупается.

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

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

Что стоит записывать: принятые решения и причину, повторяющиеся ошибки, чтобы не наступать дважды, договорённости о том, как работаем.

Чего не стоит: то, что и так видно в коде и в истории проекта. Память — не свалка, а отобранное.

Узел 5. Перехватчики порядка

Пятый узел — тонкий, и до него доходят немногие.

Правила в файле — это просьба. Сильная, но просьба: нейросеть может её обойти, особенно на длинном контексте, когда начало сессии уже далеко.

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

Пример из моей системы: сборка сайта заперта так, что нельзя писать код, пока не утверждена структура, и нельзя деплоить, пока не пройден финальный этап. Не «не рекомендуется» — именно нельзя, попытка обрывается.

Ставится это на самые дорогие ошибки. Не на всё подряд: два-три замка в правильных местах закрывают почти весь риск.

И только теперь — снимать ограничители

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

Начни с безопасного и обратимого — чтение файлов, поиск, запуск тестов. Дальше расширяй по мере того, как видишь, что система ведёт себя предсказуемо.

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

Вот что на самом деле означает «полный доступ». Не безрассудство, а то, что ты наконец перестал быть узким местом собственной системы.

С чего начать сегодня

Если ставить всё сразу — не поставишь ничего. Порядок такой:

1. git init в папке проекта — пять минут, и откат у тебя есть
2. Файл правил: кто ты, что за проект, чего не делать — полчаса
3. Разрешения на чтение и поиск — сними подтверждения хотя бы там
4. Память — по мере накопления решений, не заранее
5. Перехватчики и внешний бэкап — когда система устоялась

Первые три пункта — один вечер. Этого уже хватает, чтобы работать без страха.

Если хочешь это под себя, а не собирать по кускам

Всё выше — фундамент, и он собирается руками за несколько вечеров, если знаешь порядок. Знать порядок — и есть самая дорогая часть: я его собирал не с первого раза.

Чтобы получить настроенную систему за один вечер, без сбора по кускам и без моих граблей — есть [МИКРО-ПРОДУКТ]: [ССЫЛКА-МИКРО]

Почему это вопрос отката, а не доверия

Спор про автономность обычно ведут в терминах «доверяю или нет». Это неправильная рамка.

Доверие не масштабируется: ты не можешь проверить каждое действие агента, который делает сто шагов в день. Откат масштабируется: неважно, сколько шагов сделано, если любой день возвращается одной командой.

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

Что делать, когда что-то всё-таки сломалось

Спокойно, если сетка стоит.

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

Второе: вернуться к последнему рабочему состоянию. Одна команда, потерянные полчаса.

Третье: понять, почему модель так поступила. Почти всегда причина в формулировке задачи или в отсутствующем правиле, а не в злом умысле машины.

Четвёртое: дописать правило. Каждый сбой — это заявка на строчку в файле правил. Без неё то же самое повторится через неделю.

Частые вопросы

Опасно ли давать нейросети полный доступ к файлам?

Опасно давать его без возможности отката. С проектом под контролем версий и автоматическим бэкапом любое неудачное действие возвращается одной командой, и цена ошибки падает до потерянного времени.

С чего начинать сборку сетки безопасности?

С контроля версий. Это единственный узел, без которого остальные не имеют смысла: он превращает необратимые изменения в обратимые.

Когда можно снимать подтверждения?

После того как стоят все пять узлов: версии, бэкап, правила проекта, память между сессиями и перехватчики порядка. До этого подтверждения — единственное, что тебя защищает.

Что нельзя отдавать на автономию вообще?

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

Дальше по теме