Ежедневная работа с агентом: разобраться, сделать, починить

← назад к разделу

Настроенный агент — это инструмент, которым надо уметь пользоваться. Три задачи повторяются почти каждый день: разобраться в незнакомом коде, сделать новую функциональность, найти причину ошибки.

Во всех трёх есть один и тот же способ провалиться — попросить сразу конечный результат. «Объясни весь проект», «напиши фичу», «почини это». Агент ответит на любую из этих просьб уверенно и объёмно, и разбирать полученное будет дороже, чем сделать самому.

Работает другое: во всех трёх случаях помогает порядок шагов, где каждый следующий опирается на проверенный предыдущий.

Разобраться в чужом коде

Первое, с чем сталкиваешься на новом проекте, — сотни файлов, чужие решения, ноль контекста. Раньше на это уходили недели; агент, который читает репозиторий, сокращает срок заметно — насколько именно, зависит от размера проекта и от того, есть ли в нём тесты и документация, по которым можно сверяться. Но только если идти сверху вниз, а не проваливаться сразу в детали.

Три слоя, в таком порядке:

1. Карта. «Опиши структуру: какие модули есть, за что каждый отвечает, где точки входа». Это скелет.
2. Маршруты. «Проследи путь запроса на создание заказа: от контроллера до базы, какие классы участвуют». Так видно, как части соединяются.
3. Комната. «Разбери, что делает этот метод и кто его вызывает». Теперь понятно, куда встраивать своё.

Обратный порядок оставляет вас с фрагментами без картины.

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

Ключевое предостережение: агент способен уверенно ошибиться — пересказать логику, которой нет, или пропустить ветку. Поэтому просите ссылки на файлы и строки: ответ без опоры на код — повод насторожиться. Важное сверяйте сами, открыв названный файл. И не принимайте вслепую архитектурные выводы: «здесь плохой дизайн, надо переписать» бывает и правдой, и выдумкой.

Сделать новую функциональность

Самый частый способ провалить задачу — сразу сказать «напиши» и получить гору кода, которую проще выбросить, чем разобрать. Работает последовательность «сначала думаем, потом пишем», где агент участвует в обоих этапах, но в разных ролях.

Сначала разговор, а не код. На этом этапе агент — собеседник: какую проблему пользователя закрываем; какие есть крайние случаи и развилки («а если оплата пройдёт дважды?», «а если отмена после отгрузки?»); какие есть два-три подхода с их плюсами и минусами. Агент хорошо накидывает варианты, которые легко упустить. Правило этого этапа одно: не давать писать код, пока задача не прояснена — ранний код фиксирует непродуманные решения.

Потом план. До кода. Хороший план режет работу на вертикальные срезы: не «сначала все модели, потом все контроллеры», а «срез первый — одна операция целиком от входа до базы и теста, срез второй — следующая». Каждый срез можно собрать и проверить. План называет конкретные файлы, шаги и способ проверки, и он виден целиком — его можно поправить до того, как написана хоть строчка.

Это дешёвая точка, где ловятся ошибки замысла: поменять пункт в плане — минуты, переписать реализованное — часы.

И только теперь код, срез за срезом: сделали — собрали — прогнали тест — закрепили — следующий. План удерживает агента от расползания, а вас — от потери нити на длинной задаче. Если план оказался неверным, это нормально: возвращаетесь к нему, правите, продолжаете. Плохо не «план неточен», а «кода уже гора, а замысел не тот».

Кажется, что разговор и план — лишние этапы, замедляющие старт. На дистанции наоборот: они убирают самую дорогую переделку — когда выясняется, что сделано не то, и выясняется в конце.

Как выглядит запрос целиком

Куски в кавычках показывают направление, но не показывают объём. Вот запрос на первом этапе полностью — так, как его действительно стоит написать:

Задача: сейчас отменить заказ можно в любом статусе, и это приводит
к отмене уже отгруженных заказов. Нужно запретить отмену после отгрузки.

