Запуск Claude Code в качестве чистого механизма оценки на протяжении всего SDLC

Разработчик на r/ClaudeAI подробно описал свою многомесячную настройку использования Claude Code (среда выполнения с использованием инструментов и многошаговым циклом) на всем протяжении жизненного цикла разработки ПО — задачи, реализация в нескольких репозиториях, ревью кода, MR и постоянный уровень знаний.

Ключевое архитектурное решение: Не допускать Claude Code к оркестрации. Обычный Python выполняет всю механическую работу: вызовы API Jira, операции с git, запуск тестов, линтинг, перемещение файлов. Claude Code вызывается только для принятия решений — написания кода, оценки результатов ревью, выбора между архитектурными вариантами. Автор обнаружил, что смешивание этих двух задач (позволение агенту оркестровать через инструменты) делало первую версию медленной, дорогой и недетерминированной.

Конкретный жизненный цикл одной задачи:

• Оркестратор Python: Получает задачу из Jira, ищет в локальной вики связанные архитектурные решения, настраивает рабочее дерево на новой ветке, собирает краткое описание реализации на 30–50 строк (критерии приемки, целевые файлы, вызывающие измененные общие функции, соответствующие стандарты). Выводит JSON-пакет.
• Claude Code: Читает описание и пишет код. Это единственный шаг со значительным потреблением токенов.
• Python + подагент ревью: Запускает тесты, линтинг, форматирование. При неудаче передает обратно агенту реализации (максимум 3 повторных попытки). Затем запускает подагент ревью кода, настроенный без прав на редактирование или запись — он может только читать и сообщать о найденных проблемах.
• Python: Создает предложение в панели управления. После ручного одобрения оркестратор отправляет изменения и создает MR.

Конкретные методы Claude Code, которые оказались важными:

• Изоляция подагентов. Агент ревью работает в своем собственном контекстном окне с запретным списком (Edit, Write). Разделение ревью и реализации помогло выявить изменения в поведении общего кода, которые агент реализации постоянно упускал.
• Предварительно собранные описания лучше динамического исследования. Раньше позволение Claude Code исследовать кодовую базу перед реализацией потребляло заметно больше токенов, чем передача ему сфокусированного описания, собранного Python (получение из Jira, поиск в вики, анализ зависимостей).
• Маршрутизация навыков/команд через YAML, а не позволение агенту решать. Отображение от /ticket, /review, /standup и т.д. к оркестраторам является явным, поэтому возможности можно проверить, а не возникают спонтанно.
• Хуки блокируют коммиты. Pre-commit хук запускает линтинг и форматирование перед любым коммитом, который пытается сделать Claude Code. Нарушения блокируют коммит; агент должен их исправить.

Уровень вики: Страницы Markdown с тремя уровнями достоверности (подтверждено, предположено, предоставлено человеком) и порогами устаревания на уровне полей. Без уровней агенты принимают свои собственные прошлые предположения за истину и превращают галлюцинации в авторитетные знания.

Проблемы, которые все еще решаются:

• Функции, затрагивающие несколько репозиториев: агент теряет связность, когда функция охватывает несколько сервисов, даже с отслеживанием структурированного набора изменений.
• Нечеткие задачи: агент выдает разумные, но часто неправильные реализации из неоднозначных спецификаций. Автор теперь помечает нечеткие задачи как блокирующие.
• Расширение объема: склонность к излишней инженерии требует постоянной калибровки через стандарты и агента ревью.
• Длинные сессии: ранний контекст выпадает из эффективного внимания; реинициализация при старте сессии смягчает, но не устраняет проблему.