Ошибка 4 — оставлять агента без присмотра

Что может пойти не так

Истории про работу «без присмотра» повторяются из проекта в проект. Агент решает упростить структуру и удаляет несколько файлов, которые казались устаревшими, — а они на самом деле использовались, и потом их приходится искать и восстанавливать. По промпту «закоммить все изменения» он через git add -A втягивает в коммит файл с секретами, и если репозиторий публичный, это уже не баг, а утечка. Пытаясь исправить ошибку, он меняет версию библиотеки — обновляет Next.js или откатывает его обратно — и ломает всё, что от этой версии зависело. Не сумев починить ошибку с первого раза, он пробует всё новые и новые способы и постепенно превращает рабочий код в кашу. А чтобы решить мелкую задачу, ставит тяжёлую библиотеку там, где хватило бы десяти строк кода.

Уровни автономности агента

Claude Code работает в нескольких режимах, и разницу между ними важно понимать. В режиме по умолчанию агент спрашивает разрешение перед каждым потенциально опасным действием. В режиме планирования он только разрабатывает план и ничего не выполняет. А в режиме полной автономии действует сам, не спрашивая подтверждений. Правило для новичка простое: начинайте с режима по умолчанию и переходите к автоматическому принятию правок только тогда, когда хорошо понимаете, что агент делает в каждый момент, — и только на рутинных задачах.

Что должно требовать подтверждения

Есть минимальный набор действий, которые агент всегда должен согласовывать. Это отправка кода в общий репозиторий — особенно git push -f, ведь это публичное действие. Это удаление файлов через rm, git rm или удаление папок. Установка пакетов командой npm install, особенно когда речь о новой зависимости. Любые изменения базы данных — миграции, DROP, ALTER на боевой версии. Выкат проекта, включая git push в основную ветку с автоматическим деплоем. И закрывающие действия вроде коммита сразу со многими файлами. Всё это стоит оставить под ручным контролем, даже когда в остальном вы доверяете агенту.

Pre-commit hooks — автоматическая страховка

Git pre-commit hook — это скрипт, который запускается до каждого коммита. Если он падает, коммит не происходит.

# Создаст .husky/pre-commit
npm install --save-dev husky
npx husky init
# Добавьте в .husky/pre-commit:
npm run lint && npm run build

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

Стратегия веток для новичка

От поломок основной ветки хорошо защищает простая схема работы с ветками. Все задачи делаются не в основной ветке, а в отдельной ветке вида feature/<name>, и в ней агент может коммитить свободно. Когда функция работает и проверена, вы вручную вливаете ветку в основную, а уже из основной идёт автоматический выкат. Если что-то пошло не так, ветку достаточно просто удалить — основная ветка при этом не пострадает.

Когда оставить агента работать нормально

Часть задач можно спокойно делегировать без постоянного надзора. Это рутинные правки вроде «переименуй переменную X на Y во всех файлах», стилистические задачи в духе «приведи все компоненты в src/components к нашему DESIGN.md» или прогон тестов с просьбой найти падающие и попробовать их починить. Общий принцип такой: у задачи должен быть измеримый результат, и она не должна затрагивать критичные части системы — платежи, базу данных, секреты.

Как читать, что делал агент

После работы агента результат нужно проверять самому. Команда git status показывает, какие файлы изменены, — там должны быть только те, что относятся к задаче. git diff показывает, что именно изменено, и эти изменения должны быть осмысленными. git log --oneline -10 выводит последние коммиты, и их сообщения должны быть понятными. И, наконец, проект нужно запустить локально и проверить в браузере, что он действительно работает. Отчётам агента не стоит доверять слепо: иногда он сообщает, что всё готово и протестировано, а функция на деле не работает.

Когда отказаться от автономности

К ручному контролю стоит возвращаться, как только появляются признаки того, что вы теряете нить. Это происходит, когда возникают ошибки, которых вы не понимаете; когда архитектура усложнилась настолько, что вы перестали видеть структуру проекта; когда агент несколько раз подряд сделал не то; или когда вы сами замечаете, что не разбираетесь в написанном коде. Любой из этих сигналов означает одно: пора остановиться, пройтись по коду руками и понять, что произошло. Иначе проект постепенно превращается в «чёрный ящик», который потом никто не может править.

Что в следующем уроке

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