Пока код не пиши. Сначала разберись и ответь на вопросы:
1. Где сейчас обрабатывается отмена — назови файлы и строки.
2. Какие статусы есть у заказа и где описан переход между ними.
3. Что происходит с оплатой и с резервом склада при отмене сейчас.
4. Какие крайние случаи я упускаю: отмена в момент отгрузки,
   повторная отмена, отмена частично отгруженного заказа.
5. Предложи два варианта, где ставить проверку, с плюсами и минусами.

Домен описан в docs/spec/, туда же смотри за терминами.

Что делает этот запрос рабочим, по пунктам:

• Задача сформулирована как проблема, а не как решение. Не «добавь проверку статуса в методе cancel», а «отменяются отгруженные заказы». Иначе агент закроет ваш вариант решения, а не задачу.
• Явный запрет писать код. Без этой строки агент почти наверняка начнёт с кода — и дальше разговор пойдёт вокруг него, а не вокруг замысла.
• Пронумерованные вопросы вместо просьбы «разберись». Ответ на список проверяем по пунктам; ответ на «разберись» проверить нечем.
• Требование назвать файлы и строки. Это и есть защита от уверенной выдумки: ссылку можно открыть.
• Вопрос про упущенные случаи задан отдельно. Здесь агент действительно силён, и ответ на него часто меняет задачу.
• Указан источник правды по домену. Иначе термины будут средние по индустрии, а не ваши.

Ответ на такой запрос читают целиком и проверяют выборочно: открыть два-три названных файла и убедиться, что там написано то, что сказано. Это пять минут, которые отсекают половину дальнейших проблем.

Что такое хороший план

План — центральный артефакт этого сценария, и сказать про него одну строку мало. Вот как он выглядит и по каким признакам его принимают.

Срез 1. Запрет отмены после отгрузки на уровне домена.
  - OrderStatus: добавить метод canCancel(), матрица переходов в одном месте
  - Order.cancel(): проверка canCancel(), доменное исключение при отказе
  - OrderTest: отмена в NEW и PAID проходит, в SHIPPED и DELIVERED — нет
  Проверка: ./gradlew test --tests OrderTest

Срез 2. Ответ клиенту вместо 500.
  - CancelOrderUseCase: пропускает доменное исключение наружу
  - ApiExceptionHandler: доменное исключение -> 409 с кодом ORDER_NOT_CANCELLABLE
  - OrderControllerTest: отмена отгруженного даёт 409 и тело с кодом
  Проверка: ./gradlew test --tests OrderControllerTest

Срез 3. Кнопка отмены в кабинете скрыта для отгруженных.
  - OrderCard.tsx: кнопка по признаку cancellable из ответа
  - OrderDto: добавить поле cancellable
  - OrderCard.test.tsx: кнопки нет при cancellable=false
  Проверка: npm test -- OrderCard

Срез 1. Запрет отмены после отгрузки на уровне домена.
  - Status: добавить метод CanCancel(), матрица переходов в одном месте
  - Order.Cancel(): проверка CanCancel(), доменная ошибка ErrNotCancellable при отказе
  - order_test.go: отмена в New и Paid проходит, в Shipped и Delivered — нет
  Проверка: go test ./internal/order/ -run TestCancel

Срез 2. Ответ клиенту вместо 500.
  - CancelOrderUseCase: возвращает доменную ошибку наружу
  - httpapi/errors.go: ErrNotCancellable -> 409 с кодом ORDER_NOT_CANCELLABLE
  - handler_test.go: отмена отгруженного даёт 409 и тело с кодом
  Проверка: go test ./internal/httpapi/ -run TestCancelOrder

Срез 3. Кнопка отмены в кабинете скрыта для отгруженных.
  - OrderCard.tsx: кнопка по признаку cancellable из ответа
  - OrderDto: добавить поле cancellable
  - OrderCard.test.tsx: кнопки нет при cancellable=false
  Проверка: npm test -- OrderCard

Срез 1. Запрет отмены после отгрузки на уровне домена.
  - OrderStatus: добавить метод canCancel(), матрица переходов в одном месте
  - Order.cancel(): проверка canCancel(), доменное исключение при отказе
  - order.spec.ts: отмена в NEW и PAID проходит, в SHIPPED и DELIVERED — нет
  Проверка: npm test -- order.spec

