Код с Grok Bot: как не сломать репозиторий
Grok Bot полезен в коде, когда вы просите проверяемый diff, а не «почини всё сам». Бот может исследовать репозиторий, написать небольшой патч и подготовить PR. Он не должен бесконтрольно менять `main`, удалять историю или видеть секреты.
Это работа агента на компьютере, не чат с подсказками: чем Grok Bot отличается от Grok и ChatGPT. Старт: первый час, официально x.ai/bot и Grok Bot 101. Роль и стопы — создание своего бота, мандат как ТЗ.
Правило «сначала прочитай»
Перед изменением бот:
- Строит карту проекта (README, структура, инструкции).
- Находит существующие проверки (тесты, линтер, CI-подсказки).
- Формулирует план на маленькую задачу.
- Ждёт ок, если шаг рискованный.
Не давайте широкое «исправь техдолг». Одна issue — один ожидаемый результат — один набор файлов. Иначе получите огромный diff без review и сгоревший лимит.
Безопасный цикл изменения
Создать ветку
Отдельная ветка с понятным именем от актуального `main`/`develop`. Работа в `main` напрямую — запрет для стартового контура.
Зафиксировать baseline
Статус репозитория, какие тесты зелёные сейчас, пустой или известный diff. Без baseline непонятно, что сломал патч.
Маленький патч + diff
Внести изменение и показать diff. Человек смотрит, что реально тронуто.
Тесты и линтер
Запустить релевантные проверки. Если тесты красные — остановить расширение задачи, показать лог, локализовать причину. Не «чинить» падающий тест вырезанием assert.
PR
Описание: цель, файлы, тесты, риски, откат. Review и merge — человек. Логика «не в прод без стопов» та же, что в как не пускать бота в прод.
Чеклист перед PR:
- Ветка не `main`
- Diff просмотрен
- Тесты/линтер по зоне изменения
- Нет секретов в коммите и в промпте
- Есть способ отката
- Нет force-push в защищённые ветки
Красные линии репозитория
Запретите явно:
- force push в `main` (и в другие защищённые ветки);
- удаление веток «за компанию»;
- переписывание истории без отдельного решения;
- секреты, токены, приватные ключи в промпте или в файлах;
- миграции БД, массовые зависимости, инфраструктуру без approval владельца.
Approval на рискованные шаги: approval и 2FA. Shared-машина и чужие сессии — риск: shared computer.
PR — артефакт, а не печать доверия
В описании PR должны быть:
- цель изменения;
- список файлов / зона влияния;
- что прогнали из тестов;
- известные риски;
- как откатить.
Человек проверяет diff, тесты и поведение на границах. Бот может ответить на комментарии review, но не закрывает замечания молчаливым «fixed» без diff. Merge — только после вашего решения.
Что поручать первым
Хороший старт:
- документация и README по факту кода;
- тест-кейсы на уже понятное поведение;
- поиск дублирования;
- небольшие локальные фиксы;
- разбор логов без секретов.
Плохой старт: «перепиши архитектуру», «задеплой», «почини прод», «положи ключ в env из чата». Примеры контуров — в кейсах. Безопасный день-1 периметр — безопасный первый контур.
Цена ошибки и Heavy
Ведите журнал: задача → ветка → diff → тесты → review → откат (если был). Не обещайте процент ускорения без своих данных.
Если команде не хватает рук на поток мелких PR, Heavy считайте как ФОТ многорукого, не сравнивайте с подписками чатов: цена Heavy — не подписка. Сначала дисциплина ветки и review, потом масштаб.
Широкие «почини всё» часто жгут лимит: сжёг лимиты за день.
Пример мандата на маленький патч
Роль: разработчик патча по issue #123. Цель: исправить X в файлах A,B; тесты зоны зелёные; PR-описание готово. Шаги: ветка fix/123-short → baseline тестов → патч → diff → тесты → описание PR. Нельзя: push в main, force-push, секреты в промпт/коммит, миграции, деплой. Approval: перед push ветки на remote (если включено), перед любым merge, перед изменением CI. Стоп: красные тесты вне зоны, нужны секреты, scope расползся больше чем на 2 файла сверх плана.
Так бот не превращается в «агента с правами админа репозитория». Если scope расползся — остановите и заведите вторую задачу, не дописывайте «заодно» в тот же PR.
Типичные фейлы первой недели с кодом
| Фейл | Почему больно | Что сделать |
|---|---|---|
| Работа сразу в main | Нет review/отката | Только ветка |
| «Почини все варнинги» | Огромный diff | Одна issue |
| Секрет в промпте | Утечка | Секрет-хранилище |
| Правка теста вместо бага | Ложная зелень | Чинить код |
| Merge без человека | Риск прод | Approval |
Честные фейлы общего старта — в честных фейлах первой недели. Для кода добавьте Git-дисциплину из этого материала.
FAQ
Можно ли пушить в main? Нет для стартового контура. Ветка и PR сохраняют review и откат.
Нужен ли весь репозиторий? Только необходимая область. Начните с read-only и конкретной задачи.
Как защитить секреты? Не вставлять в промпт, не коммитить; использовать секрет-хранилище команды.
Тесты не проходят — что делать? Остановить расширение, показать лог, локализовать причину. Не маскировать ошибку правкой теста «в зелень».
Может ли бот сам сделать PR? Подготовить ветку и описание — да. Review, merge и рискованные изменения — человек.
С чего начать? Откройте /start и проведите один маленький патч с diff и тестом.
Что сделать сейчас
- Выберите одну issue и запретите работу в `main`.
- Прогоните цикл: ветка → baseline → патч → тесты → PR-описание.
- Сверьте красный список с не пускать в прод.
- Официально: x.ai/bot, Grok Bot 101.