На проекте portal-frontend я прошёл через 239 промптов. Где-то после пятидесятого стало понятно: один Claude Code с одним контекстом не масштабируется. Агент начинал переспрашивать вещи, которые уже обсудили. Правил то, что уже исправил. Контекстное окно превращалось в помойку из промежуточных обсуждений, отброшенных идей и устаревших правок.
Два паттерна оформились сами собой. Subagent-driven - оркестратор делегирует задачи специализированным агентам в изолированных контекстах. Параллельные сессии - несколько независимых Claude Code в отдельных git worktrees. Оба работают. Но для разных задач.
Subagent-Driven: специализация через изоляцию
Оркестратор получает задачу, делит её на домены - безопасность, производительность, документация - и отправляет каждый домен в отдельный subagent с чистым контекстом. Результаты возвращаются уже как компактное резюме, а не весь контекст выполнения. Оркестратор координирует только стыки.
Ключевой эффект - изоляция. Исследования AAIA (январь 2026) показывают: при заполнении контекста на 50-75% следование инструкциям падает до 73%, при 75-100% - до 41%. Это то самое “агент начинает забывать”, только с числами. На portal-frontend я видел это на UI-компонентах: к 60-й итерации агент начинал предлагать решения, которые противоречили договорённостям из начала сессии.
Для portal-frontend subagent-driven имел смысл из-за структуры проекта: три чётких домена - UI-компоненты, state management, API-интеграция. Каждый subagent работал со своим срезом кодовой базы. Контекстного мусора между ними не было.
Честный нюанс: subagents не бесплатны. Каждый запуск несёт накладные расходы на передачу контекста и инициализацию. Я не считал токены по-промптово, но subagent-подход заметно дороже в абсолютных числах - токены тратятся на чистую работу, но самих запусков больше.
Хорошо работает когда: задача требует специализации, контекст плотно занят, есть чёткие границы между подзадачами, каждая задача дольше пяти минут.
Плохо работает когда: задача маленькая, нужен постоянный back-and-forth, overhead превышает саму задачу.
Parallel Sessions: скорость через параллелизм
Несколько экземпляров Claude Code, каждый в своём git worktree. Нет иерархии - только параллельная работа над независимыми задачами.
Boris Cherny, создатель Claude Code, описывает работу с 5 терминальными сессиями одновременно. Сообщество разработчиков использует обычно 3-5 worktrees - каждый на своей ветке, системные уведомления сигналят когда нужен ввод.
Git worktrees - ключевой механизм. Каждый worktree получает свою рабочую директорию при общем .git. Запускается за секунды, конфликтов файлов нет по определению - агенты физически работают в разных директориях. Практическая схема для Rails: три параллельные сессии, каждая на своём порту, каждая в отдельном worktree.
Ограничение - человеческое, не техническое. На практике разработчики упираются в потолок 3-4 одновременных сессии. Больше - и начинается когнитивная перегрузка: нужно держать в голове, где что происходит, разрешать конфликты при мёрже, отслеживать каждый агент. Некоторые инструменты решают это через best-of-N: запускают несколько агентов на одну задачу и выбирают лучший результат. Без такой автоматизации потолок ниже.
Хорошо работает когда: задачи независимы, есть чёткие файловые границы, скорость критична.
Плохо работает когда: задачи связаны между собой, нет заранее оговорённой стратегии мёржа, агентов больше пяти.
Выбор по ситуации
| Критерий | Subagent-Driven | Parallel Sessions |
|---|---|---|
| Контекст >60% занят | Да | Нет |
| Задачи независимы | Последовательные | Независимые |
| Приоритет токенов | Высокий | Средний |
| Приоритет скорости | Средний | Высокий |
| Сложность настройки | Высокая | Средняя |
Дерево решений: задача маленькая - делай inline. Большая задача с доменными границами - subagent-driven. Несколько независимых задач, важна скорость - параллельные сессии. Крупный проект с множеством доменов - гибрид.
Где ломается и что делать
Три места, где оба паттерна дают сбои - с практическими обходами.
Context sharing. Качество контекста, которым агенты обмениваются, критически важно. Протоколы MCP и A2A активно стандартизируются и принимаются крупными платформами, но единых решений пока нет. Обход: явные state snapshots между сессиями - сохранять не только результаты, но и промежуточные решения.
Человеческий потолок координации. 4+ параллельных агента требуют больше когнитивных ресурсов, чем большинство готовы инвестировать. Это не проблема инструмента. GitHub Copilot уже решает её через Agent HQ (октябрь 2025, mission control вышел в декабре 2025) - параллельная оркестрация как часть продукта. До широкой доступности подобного: ограничивайте сессии тремя и используйте уведомления вместо активного мониторинга.
Subagent overhead при неправильном применении. Попытка распараллелить мелкие задачи через subagents - классическая ошибка. Контекст заполняется, частичные результаты теряются. Правило: subagent оправдан только когда задача занимает больше времени, чем инициализация агента. Для portal-frontend граница была примерно на 10-15 минутах работы.
Итог
На portal-frontend я использовал оба паттерна. Для связанных задач с риском контекстного загрязнения - subagent-driven с тремя агентами по доменам. Для независимых фич с чёткими файловыми границами - параллельные сессии.
Subagent выигрывает по токенной эффективности на структурированных задачах. Параллельные сессии выигрывают по скорости, когда задачи не пересекаются.
Начните с одного паттерна. Измерьте токены и время. Потом решайте.