Срез 2. Ответ клиенту вместо 500.
  - CancelOrderUseCase: пропускает доменное исключение наружу
  - DomainExceptionFilter: доменное исключение -> 409 с кодом ORDER_NOT_CANCELLABLE
  - orders.controller.spec.ts: отмена отгруженного даёт 409 и тело с кодом
  Проверка: npm test -- orders.controller.spec

Срез 3. Кнопка отмены в кабинете скрыта для отгруженных.
  - OrderCard.tsx: кнопка по признаку cancellable из ответа
  - OrderDto: добавить поле cancellable
  - OrderCard.test.tsx: кнопки нет при cancellable=false
  Проверка: npm test -- OrderCard

Срез 1. Запрет отмены после отгрузки на уровне домена.
  - OrderStatus: добавить метод can_cancel(), матрица переходов в одном месте
  - Order.cancel(): проверка can_cancel(), доменное исключение при отказе
  - test_order.py: отмена в NEW и PAID проходит, в SHIPPED и DELIVERED — нет
  Проверка: pytest tests/test_order.py

Срез 2. Ответ клиенту вместо 500.
  - CancelOrderUseCase: пропускает доменное исключение наружу
  - обработчик исключений FastAPI: доменное исключение -> 409 с кодом ORDER_NOT_CANCELLABLE
  - test_orders_api.py: отмена отгруженного даёт 409 и тело с кодом
  Проверка: pytest tests/test_orders_api.py

Срез 3. Кнопка отмены в кабинете скрыта для отгруженных.
  - OrderCard.tsx: кнопка по признаку cancellable из ответа
  - OrderDto: добавить поле cancellable
  - OrderCard.test.tsx: кнопки нет при cancellable=false
  Проверка: npm test -- OrderCard

Обязательное в каждом пункте — три вещи, и по их отсутствию план и забраковывают:

Размер: от трёх до семи срезов, каждый на полчаса-два работы. Признаки, что план слишком крупный, — и что с ними делать:

• Срез содержит слово «и» больше двух раз. Это несколько срезов, которые слиплись.
• Проверка среза — «прогнать все тесты». Значит непонятно, что именно должно измениться.
• Срез нельзя слить в основную ветку отдельно. Значит это половина среза; режьте по другой границе.
• В срезе больше пяти файлов. Почти всегда означает горизонтальный слой вместо вертикального.
• План длиннее десяти пунктов. Это не план, а список задач на неделю; возьмите первую треть, остальное обсудите потом.

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

Найти и починить ошибку

Соблазн при ошибке — вставить агенту текст исключения и попросить «почини». Иногда срабатывает; чаще агент правдоподобно правит не то, маскирует симптом или ломает соседнее.

Сначала воспроизвести. Нельзя надёжно починить то, что не умеешь стабильно вызвать. Соберите точные шаги и данные, при которых ошибка проявляется, а лучше — падающий тест. Это золото: появляется объективный критерий «починено», не зависящий от ощущений. Если ошибка плавающая, так и скажите агенту — «воспроизводится примерно в одном случае из трёх» меняет весь подход.

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

Потом минимальная правка причины. Не обходной путь, который прячет симптом. Хорошая правка объяснима: понятно, почему она чинит ошибку.

И проверка двумя вопросами: ушла ли ошибка — прогнать тот самый воспроизводящий тест; не сломалось ли рядом — прогнать остальные. Правка могла задеть соседнее, и агент про это сам не вспомнит.

И тест остаётся в репозитории. Шаг, который пропускают чаще всего: воспроизводящий тест, на котором всё держалось, должен уехать в коммит вместе с правкой. Не «проверил локально и удалил», а именно закрепить.

Зачем это важнее, чем кажется:

• Это защита от возврата ошибки. Один и тот же дефект возвращается регулярно: кто-то рефакторит, кто-то «упрощает» проверку. Тест — единственное, что останавливает повтор.
• Это документация случая. Тест с именем вида «отмена отгруженного заказа отклоняется» объясняет, почему в коде стоит эта проверка, лучше любого комментария — и не устаревает молча.
• Это доказательство для ревью. Диф, где есть падавший тест и правка, проверяется в разы быстрее: видно, что именно было не так.

