От pair programming к оркестрации: почему одной сессии больше нет
Ещё месяц назад я писал о том, как работать с Claude как с младшим коллегой, а не поисковой строкой: правильно ставить задачу, планировать до кода, проверять diff. Это был базовый уровень.
Та статья — всё ещё нижняя граница. Эта — следующий уровень.
Где-то в июле то, чем я занимался, перестало быть парным программированием с ИИ и превратилось в нечто другое. У меня одновременно открыты четыре сессии Claude Code: одна собирает фичу, вторая тестирует её в iOS Simulator, третья разбирает миграцию в worktree, четвёртая ревьюит PR, который я ещё не читал.
Я не писал код. И дело даже не в том, что я перестал брифить одного агента. Изменилась сама роль: из исполнителя я превратился в техлида, который управляет системой параллельных ИИ-агентов.
Техлид vs сеньор: где проходит граница
Сеньор-разработчик отвечает за качество одной задачи: как написан код, насколько удачно выбрано решение, какие тесты покрывают функциональность. Техлид отвечает за качество системы, в которой задачи решаются.
Разница принципиальная. Вы перестаёте принимать каждое решение за агента. Вместо этого вы создаёте условия, в которых агент принимает приемлемое решение без вашего участия. Это смена уровня контроля: не «я проверяю каждую строку», а «я задаю спецификацию, границы и критерии приёмки».
На практике это выглядит так: вы не пишете код, а читаете диффы, разруливаете конфликты контекста и следите, чтобы четыре сессии не мешали друг другу.
Что меняется в голове
Ключевой сдвиг — перестать думать о Claude как об одном окне с задачей. Думайте о нём как о пуле исполнителей, у каждого из которых свой контекст, своя задача и свой канал приёмки. Ваша работа — оркестрация, а не микроменеджмент.
Четыре контура техлида при работе с Claude
Модель, которая у меня сложилась, состоит из четырёх контуров. Они работают параллельно, но управляются из одной точки.
1. Спецификация до запуска
Прежде чем запускать сессию, я фиксирую, что должно получиться. Это не «сделай фичу», а короткое описание поведения, ограничений и критериев готовности. Claude не должен угадывать, что для меня «приемлемо». Чем точнее спецификация, тем меньше правок на этапе ревью.
2. Изоляция контекста
Четыре сессии одновременно — это четыре контекстных окна. Если смешать их, агенты начнут тянуть лишние зависимости и конфликтовать. Поэтому я разделяю их так же, как разделял бы задачи между разработчиками: отдельная ветка, отдельный worktree, отдельная зона ответственности.
3. Приёмка через diff, а не через «выглядит нормально»
Я не смотрю на то, как Claude «объясняет» решение. Я смотрю на diff. Это важный принцип: модель может уверенно рассказывать про архитектуру, но код при этом ломает смежный модуль. Поэтому приёмка всегда идёт через фактическое изменение, а не через пересказ.
4. Документация решений
Если агент принял архитектурное решение, оно должно остаться в репозитории или в задаче. Иначе через неделю никто не вспомнит, почему выбран этот путь. Это как с командой: техлид фиксирует договорённости, чтобы они пережили конкретную сессию.
Как это выглядит в реальном потоке
Сценарий из практики:
Первая сессия Claude Code собирает новую фичу. Вторая — проверяет её в симуляторе, прогоняет сценарии и возвращает ошибки. Третья — в изолированном worktree мигрирует данные, чтобы не задеть основной код. Четвёртая — читает PR, который я ещё не открывал, и даёт замечания по стилю, безопасности и архитектуре.
Я в это время не печатаю код. Я распределяю приоритеты, отвечаю на вопросы, которые требуют моего решения, и проверяю только ключевые развилки. Остальное — зона агентов.
Когда вы перестали быть сеньором для одного Claude и стали техлидом для нескольких, вы начинаете управлять не задачами, а пропускной способностью.
Почему это выходит за рамки кода
Та же схема переносится на маркетинг, контент и операции. Вы создаёте несколько рабочих контуров: один агент анализирует данные, второй готовит оффер, третий проверяет позиционирование, четвёртый собирает отчёт. Вы управляете спецификациями, контекстами и критериями приёмки.
Чтобы такой конвейер не превратился в хаос, нужны два условия. Первое — автоматизация процессов, где ИИ-агенты связаны в понятные воркфлоу. Здесь помогает внедрение ИИ-агентов и n8n воркфлоу. Второе — прозрачные метрики: если вы не видите вклад каждого контура в результат, вы управляете вслепую. Поэтому важна настройка сквозной аналитики и лидгена.
Если вы хотите выстроить такие процессы системно, можно обратиться в маркетинговое агентство Dragon Farm. Но сначала — попробуйте запустить четыре сессии и посмотреть, как изменится ваша роль. Скорее всего, вы перестанете быть «тем, кто пишет», и станете «тем, кто управляет».
