Claude Code в команде: правила, ревью и безопасность

В одиночку агент - это инструмент. В команде это ещё и вопрос договорённостей: кто отвечает за то, что он сделал, и во что он вообще имеет право лезть.

Что нельзя отдавать агенту

Список короткий и не про качество кода.

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

Секреты. Ключи, токены, дампы с персональными данными. Всё, что попало в контекст, ушло провайдеру модели. Это не гипотетический риск, а определение того, как работает инструмент.

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

Чужие данные под NDA, если условия договора не позволяют передавать их третьим лицам. Провайдер модели - третье лицо, и посредник в цепочке доступа тоже, см. доступ и оплату.

Песочница и разрешения

Три уровня, от слабого к сильному:

Разрешения в конфиге. Список того, что можно без вопроса: тесты, сборка, чтение. Всё остальное спрашивает. Этого достаточно для обычной работы на своей машине.

Ограничение каталогов и сети. Агент видит только проект и не может отправлять данные наружу произвольно. Разумный уровень для проекта с чувствительными данными.

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

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

Ревью агентского кода

Отличается от обычного двумя вещами.

Автор не читал код так, как читал бы свой. Обычно ревьюер опирается на то, что автор уже подумал над каждой строкой. Здесь этой опоры нет, и часть работы переносится на ревью.

Ошибки другого рода. Агент редко делает синтаксические ошибки и часто делает правдоподобные: обработал не тот случай, продублировал существующую функцию под другим именем, поправил симптом вместо причины. Такое проходит беглый просмотр.

Что помогает:

• Разумный размер изменения. Правка на тысячу строк не ревьюится, она пролистывается.
• Тесты, написанные не тем же прогоном, что и код. Иначе они проверяют то же неверное предположение.
• Требование проверяемого результата. Не «сделано», а вывод тестов. Тот же принцип, что и с субагентами.
• Явная пометка в пулл-реквесте, что изменение агентское. Она меняет глубину чтения.

Общие скиллы и конфиги

Что стоит держать в репозитории:

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

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

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

С чего начать внедрение

Порядок, который работает:

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

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

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