Практическое правило: правка без теста принимается только там, где тест написать физически нечем (визуальная правка, поведение внешней системы). И в этом случае в коммите остаётся описание способа проверки руками — иначе через месяц никто не вспомнит, что и как проверяли.

Что общего у всех трёх

Порядок один и тот же: сначала понимание, потом действие, потом проверка. Меняется только предмет — чужой код, новая функциональность или причина ошибки.

И роли распределены одинаково. Суждение о том, что делать и правильно ли получилось, остаётся за человеком; на агента ложится объём — читать, перебирать варианты, писать, прогонять.

Гигиена сессии: почему к третьему часу агент глупеет

Самая частая практическая жалоба звучит так: «утром работал хорошо, к вечеру перестал слушаться». Это не ощущение и не усталость — это предсказуемое свойство длинного разговора.

Что происходит. Вся история сессии — ваши запросы, ответы агента, содержимое прочитанных файлов, вывод команд, неудачные попытки — лежит в окне контекста и участвует в каждом следующем ответе. Три следствия накапливаются одновременно:

• Место кончается. Когда история перестаёт влезать, самое старое вытесняется или сжимается — и первым уходит то, о чём договорились в начале. Отсюда «агент забыл, что мы решили не трогать этот модуль».
• Мусор весит столько же, сколько нужное. Три неудачные гипотезы про причину ошибки остаются в контексте и продолжают влиять на ответы. Агент, который дважды предложил неверное объяснение, будет возвращаться к нему.
• Указания размываются. Ваше правило из первого сообщения к сотому теряется среди прочего текста, и вес его падает.

Когда начинать новую сессию. Признаки конкретные:

Что переносить руками в новую сессию. Это главный навык, и он занимает три минуты:

• Что решено и что отвергнуто. Две-три строки. Отвергнутое важнее: без него агент предложит то же самое.
• Где вы остановились. Какой срез плана сделан, какой следующий.
• Что уже выяснили про код. «Отмена живёт в двух местах: там и там» — это результат работы, его глупо получать заново.
• Текущее состояние проверок. Что зелёное, что падает и с каким сообщением.

Хороший приём: держать этот текст не в чате, а в файле в репозитории — тогда он и в новую сессию попадает, и остаётся после. Решения, которые пережили задачу, оттуда переезжают в память проекта.

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

Страховочная сетка: чистое дерево и чтение дифа

Порядок шагов защищает от плохого замысла. От испорченного рабочего каталога он не защищает, и здесь работают две скучные привычки.

Перед тем как пускать агента править — чистое дерево. То есть все свои изменения закоммичены или отложены, git status пустой. Причина простая: агент правит файлы сам, и через двадцать минут в рабочем каталоге лежит смесь его правок и ваших. Разделить их потом нельзя, и откатить его работу без потери своей — тоже.

Что это даёт практически:

• Откат в одну команду. Не понравилось — git checkout . возвращает всё, и ничего своего вы не теряете.
• Диф показывает ровно работу агента. В этом весь смысл: вы смотрите на его изменения, а не на их смесь со своими.
• Коммит после каждого принятого среза. Тогда откатывать можно по одному срезу, а не всё разом. Это та же мысль, что «план из срезов», только на стороне репозитория.

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

На что смотреть в дифе в первую очередь:

• Файлы, которых не было в плане. Самый важный сигнал. Изменение в файле, о котором не договаривались, — повод спросить зачем.
• Изменения в тестах. Поправленный тест вместо поправленного кода — классическая подмена. Ожидаемое значение, подогнанное под фактическое, выглядит в дифе как одна безобидная строка.
• Ослабленные проверки. Пустой catch, убранное утверждение, отключённый тест, расширенный тип с допущением отсутствия значения.
• Зависимости и настройки сборки. Новая библиотека в списке зависимостей — отдельное решение, а не деталь реализации.
• Удалённый код. Агент убирает то, что кажется ему неиспользуемым, и иногда ошибается.

Практический порядок приёмки: сначала git status (какие файлы вообще тронуты), потом git diff по файлам вне плана, потом диф по остальным, потом прогон проверок. Занимает это меньше, чем разбор последствий одной пропущенной правки.

