Договорились, что агент — не волшебник, а очень способный сотрудник с амнезией и без чувства ответственности. Четыре базовых практики держат его в рамках, пока он пишет по фиче за сессию. Но как только он начинает писать заметную часть боевого кода, к этим четырём добавляются другие вопросы. Кто проверит то, что он написал? Что мешает ему запушить в мастер или уронить прод? Что делать, когда сессия распухла и агент теряет нить?
Здесь — шесть практик следующего уровня. Всё, что ниже, мы набили на реальных проектах. Не теория — то, что срабатывает на каждой сессии.
1. Задача — это файл в git, а не строчка в чате
Договорились в прошлый раз: спека живёт в файле, а не в переписке. Здесь идём дальше — файл задачи должен быть не просто «где записаны требования», а трекером с жизненным циклом и явным критерием готовности. Иначе следующим практикам не на что опереться: приёмку не сверить, если непонятно, что именно считалось «сделано».
У нас каждая функция — это отдельный файл задачи, и папка задач лежит в git. Задача коммитится вместе с кодом, который её реализует. Правила простые:
- Одна задача = одна функция. Есть уже задача — работаем с ней, не плодим дубли.
- Фазы со статусом. Задача разбита на шаги, у каждого
[ ]или[x]. Видно, где агент остановился, если сессия оборвалась. - Явный Definition of Done. Не «сделать фичу», а перечисляемый список: что именно должно работать. Это тот самый список, по которому потом идёт приёмка (практика 3).
- Итоговый блок. В конце — реализовано целиком или нет, что осталось.
- Готова — переезжает в
done. Не когда «задеплоили когда-нибудь», а сразу как DoD выполнен.
Большие направления держим отдельно, длинным roadmap’ом, который режется на пачку мелких задач: агент видит и лес, и деревья.
Побочный эффект приятный: у задачи теперь есть история в git. Кто, когда, зачем — из лога, а не из памяти. А DoD из файла превращается в чек-лист приёмки: задачу нельзя закрыть «на ощущение», есть список — по нему и сверяемся.
Файл задачи — это контракт. Пока в нём не прописано, что считается «готово», любое «готово» — вопрос веры.
2. Не объясняйте одно и то же в каждом чате — упакуйте это в скиллы
Есть вещи, которые агенту надо объяснять снова и снова: как у вас принято проектировать сервис, что значит «тестируемый блок», как выглядит финальная приёмка задачи. Пересказывать это в каждом чате — то же самое, что каждый раз заново обучать нового сотрудника с нуля. Скучно, долго, и половину вы забудете сказать.
Решение — вынести повторяющиеся процедуры и знания в скиллы: маленькие самодостаточные инструкции, которые агент подхватывает по триггеру, когда задача этого требует.
- Знание-паки. Принципы проектирования (SOLID, KISS/YAGNI, «тонкие контроллеры — толстые сервисы»), правила по слоям, чек-листы качества. Один раз описал — агент применяет во всех чатах одинаково, а не по настроению.
- Процедуры. «Как разбить фичу на тестируемые блоки», «как принять готовую задачу»: вход/выход, корнер-кейсы, способ проверки. Это не текст «на почитать», а пошаговый алгоритм, который агент реально исполняет.
- Триггеры вместо ручного вызова. У скилла в описании — фразы-триггеры («новый сервис», «рефакторинг», «задача готова»). Агент сам понимает, когда пора его достать.
Плюс скилла в том, что он переиспользуемый и версионируемый. Поправил чек-лист один раз — и он применяется во всех будущих сессиях и на всех проектах, куда его положил. Знание перестаёт жить в голове одного человека.
И писать всё с нуля не нужно — уже есть открытые наборы, которые можно взять как основу и адаптировать под свой флоу. Мы отталкивались от двух:
- awesome-claude-code (© Dykyi Roman, MIT) — готовые знание-паки и агенты-аудиторы: SOLID, чистая архитектура, слои, DDD, тестирование, детекторы код-смеллов.
- superpowers (obra) — процессный конвейер: brainstorming → написание плана → исполнение (в том числе через субагентов). Мы подрезали его под свой формат задач.
Не «скопировали и забыли», а взяли за основу и переписали под свои договорённости. Но стартовать с готового набора — сильно быстрее, чем изобретать чек-листы самому.
Скилл — это не «ещё один документ». Это компетенция, которую вы один раз выдали агенту и больше не пересказываете.
3. «Прогнал — работает», а не «по идее работает»
Любимая фраза агента в конце задачи — «готово, должно работать». Слово «должно» здесь несёт всю нагрузку. Агент искренне верит в свой код: он же его только что написал. Но вера — не проверка.
Поэтому финал задачи — это не «я закончил писать», а отдельная процедура приёмки, которая заменяет «по идее работает» на «прогнал — работает». По пунктам:
- Перечитать Definition of Done задачи. Каждый пункт проверяется отдельно, а не «в целом вроде всё».
- Прогнать тесты затронутой области. Не «тесты вроде есть», а зелёный прогон.
- Smoke-проверка живого поведения — реально дёрнуть основной сценарий, а не рассуждать о нём.
- Корнер-кейсы из декомпозиции: пусто, граница, null, ошибка внешнего сервиса. Happy path проходят все, падают на краях.
- Чистота проверок — линтеры и анализатор архитектуры без нарушений.
Итог оформляется таблицей: пункт DoD → как проверено → PASS/FAIL. Любой FAIL — задача не закрыта. Никаких «ну это мелочь, потом».
Это не то же самое, что независимый аудит из практики ниже: там второй агент ищет скрытые баги в чужом коде, здесь автор доказывает, что его собственный код делает заявленное. Разные проверки, нужны обе.
«Должно работать» — это гипотеза. Задача закрыта тогда, когда гипотезу прогнали и она стала фактом.
4. Хуки-рельсы: то, что агент физически не может обойти
Промпт — это просьба. Хук — это стена. Разница принципиальная: агент может «забыть» инструкцию из карты проекта, но не может проигнорировать скрипт, который перехватывает его действие до выполнения.
Поэтому все критичные договорённости стоит вынести из текста инструкций в исполняемые хуки:
- Секреты не утекают. Хук не пускает содержимое
.env, приватных ключей и токенов в чат. Даже частично. - В главную ветку — только через MR. Прямой push и force-push в неё блокируются.
- Прод трогает человек. Опасные команды на боевом сервере (по хосту/IP) не выполняются агентом; агент только готовит команды.
- Границы слоёв проверяются автоматом. На завершение хода прогоняется анализатор архитектуры: уехала логика не в тот слой — ход не закрыть, пока не переложишь.
- Форматирование не обсуждается. После каждой правки прогоняется линтер-форматтер.
Два инженерных нюанса, которые мы усвоили на практике:
- Одна точка настройки. Все хуки читают один конфиг — путь к приложению, имя защищённой ветки, регэксп прод-хоста. Правишь один файл, а не семь скриптов.
- Fail-open по умолчанию. Нет нужной утилиты в окружении — команда всё равно выполнится. Битый хук не должен блокировать работу. Исключение — защита прода: она fail-closed, потому что цена ошибки на проде выше цены неудобства.
Хуки — это не «недоверие агенту». Это гигиена. Ремень безопасности не означает, что вы плохой водитель.
5. Никакого «сам написал — сам и проверил»
Агент, который проверяет собственный код, находит ровно те баги, которые готов признать. Это как просить студента самому проверить свою контрольную по своему же решению.
Отсюда правило: без независимого аудита мёрдж не предлагаем. После любой нетривиальной доработки запускается отдельный агент, который не видел хода решения — только код диффа. Ему на вход даётся явный чек-лист:
- Полнота — покрыты ли все места вызова, а не одно.
- Нерегрессия — не сломаны ли смежные пути.
- Тесты — есть ли проверка на изменение и проходит ли.
- Скрытые баги — edge-кейсы, null, гонки, необработанные ошибки внешних сервисов.
- Слои — не уехала ли логика не туда.
- Секреты — не утекли ли ключи в код или логи.
Ключевое: аудитору не показывают версию событий автора. Он судит по коду. Нашёл проблему — не чинит молча, а возвращает автору; чинит автор, аудитор перепроверяет.
Это дороже, чем «глянул сам». Но один свежий взгляд, не заражённый исходным замыслом, ловит то, что автор структурно не способен увидеть.
6. Свежий агент на задачу: не дайте контексту протухнуть
Чем длиннее сессия, тем хуже агент соображает. Он тащит за собой всю историю чата — отладочные тупики, брошенные гипотезы, случайные реплики. Контекст «протухает»: агент цепляется за нерелевантное, теряет нить, начинает противоречить сам себе. Один марафонский чат на всю фичу — прямой путь к этому.
Лечится дроблением работы на изолированные единицы. Если задачи из плана независимы — каждую отдаёшь свежему субагенту с чистым, специально собранным контекстом:
- Не пересказ сессии, а бриф. Субагенту даёшь ровно то, что нужно для его задачи: требования, точные значения, куда смотреть. Он не наследует твою историю — и потому на неё не отвлекается.
- Ревью после каждой задачи. Свежий агент проверяет результат в две стадии: соответствие спеке и качество кода. Пока задача не принята — следующую не начинаем.
- Координатор бережёт свой контекст. Главная сессия занята оркестрацией — кто что делает и в каком порядке, — а не деталями каждой задачи. Контекст координатора остаётся чистым.
Это не то же, что независимый аудит из практики 5. Там — один финальный разбор всей ветки перед мёрджем. Здесь — способ вести работу по ходу: свежий исполнитель на каждую задачу, чтобы контекст не гнил от задачи к задаче.
Контекст — расходник, об этом была прошлая статья. Свежий агент на задачу — это способ не сжечь его весь в одном бесконечном чате.
Что из этого вынести
Если свести шесть практик к одной мысли: не делайте вид, что агент — человек с памятью, здравым смыслом и чувством ответственности за прод. Он ничего из этого не имеет по умолчанию. Зато он отлично работает внутри рельсов, которые вы ему поставите.
- Задача — файл в git с явным DoD, а не строчка в чате.
- Компетенции — в скиллах, а не в пересказе на каждый чат.
- Приёмка — «прогнал — работает» по DoD, а не «должно работать».
- Договорённости — в хуках-рельсах, а не в благих пожеланиях.
- Проверка — отдельным агентом, по коду, а не по рассказу автора.
- Работа — свежими агентами на изолированных задачах, чтобы контекст не протухал.
Ничего из этого не про «магию промптов». Всё — про инженерную дисциплину вокруг инструмента, который сам по себе дисциплины не имеет. Чего и вам желаем.