Разработчик с более чем 15-летним опытом в индустрии превратил личный пет-проект на Java в рабочий оркестратор задач. Система связывает git worktree, CLI-сессии агента, merge request и веб-дашборд. Свой опыт автор описал в разборе на Habr.
Задумывалось всё как небольшой CLI-дашборд. Через несколько итераций в проекте появились tmux, git-хуки для детерминизма статусов, авторевью комментариев через AI и end-to-end тесты с MCP chrome-devtools. Главный вывод автора звучит непривычно: привычная инженерия заняла несущественную часть разработки, а фокус сместился на архитектуру, скиллы и организацию агентных сессий.
Ниже разобрано, из каких компонентов собран оркестратор, как в него встроен Claude Code через CLAUDE.md и MCP, с какими ограничениями столкнулся автор и какие метрики пришлось пересмотреть.
Зачем понадобился оркестратор: от CLI-дашборда до системы
За 15 лет в индустрии у автора накопилось кладбище пет-проектов, и он говорит об этом спокойно. В этот раз всё сложилось: рабочая подписка на Claude Code, желание чем-нибудь заняться, новая реальность вокруг LLM и общая инфляция производительности.
Первая версия планировалась как CLI-дашборд. Расчёт не пережил первой итерации: захотелось ссылок на задачу и merge request, индикаторов, кликабельного интерфейса. Терминал такое показывает плохо, поэтому проект переехал в браузер.
Рабочий набор инструментов у автора скромный: macOS, Git, IntelliJ IDEA IDE, терминал и Java 25. Никаких редких фреймворков. Привычный цикл работы он описывает как работу гребца: взять задачу, вычитать, сделать, отправить на ревью, провести пару раундов, задеплоить на тестовый стенд. Оркестратор появился, чтобы разгрузить именно эту последовательность.
Архитектура Java-оркестратора: git worktree, CLI-сессии и дашборд
Оркестратор связывает четыре компонента: git worktree, CLI-сессии агента, merge request и веб-дашборд. Задача получает изолированную рабочую директорию, в ней стартует агентная сессия, результат уходит в merge request, а дашборд показывает человеку состояние всего конвейера. Каждый элемент закрывает свою часть работы, и выпадение любого ломает цепочку.
Инструмент вырос за пределы CLI. Интерфейс стал кликабельным, со ссылками на задачу и merge request и индикаторами статусов. Разница принципиальная: в терминале состояние приходится держать в голове, а дашборд показывает его на экране.
Как git worktree помогает изолировать задачи
git worktree позволяет одному репозиторию обслуживать несколько рабочих директорий сразу, каждая на своей ветке. Пока агент правит код в одной директории, вторая остаётся нетронутой, и переключение ветки не рушит сборку под руками. Для параллельных агентных сессий это критично: без изоляции они затирают файлы друг друга.
Что происходит дальше, источник не раскрывает: материал обрывается на фразе про запуск сессии после создания worktree. Так что о связке директорий с конкретными CLI-процессами можно только догадываться, и делать этого не стоит.
Роль tmux в управлении агентными сессиями
Открывать по вкладке терминала на каждую задачу оказалось неудобно, поэтому в проекте появился tmux. Мультиплексор держит несколько сессий в одном окне и позволяет переключаться между ними без потери контекста.
Побочный эффект перехода на многозадачность: рабочий терминал автора Warp не выдержал нагрузки и начал лагать. Замена нашлась быстро, на Kitty, где всё работало ровно. Полезное наблюдение для всех, кто планирует держать десяток параллельных агентных сессий: терминал становится узким местом раньше, чем кажется.
Claude Code в оркестраторе: память, MCP и агентные сессии
Агентный CLI в проекте оставлен умным. Через MCP он работает с репозиторием, документацией, бордой, логами и другими источниками. Автор описывает это как одно из ключевых решений: оркестратор не подкладывает агенту файлы вручную, тот сам запрашивает нужное. Если выбираете coding agent под похожую задачу, пригодится практическая матрица выбора между Claude Code и Codex.
Настройка CLAUDE.md для постоянного контекста
Память в Claude Code живёт в файлах и переживает отдельные сессии и разговоры. От временного контекстного окна файлы памяти отличаются тем, что дают постоянный контекст: общие стандарты проекта для команды, личные предпочтения разработчика, правила для конкретных директорий. Документация по памяти Claude Code отдельно отмечает, что такие файлы можно версионировать вместе с проектом.
Быстрый старт даёт команда /init: она создаёт CLAUDE.md с базовой документацией проекта. Правят память через /memory, которая открывает файлы в системном редакторе. Префикс # для добавления правил на ходу отключили. Запоминать новое теперь лучше через /memory или обычную просьбу в диалоге, в документации приводится пример вроде «remember that we always use TypeScript strict mode».
MCP для доступа к репозиторию и логам
MCP работает как слой доступа к внешним данным. Через него агент дотягивается до репозитория, документации, борды и логов, то есть до тех систем, где контекст задачи реально живёт. Практическая выгода в том, что тикеты и логи не нужно копировать в промпт вручную.
Какие именно MCP-серверы подключены и как разграничены права, источник не раскрывает. Для повторения это придётся решать самостоятельно.
Недетерминизм LLM и как с ним бороться: git-хуки и детерминизм статусов
Главная техническая проблема агентной разработки в том, что LLM недетерминированы. Один и тот же промпт даёт разные ответы, поэтому доверять модели фиксацию состояния задачи нельзя. Автор выносит статусы на git-хуки: смена состояния привязана к событию в репозитории, а не к выводу модели. Хук срабатывает на коммит, ветку или push, и статус меняется по факту, который легко проверить.
Как именно устроены эти хуки, материал не описывает. Детерминизм держится на событиях Git, и это разумная граница ответственности: модель делает работу, где вариативность нормальна, а учёт состояния остаётся за обычным кодом.
Контекст вокруг тоже изменился. По наблюдениям автора, вместо задач от людей, которым было лень написать больше трёх слов в заголовке, приходят полотна плохо связанного текста. Документация, которую и раньше было тяжело держать в узде, взорвалась и устаревает ещё быстрее. На код-ревью все внезапно поумнели, и людей стали волновать вещи, которым не первый десяток лет.
Кризис код-ревью и новые метрики: Cycle Time, WIP limit
Почему классическое ревью перестаёт работать
Автор формулирует прямо: он быстро понял, что сам слабое звено, ревью кода бесполезно, кода слишком много, и в MVP оно не нужно. Объём изменений, который выдаёт агент, физически не проходит через человеческое чтение. Один из подходов, упомянутых в проекте, это авторевью комментариев через AI: часть замечаний отсеивается до того, как их увидит человек. Как устроен этот фильтр, источник не раскрывает, но логика прозрачна: отсеивать шум на входе дешевле, чем разбирать его вручную.
Меняется и то, о чём вообще спрашивают на ревью. Вопросы сползли к базовым вещам, которым не первый десяток лет: корректность границ, обработка ошибок, лишние зависимости. Когда код пишет не человек, слабые места проявляются на другом уровне. Почему скорость генерации строк стала фиктивным KPI и как агентная разработка разрушает понимание кодовой базы, разбираем в отдельном материале.
Как меняются Cycle Time и WIP limit
Cycle Time и WIP limit в агентной разработке требуют пересборки. Ограничение на число задач в работе теряет привычный смысл, потому что узкое место смещается с разработчика на проверку и согласование. Cycle Time начинает измерять отрезок от постановки до принятого merge request, а не время написания кода: сам код появляется быстро, а приёмка остаётся человеческой.
Конкретных цифр автор не приводит, речь именно о смене логики метрик. Разбор про то, почему Claude Code уверенно ошибается в оценке сроков и как получить диапазон с понятными рисками, помогает выстроить такую калибровку.
Тестирование в агентной разработке: end-to-end с MCP chrome-devtools
Тестирование сместилось в сторону end-to-end. Дашборд это веб-приложение, и его поведение автор проверяет через MCP chrome-devtools: агент управляет браузером и проходит сценарии так, как это делал бы человек. Смысл в том, что проверка закрывает связку интерфейса и бэкенда целиком, а не отдельные функции в вакууме.
Подход подпирает главный вывод автора: привычная инженерия заняла несущественную часть разработки. Код, тесты и инфраструктура собираются быстро, время уходит на архитектуру, скиллы и организацию агентных сессий. Тестирование в такой модели тоже становится организационной задачей: нужно заранее решить, что именно проверяет агент и по каким признакам считает сценарий пройденным.
Как настроен тестовый контур, какие сценарии покрыты и как обрабатываются падения, источник не раскрывает. Общий принцип переносится на другой проект только после собственной проверки.
Стоит ли повторять: выводы и ограничения подхода
Проект прошёл путь от пет-проекта до рабочего инструмента и занял место в ежедневной работе. Повторить его можно, но цена входа лежит не в написании кода. Основные усилия уходят на архитектуру связки worktree, сессий и дашборда, на описание скиллов и на дисциплину вокруг агентных сессий.
Что держать в голове:
- недетерминизм LLM: статусы и учёт состояния надёжнее держать на git-хуках, а не на выводе модели;
- кризис ревью: объём кода растёт быстрее, чем способность его читать, поэтому нужен фильтр замечаний до человека;
- метрики: Cycle Time и WIP limit пересобирают под новое узкое место, иначе они показывают не то;
- память агента: CLAUDE.md требует поддержки, а префикс # больше не работает, память правят через /memory;
- инструменты: терминал под нагрузкой может не выдержать, опыт автора с Warp и Kitty это показывает.
Практический старт выглядит скромно. Возьмите одну повторяющуюся задачу, заведите CLAUDE.md через /init, подключите MCP к репозиторию и логам, вынесите статусы на git-хуки. Вместо вкладки терминала под каждую задачу поставьте tmux.
Решающий критерий простой: если ревью и приёмка съедают больше времени, чем генерация кода, оркестратор окупается. Если задачи редкие и мелкие, накладные расходы на инфраструктуру и поддержку сессий перевесят выгоду. Похожий урок есть в кейсе агента, который провалил боевые задачи, но закрыл больше половины исследовательских запросов аналитиков.