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

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

Ломается это в момент, когда нужно понять, что именно изменил агент. Если старт был грязным, его правки перемешаны с вашими, и diff показывает сумму, а не вклад агента. Отделить одно от другого задним числом трудно и рискованно: легко откатить лишнее или оставить чужое. Грязный старт превращает измеримый результат в клубок. Особенно обидно это на первой сессии, когда вы ещё не знаете почерк агента и не можете на глаз сказать, какая строка в diff чья.

Профессиональный ход - завести baseline. Добейтесь чистого git status, зафиксируйте исходное состояние коммитом и убедитесь, что build и test запускаются без агента и дают известный результат. Для этого достаточно нескольких команд: посмотреть статус, отвести отдельную ветку под работу с агентом, прогнать тесты и сборку до задачи. Ни одна из этих команд не относится к агенту - в этом и смысл: baseline снимают в среде без него, чтобы точка отсчёта была честной.

Смысл этой подготовки один: после неё любой результат агента читается как diff относительно известного состояния. Вы видите ровно то, что добавил агент, и знаете, что тесты и сборка были зелёными до него, - значит, красный результат после задачи говорит о правке агента, а не о фоновой поломке. Известная исходная точка превращает проверку из догадки в сравнение. Это различение дороже, чем кажется: без него любая нестабильность теста после сессии выглядит как вина агента, даже если она была и до него, и вы тратите время, отлаживая не то.

В существующем проекте отдельная ветка или worktree - не перестраховка, а способ не смешивать. Свои незакоммиченные изменения не оставляют в одной куче с первой сессией агента: крупную работу ведут в отдельной ветке или в изолированном worktree, где diff агента живёт сам по себе. Так параллельная задача не заражает активную ветку, а слияние остаётся управляемым шагом. Worktree здесь особенно уместен, потому что он даёт агенту отдельное рабочее дерево того же репозитория: ветки, история и remote общие, а файлы на диске - свои, и активная работа в основном дереве не пересекается с сессией.