Skip to main content
gitai-coding-assistantsprompt-engineering

Как я ограничиваю AI в Git

Обсуждение свелось к простой мысли: одного системного промпта для безопасности Git мало. Нужны read-only ограничения по умолчанию, явное подтверждение перед commit/push и внятные правила веток и PR, иначе AI automation в разработке легко портит незавершенную работу.

Технический контекст

Я бы вообще не доверял одному системному промпту, когда речь про Git. Если я делаю artificial intelligence integration в процесс разработки, то первое правило у меня скучное, но спасает нервы: любые не read-only действия запрещены, пока я не попросил их явно.

Причина банальная. И Claude, и Codex в параллельных сессиях могут добросовестно затереть in-progress изменения, потому что для них локальная рабочая директория выглядит как просто очередное состояние проекта. Я такое видел не раз, и именно здесь красивый промпт заканчивается, а инженерная дисциплина начинается.

Я обычно фиксирую несколько правил прямо в инструкциях агента: не делать commit, push, rebase, branch delete и checkout с побочными эффектами без подтверждения; перед любым изменением показывать, что именно будет затронуто; после генерации кода сначала гонять тесты или сборку. Если проект тяжелый, я еще отдельно запрещаю коммит без апрува, потому что с незакоммиченными изменениями разбирать AI-код часто быстрее.

Из практики команды мне нравятся и более приземленные штуки: единый формат feature-branch с кодом задачи, ссылка на PR в трекере, короткое описание PR человеческим языком, пинг в Slack или Telegram на code review. Это не про бюрократию. Это про то, чтобы AI не превращал Git-историю в свалку без контекста.

И да, если нужен реальный контроль, я бы не ограничивался промптом. Внешние safety-слои для CLI, которые требуют confirm или режут опасные git-команды, надежнее любого “никогда так не делай” в system prompt.

Что это меняет для бизнеса и автоматизации

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

Для AI implementation я вижу ровно три последствия. Первое: чуть медленнее цикл, зато меньше случайных перезаписей. Второе: чище ревью и понятнее ответственность по PR. Третье: проще масштабировать automation with AI между командами, потому что правила одинаково читаются и людьми, и агентами.

Мы в Nahornyi AI Lab как раз такие места и разбираем: где агенту можно дать свободу, а где ему нужен короткий поводок. Если у вас AI уже пишет код, но процесс начинает крошить ветки, ревью и сроки, можно спокойно посмотреть на ваш workflow и собрать AI automation так, чтобы он ускорял разработку, а не создавал новые аварии.

Ранее мы рассматривали MicroMorph — автономного Python-агента, способного менять свой код во время выполнения, что создаёт значительные риски для безопасности и стабильности. Этот случай наглядно демонстрирует, почему системные промпты, ограничивающие такое поведение, становятся необходимыми.

Поделиться статьёй