Сколько это стоит и где дешевле руками

Ни один из трёх сценариев не бесплатный, и стоят они очень по-разному. Полезно знать заранее, где агент окупается очевидно, а где вы платите за удовольствие.

Что делает расход большим: чтение файлов. Разбор незнакомого кода дорог не потому, что агент много думает, а потому что он загружает в контекст десятки файлов. Отсюда практический вывод: точная постановка («посмотри в этом модуле») стоит в разы меньше, чем «разберись в проекте».

Где агент выходит дороже руками — три узнаваемых случая:

• Вы точно знаете, что и где поменять. Объяснение задачи займёт больше времени, чем правка. Признак: вы уже открыли нужный файл.
• Задача требует вкуса, а не объёма. Формулировка текста в интерфейсе, выбор имени, компоновка экрана. Агент даст средний вариант, и вы будете его править.
• Задача плохо проверяема. Там, где нельзя быстро сказать «работает или нет», приёмка съедает всю экономию.

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

Глубже: когда агент не справляется: признаки тупика и правило остановкирасширенное

Три сценария выше описаны для случая, когда агент справляется. Отдельный навык это заметить, что не справляется, раньше, чем он потратит ваш вечер и ваш бюджет.

Признаки. Третья правка подряд не чинит тест, а меняет место падения. Агент уверенно повторяет одно и то же действие или объяснение с другими словами. Диф растёт, а движения к цели нет: правки расползаются по файлам, которых задача не касалась. Тесты «то зелёные, то красные» после каждой попытки, и агент объясняет это по-разному. Агент начал ослаблять проверки (закомментировал утверждение, добавил catch с пустым телом, поменял ожидаемое значение под фактическое).

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

Правило остановки. Два неудачных цикла, и работа останавливается, а не продолжается «ещё разок». Дальше один из четырёх ходов.

Откатить к последнему хорошему коммиту и переформулировать задачу с тем, что узнали (например, добавить падающий тест, который описывает нужное поведение, и просить починить его, а не «сделать чтобы работало»). Сузить задачу: одна функция вместо сценария. Начать новую сессию с чистым контекстом и коротким резюме, потому что старый контекст уже мешает. Или сделать руками: полчаса своей работы против ещё двух часов наблюдения за кругами.

Цена переключения. Ручная работа кажется поражением, и это ошибка: цель это результат, а не доля кода, написанного агентом. Полезная привычка: заводить таймер на задачу для агента (двадцать минут на маленькую, час на большую) и на истечении решать явно, а не по инерции. Случаи, где агент не справился, записывают одной строкой: они показывают границы применимости в вашем проекте точнее любых статей, и через месяц по ним видно, что стоит починить в правилах или в кодовой базе.

Глубже: большая унаследованная база без тестов: что построить первымрасширенное

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

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

Характеризующие тесты. До любого изменения фиксируют текущее поведение, каким бы странным оно ни было: агент хорошо пишет тесты вида «на такой вход сейчас такой выход» для существующего кода, включая крайние случаи, которые он находит по коду. Это не тесты на правильность, а сеть, которая ловит изменение поведения; после неё правки становятся безопасными. Для модулей с выводом наружу (отчёты, файлы, ответы API) годятся снимки: сохранить вывод на наборе входов и сравнивать.

Швы и храповик. Изменения делают через швы: место, где можно подставить другую реализацию, не трогая остальное (интерфейс, точка вызова). Правила ArchUnit с замороженными нарушениями фиксируют текущую структуру и не дают ей ухудшаться, а каждая сессия убирает несколько старых нарушений. Большой рефакторинг «переписать модуль» запрещён до тех пор, пока модуль не покрыт характеризующими тестами.

Что отдавать агенту здесь. Чтение и описание, генерацию характеризующих тестов, поиск мест использования, механические переименования и извлечения с тестами до и после. Что оставлять себе: решение, где шов, что считать правильным поведением там, где текущее очевидно неверно, и порядок, в котором модули выводят из хаоса.

Глубже: несколько агентов сразу: рабочие деревья, ветки и сборка результатарасширенное

