Програміст Ядулла Абіді поділився прийомом, який дозволив йому значно ефективніше працювати з Claude Code: він налаштував кілька сесій так, щоб вони самі обмінювалися повідомленнями, замість того щоб він вручну копіював результати з одного вікна в інше. За його словами, річ зовсім не у швидкості виконання — виграш з'являється тому, що увагу більше не доводиться витрачати на передачу контексту між сесіями.

У чому суть прийому

Claude Code непогано впорається з одним окремим завданням, проте щойно кілька сесій працюють над спільною ціллю, роль посередника між ними бере на себе людина — доводиться вручну переносити плани, висновки й команди. Абіді розв'язав цю проблему за допомогою міжсесійних повідомлень (cross-session messaging). Важливо, що це не те саме, що експериментальні агентні команди: функція просто з'єднує сесії, які користувач запускає самостійно, і працює без додаткових експериментальних прапорців у підтримуваних версіях.

Що потрібно для запуску

  • Версія Claude Code: 2.1.224 для macOS, Linux і WSL2, або 2.1.234 для Windows.
  • Дві сесії, запущені в різних терміналах. Автор радить присвоїти їм імена — це необов'язково, але спрощує звернення до потрібної сесії.

Зв'язка «планувальник + виконавець»

У першому терміналі запускається планувальник у режимі планування:

claude --name planner --permission-mode plan

У режимі plan mode сесія може досліджувати кодову базу та пропонувати зміни, але не редагує вихідний код напряму. У другому терміналі запускається виконавець:

claude --name builder

Перелік доступних сесій показує команда /list-agents. Коли план готовий, планувальнику достатньо попросити пояснити його виконавцеві, звернувшись до нього як @builder. Увесь пошук сесій і доставку повідомлень Claude бере на себе, користуючись інструментами ListAgents і SendMessage — вручну запускати їх не треба.

Як розподілити ролі

Абіді наводить приклад із додаванням автентифікації у вебзастосунок. Планувальник досліджує наявні маршрути, визначає точки інтеграції та виокремлює рішення, чутливі для безпеки. Виконавець береться за реалізацію тільки після явного схвалення підходу користувачем — цю умову варто прописати в інструкціях обох сесій.

Для планувальника автор радить формулювати запит так: дослідити можливі способи автентифікації, запропонувати найменшу розумну реалізацію та дочекатися підтвердження від користувача, перш ніж передавати план виконавцеві. У такому «брифі» мають бути зазначені релевантні шляхи до файлів, узгоджена поведінка, обмеження та критерії приймання.

Поки виконавець реалізує затверджений план, планувальник паралельно опрацьовує наступні завдання. Абіді застерігає: це не привід кодити під вимоги, що постійно змінюються. Невирішені питання не варто перекладати на виконавця — натомість він має повідомляти про блокери, а не імпровізувати самостійно. Наприклад, якщо виконавець виявить, що наявне API обробляє прострочені сесії не так, як очікувалося, він може надіслати це планувальнику. Так утворюється зворотний зв'язок: реалізація впливає на планування, і людині не доводиться вручну переписувати кожне оновлення.

Підводні камені

  • Контекст не є спільним: сесії не централізовані й не бачать історії одна одної. Передається лише текст повідомлення, без історії розмови та вкладених файлів, тож формулювання має бути самодостатнім.
  • Колізії файлів нікуди не зникають: повідомлення не запобігають одночасному редагуванню одного й того ж файлу. Якщо дві незалежні сесії претендують на один файл, варто скористатися командою claude --worktree feature-name, яка створює окрему копію репозиторію та гілку. Саме повідомлення про зміну не переносить її в інший worktree — інтеграція відбувається окремим кроком через Git.
  • Доставка повідомлення не є перериванням: активна сесія читає вхідні повідомлення між викликами інструментів, а сесія в режимі очікування може почати новий хід. Вхідне повідомлення можуть прийняти, відкласти або відхилити, тож відсутність реакції краще перевірити, а не заспамлювати сесію повторними запитами.
  • Дозволи залишаються локальними: одна сесія Claude не може схвалювати дії від імені користувача за іншу. Абіді вважає це корисним обмеженням.

Коли варто переходити на агентні команди

Якщо завдання потребує більше контролю, ніж разові передачі повідомлень, автор радить звернутися до агентних команд. Це експериментальна можливість, яка за замовчуванням вимкнена і активується через змінну середовища:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS1

У цій схемі головний агент координує решту учасників, кожен із яких має власне вікно контексту і може обмінюватися повідомленнями з іншими. Абіді радить доручити лідеру сформувати окремого бекенд-реалізатора, фронтенд-реалізатора та рев'юера з чітко розмежованими зонами відповідальності. Якщо доступні інструменти Task, учасники команди можуть спільно користуватися списком завдань із залежностями, що унеможливлює взяття в роботу заблокованого завдання. Така координація вбудована саме в агентні команди — звичайні міжсесійні повідомлення її не забезпечують.

Вкладені агенти не успадковують історію лідера, тому архітектуру й обмеження потрібно передавати їм одразу і повністю. Агентні команди також не ізолюють учасників у окремих worktree автоматично, тож розподіл файлів між ними набуває особливого значення.

Висновок

Приріст продуктивності дає саме скорочення кількості «ретрансляцій» між сесіями без втрати контролю над процесом. Підхід добре працює для завдань із чітко розділеними обов'язками, але не варто перетворювати кожну дрібну правку на «збори AI-комітету» — кілька активних сесій швидко з'їдають токени, а агентні команди додають додаткові накладні витрати на координацію.

Якщо підходити до цього з розумом, ви швидко помітите, що менше координуєте й більше будуєте.

Ядулла Абіді, розробник

Джерело: Highload.tech