Skip to main content
gitai-coding-assistantsprompt-engineering

Як я обмежую ШІ в Git

Обговорення звелося до простої думки: одного системного промпту для безпеки Git недостатньо. Потрібні обмеження лише читання за замовчуванням, явне підтвердження перед комітом і пушем, а також чіткі правила гілок та пул-реквестів. Інакше AI автоматизація в розробці легко псує незавершену роботу, створюючи хаос у командній історії.

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

Я б взагалі не довіряв одному системному промпту, коли йдеться про Git. Якщо я інтегрую штучний інтелект у процес розробки, то моє перше правило нудне, але рятує нерви: будь-які дії, окрім читання, заборонені, поки я не попрошу їх явно.

Причина банальна. І Claude, і Codex у паралельних сесіях можуть добросовісно затерти зміни, що тривають, тому що для них локальний робочий каталог виглядає як просто черговий стан проєкту. Я таке бачив не раз, і саме тут гарний промпт закінчується, а інженерна дисципліна починається.

Зазвичай я фіксую кілька правил прямо в інструкціях агента: не робити commit, push, rebase, видалення гілок і checkout з побічними ефектами без підтвердження; перед будь-якою зміною показувати, що саме буде зачеплено; після генерації коду спочатку проганяти тести або збірку. Якщо проєкт важкий, я ще окремо забороняю коміт без апруву, тому що з незакоміченими змінами розбирати AI-код часто швидше.

З практики команди мені подобаються і більш приземлені речі: єдиний формат feature-гілки з кодом задачі, посилання на 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-агента, здатного змінювати свій код під час виконання, що створює значні ризики для безпеки та стабільності. Цей випадок наочно демонструє, чому системні промпти, що обмежують таку поведінку, стають необхідними.

Поділитися статтею