Вся статья написана про одного агента в одной сессии. Как только задач больше одной, возникает соблазн запустить три агента параллельно, и без правил это даёт три несовместимых решения и вечер слияния конфликтов.

Изоляция. Каждый агент работает в своём рабочем дереве git (git worktree add ../task-a task-a), то есть в отдельном каталоге на своей ветке от одного и того же коммита; так они не видят незакоммиченных правок друг друга и не ломают друг другу сборку. Одна ветка на задачу, одна задача на агента.

Разделение задач. Параллелятся задачи с непересекающимися файлами и модулями: один делает миграцию и репозиторий, другой контроллер и контракт, третий тесты на существующий модуль. Две задачи в одном файле это одна задача. Общие решения (имена, контракт между частями) принимают до запуска и записывают в спецификацию, которую читают все агенты; иначе каждый изобретёт своё.

Сборка результата. Собирает один человек, по одной ветке за раз: ревью дифа, слияние в main, запуск проверок, затем следующая ветка поверх обновлённого main (агенту второй задачи говорят перебазироваться). Слияние трёх веток разом это то место, где несовместимые решения обнаруживаются позже всего.

Цена. Три агента это тройной расход токенов и тройное внимание на приёмку; экономия есть только там, где задачи независимы и каждая заняла бы час. Признак перебора: вы тратите на слияние и согласование больше, чем сэкономили на параллельности. Обычная рабочая норма это один основной агент и второй на фоновую задачу (тесты, документация), а не пять.

Коротко

• Общий провал во всех трёх задачах — просить сразу конечный результат: «объясни всё», «напиши фичу», «почини».
• Чужой код разбирают сверху вниз: карта → маршруты → конкретный метод; ответы требуют ссылок на файлы и строки. Функциональность делают в порядке разговор → план → код срезами; ранний код фиксирует непродуманные решения.
• План режут вертикальными срезами, где каждый можно собрать и проверить. Ошибку сначала воспроизводят (лучше падающим тестом), потом ищут причину по коду, потом чинят минимально и проверяют, что не сломалось соседнее.
• Суждение — за человеком, объём — на агенте. Наоборот не работает. Тупик виден по признакам: третья правка не чинит, повторы, растущий диф, ослабленные проверки; после двух неудачных циклов откат и переформулировка, сужение, новая сессия или руками, с таймером и записью случаев.
• В унаследованной базе без тестов сначала карта, характеризующие тесты и снимки, швы и ArchUnit-храповик; агенту чтение, тесты и механику, себе решения о швах и порядке.
• Несколько агентов: рабочее дерево и ветка на задачу, непересекающиеся файлы, общие решения в спецификации до запуска, сборка одним человеком по одной ветке; норма один основной и один фоновый.
• Хороший запрос содержит проблему, а не решение, явный запрет писать код, пронумерованные вопросы, требование назвать файлы и строки и указание на источник правды по домену. Хороший план — от трёх до семи срезов, в каждом конкретные файлы, шаг проверки и работающий результат; признак готовности — можно остановиться после любого среза.
• Воспроизводящий тест уезжает в коммит вместе с правкой: он и защита от возврата дефекта, и объяснение проверки в коде, и доказательство для ревью. Длинный разговор предсказуемо портится: место кончается, мусор весит столько же, указания размываются; новую сессию начинают по признакам и переносят руками решённое, отвергнутое, место остановки и состояние проверок.
• Перед работой агента дерево чистое, коммит после каждого принятого среза, и смотреть надо диф, а не пересказ: файлы вне плана, правки тестов, ослабленные проверки, новые зависимости, удалённый код.
• Дороже всего чтение файлов, поэтому точная постановка дешевле «разберись в проекте»; руками быстрее, когда вы уже знаете правку, когда нужен вкус, а не объём, и когда результат плохо проверяем.

Что почитать дальше

• Как настроить агента под свой проект — правила, скиллы, память и инструменты, на которых всё это стоит.
• Галлюцинации — почему уверенный ответ и правда не одно и то же.
• Как ревьюить код, который написал AI — что проверять перед слиянием.
• Приёмка результата ИИ — как убедиться, что сделано то, что требовалось.