Требования в git: моя практика

Сразу дисклеймер: моя философия с AI -- “делай и экспериментируй, а там разберешься”. Поэтому сетап может быть далек от оптимального, но пока работает.

Начало моего AI adoption описывала пару постов выше. Коллега-инженер помог поднять локальное dev-окружение и настроить Claude Code с GitHub через стандартный gh CLI. И между делом обронил фразу, которая для меня стала ключевой: «агенты работают эффективнее, когда контекст лежит в репозитории рядом с кодом. И уже есть скиллы, которые пишут требования, тебе руками писать не нужно».

Open-source скилл, который он мне показал, выдавал ерунду. Я его переписала под себя и сохранила где? Правильно, в git. Скилл покрывает весь процесс написания требований:

1. Записывает бизнес-контекст, формулирует гипотезу
2. Ходит в кодовую базу и исследует, как новая идея ложится на текущее состояние кода, подсвечивает лимитейшены и потенциальные проблемы ещё до того, как я пойду к разработчикам.
3. Генерирует prd по заданной структуре
4. Проверяет, какие метрики для AB-тестов уже существуют, чтобы не плодить дубли (с этим у нас исторически была проблема).

Теперь я не пишу и не редактирую требования руками. Вообще. Я вызываю скилл, описываю контекст идеи, получаю драфт, дальше промчу AI до состояния ready -- и пушу в git.

Сетап такой:

1. Общение с AI: Claude Code в терминале. Сейчас через cmux, думаю перейти на Warp.
2. Просмотр markdown: Nimbalyst (это AI-нативный редактор markdown-файлов; удобно читать рядом с тем, что пишет агент).
3. Хранение и согласование: pull request в GitHub. Пока требование в папке draft, аппрув разработчиков не нужен. Как только перевожу в ready for dev - нужен.
4. Если в процессе написания требований я поняла, что нужно улучшить скилл, то доставляю исправления в скилле в одном PR с требованиями.
5. Если в процессе разработки мы поняли, что требования нужно изменить, то это чаще всего делают сами разработчики. Ребята просто просят свой AI обновить требования согласно коду, и я аппрувлю это изменение. Никаких тебе “не так понял”, “не так услышал”, “я этого не говорила”.

Иногда я свои оптимизационные идеи реализую сразу в коде, и только если идея нравится -- пишу PRD. Тогда коллеги получают draft PR сразу с требованиями и реализацией, и решают сами: переиспользовать код или выкинуть и написать нормально.

Ещё у меня есть агент, который оценивает результаты AB-тестов. Контекст по каждому тесту он забирает из git, а не из Confluence. Теоретически мог бы и оттуда, но интуитивно кажется, что токенов горело бы больше (но замеров я не делала).

Я уже писала, что время на написание требований с таким сетапом сократилось в разы. Падения в качестве не замечены, даже наоборот -- за счет того, что скилл исследует кодовую базу, он часто поднимает вопросы, которые я бы 100 про пропустила при проработке идеи.

При этом я вижу потенциальные проблемы с внедрением такого подхода:

1. Не-инженерные стейкхолдеры. В Git комфортно тем, кто там уже живёт. Если вам нужно получать формальное согласование от бизнес-стейкхолдеров, вряд ли они легко адаптируются.
2. Сетап работает круто, потому что я не пишу требования руками и все процессы по веткам и PR делает claude code. Если вы не хотите или не можете делегировать эту работу AI, то писать требования в markdown файлах и руками открывать PR скорей всего вас замедлит.

Резюме

В эпоху AI самым важным становится правильная организация контекста для агентов. Организовать контекст в GitHub проще, потому что:

1. Там уже лежит код, то есть львиная доля контекста.
2. Есть наработанные практики контроля контрибьюшена в этот контекст: PR, ревью, diff'ы, история.

Раз мы превращаемся в менеджеров контекста, логично перемещаться туда, где этот контекст живёт.

Если у вас похожий опыт или, наоборот, вы попробовали и не зашло -- расскажите в комментариях! Страшно интересен опыт простых смертных, а не AI гуру с линкедина и телеги)