Розробник Ядулла Абіді розповів, як суттєво підвищити продуктивність у 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. У такому режимі сесія може вивчати кодову базу й пропонувати зміни, не редагуючи вихідний код. У другому терміналі запускають виконавця: claude --name builder. Доступні сесії можна переглянути командою /list-agents, а коли план готовий, планувальник звертається до виконавця як @builder. Пошук сесій і доставку повідомлень Claude виконує сам, за допомогою інструментів ListAgents і SendMessage, тож вручну їх запускати не потрібно.
Як приклад Абіді наводить додавання автентифікації у вебзастосунок. Планувальник вивчає наявні маршрути, обирає точки інтеграції та визначає рішення, чутливі для безпеки. Виконавець займається реалізацією, але лише після явного схвалення підходу з боку користувача. Цю умову варто прописати в інструкціях обох сесій. Бриф для планувальника має містити релевантні шляхи до файлів, узгоджену поведінку, обмеження та критерії приймання. Далі виконавець реалізує план, а планувальник тим часом вивчає наступні завдання. Розробник застерігає, що це не привід кодити під вимоги, які змінюються: невирішені питання не варто віддавати виконавцеві, натомість він має повідомляти про блокери, а не імпровізувати. Якщо, наприклад, виконавець виявить, що наявне API обробляє прострочені сесії інакше, ніж очікувалося, він може надіслати це планувальнику. Так виникає зворотний зв'язок, і користувачу не доводиться вручну переписувати кожне оновлення.
У цього підходу є обмеження. По-перше, контекст не спільний: сесії не бачать історії одна одної, передається лише текст, без історії розмови та вкладених файлів, тому повідомлення має бути зрозумілим само по собі. По-друге, колізії файлів нікуди не зникають: повідомлення не запобігають одночасному редагуванню одного файлу. Якщо двом незалежним сесіям потрібен той самий файл, варто використати claude --worktree feature-name, яка створює окрему копію репозиторію та гілку, а інтеграція відбувається окремим кроком у Git. По-третє, доставка не є перериванням: активна сесія читає вхідні повідомлення між викликами інструментів, а сесія в очікуванні може почати новий хід. Повідомлення можуть бути прийняті, відкладені або відхилені, тож відсутність відповіді краще з'ясувати, а не засипати сесію новими запитами. Нарешті, дозволи залишаються локальними: інший екземпляр Claude не може схвалювати дії від вашого імені, і автор вважає це корисною межею.
Якщо завдання вимагає більше нагляду, ніж разові передачі, Абіді пропонує агентні команди. Це експериментальна функція, за замовчуванням вимкнена, яку вмикає змінна середовища CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Головний агент координує інших, кожен з яких має власне вікно контексту, і вони можуть обмінюватися повідомленнями. Автор радить просити лідера створити бекенд-реалізатора, фронтенд-реалізатора та рев'юера з чітко розмежованими зонами відповідальності. За наявності інструментів Task вони можуть спільно користуватися списком завдань із залежностями, щоб заблоковане завдання не взяли в роботу. Вкладені агенти не успадковують історію лідера, тому архітектуру й обмеження варто передати одразу, а розподіл файлів між учасниками особливо важливий, бо агентні команди не ізолюють їх у worktree автоматично.
Загалом розробник доводить простішу думку: зростання продуктивності дає менша кількість ретрансляцій між сесіями без втрати контролю. Підхід підходить для завдань із справді розділеними обов'язками, а не для кожної дрібної правки. Кілька активних сесій швидко витрачають токени, а агентні команди додають накладні витрати на координацію. Якщо використовувати це з розумом, пише Абіді, швидко помітиш, що менше координуєш і більше будуєш.
4
