В прошлый вторник я сел провести аудит каждого своего проекта за последние несколько лет. 77 штук. Старые монорепозитории курьерской логистики, заброшенные стартеры, движок клинических рассуждений, полдюжины Telegram-ботов, SaaS-фреймворк, который я постоянно переиспользую, два стартапа, менеджер процессов на Rust. Разные стеки, разный возраст, разные работодатели, разное состояние git-гигиены.
Я отдал задачу четырём агентам Claude Code, работающим параллельно. Они управились примерно за 90 минут.
Ниже — паттерн, который они использовали, и почему его версия теперь работает внутри продакшн-кодовой базы на 2200 коммитов на моей основной работе.
Почему одного агента мало
Одноагентный Claude Code хорош, пока не упрёшься в одну из трёх стен.
Контекстное окно начинает захлёбываться на большой кодовой базе. Работа шире, чем глубже, и последовательное чтение тратит реальное время. Хочется, чтобы оркестратор сохранял суждение, а не тонул в диффах файлов.
Рой чинит всё три проблемы. Каждый агент получает свой срез. Лид держит карту.
Сложность не в том, чтобы породить агентов. Порождение — это один вызов инструмента. Сложность в том, чтобы четверо из них не спотыкались друг о друга.
Паттерн
Claude Code поставляется с двумя примитивами, которые в связке дают чистый рой.
TeamCreate + именованные тиммейты. У каждого агента стабильное имя (analyst1, designer, metrics), и он вступает в команду с общим списком задач.
SendMessage для координации. Лид обращается к любому тиммейту по имени. Тиммейты простаивают между ходами и просыпаются, когда им пишут.
Свяжите это с TaskList — и получите плоскость координации. У каждой задачи есть поле owner. Установка owner = analyst3 — ваш атомарный лок. Пока это поле не изменится, задача принадлежит этому агенту.
Для аудита я сделал 77 задач, по одной на проект. Породил четырёх тиммейтов analyst с одним шаблоном промпта: читать проект на уровне кода (а не сообщений коммитов), парсить транскрипты сессий Claude Code, если они есть, писать досье по каждому проекту. И отпустил их.
Гонка, которую я выкатил в первый же день
Первая попытка: каждый тиммейт при простое запускает TaskList, находит задачу с наименьшим ID без владельца, забирает её, делает, помечает выполненной, повторяет.
Это работало первые десять минут. Потом два аналитика схватили одну и ту же задачу в пределах одной секунды. TaskUpdate, устанавливающий владельца, прошёл дважды. Оба сделали работу. Второй перезаписал первое досье слегка другой версией того же контента.
Классическая ошибка оптимистичной конкуренции. Фикс скучный и надёжный: перестать гоняться за задачами с низким ID. Лид заранее назначает владельцев на весь оставшийся диапазон, прежде чем снова запустить рой.
Я разбил оставшуюся работу на четыре непрерывных блока (#33–43, #46–56, #57–67, #68–77) и заранее выставил всех владельцев. Теперь, когда любой агент читает список, каждая задача уже кем-то занята. Гоняться не за что. Каждый агент обрабатывает свой блок в порядке ID и отчитывается, когда блок пуст.
Ноль коллизий до конца прогона.
Что получилось
Шестьдесят файлов досье. Двадцать два помечены showcase, тридцать восемь supporting, семнадцать skip. Пропуски были честными: клиентская работа, где моя доля коммитов ниже 10%, заброшенные скаффолды, пустые заготовки. Плохие данные хуже, чем никакие, когда цель — аудит личного бренда.
Самые интересные находки были не в громких проектах. Они были в пересечениях. Мой «fullstack»-бойлерплейт тихо стал основой под четырьмя продуктами. Одна и та же кодовая база всплыла у пяти разных клиентов. На одном медицинском CRM мои коммиты составили 962 из 2208 (топ-контрибьютор), хотя поверхностные метаданные, на которые я полагался, говорили лишь про ~700. Ручная история git теряет данные. Рой с общим выводом ловит расхождение.
Продакшн-версия
Это не хобби-паттерн. Тот же мультиагентный воркфлоу Claude Code работает в нашем медицинском CRM на основной работе, на кодовой базе в 2200 коммитов. CLAUDE.md там определяет четырёх кастомных субагентов:
django-backend-specialist— владеет моделями, вьюхами, URL-ами.advertiser-frontend-developer— владеет дашбордом рекламодателя.patient-frontend-specialist— владеет порталом пациента.linting-specialist— запускается последним, владеет диффом.
Есть явный контракт между агентами. Когда бэкенд меняет вьюху, он сообщает новый эндпоинт, URL, форму ответа. Фронтенды знают, что нужно запросить эти данные до старта. Линтинг запускается в конце цепочки, а не в середине. Оркестратор (я) держит архитектуру. Агенты держат диффы файлов.
На одном из продуктов, которые я выпускаю по этому паттерну, — перестройке внутренних инструментов под названием prouniforma_full — около 29% коммитов написаны AI под моим руководством. Остальные 71% — мои. Разбивка видна в git shortlog. Нечего прятать, нечего раздувать.
Честная часть
Это не заменяет инженерное суждение уровня senior. Оркестратор всё ещё должен знать, как выглядит хорошо. Когда аналитик возвращает слабое досье, нужно это распознать и попросить переделать. Два агента не согласны друг с другом? Ты это разрешаешь.
Что это действительно даёт — так это рычаг. Один инженер с роем покрывает площадь уровня staff. Узкое место смещается со скорости печати на качество суждения — а это правильное узкое место.
Если хотите посмотреть, что рой реально произвёл, 60 досье живут на davr.dev/projects. Каждое — аудит на уровне кода, а не маркетинговый текст.
— Davron Yuldashev · github.com/Dave93 · @YulDavr