--- title: "Два паттерна AI-кодирования: когда запускать subagent, когда параллельные сессии" description: "Subagent-driven и параллельные сессии - два паттерна масштабирования AI-кодирования. Когда какой выбирать, trade-offs и практический опыт на проекте portal-frontend." url: "https://ifonin.ru/blog/subagent-driven-vs-parallel-sessions/" date: 2026-03-13 tags: ["ai-coding","claude-code","architecture","vibe-coding"] --- # Два паттерна AI-кодирования: когда запускать subagent, когда параллельные сессии На проекте 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 выигрывает по токенной эффективности на структурированных задачах. Параллельные сессии выигрывают по скорости, когда задачи не пересекаются. Начните с одного паттерна. Измерьте токены и время. Потом решайте.