Technical Context
Я регулярно бачу один і той самий збійний патерн в автономній розробці: агент бадьоро стартує, робить 3–10 кроків, потім «пливе» — плутає пріоритети, повторює вже зроблене, втрачає критерії готовності. У Claude Code цей ефект особливо помітний після compact (стиснення контексту) або при перезапуску сесії. На практиці проблему лікують не «довшим промптом», а правильною опорною структурою: task-лист + субагенти.
Що я вважаю ключовим з точки зору архітектури агента: task-лист у Claude Code — це не просто список у чаті. Починаючи з гілки оновлень початку 2026 року (у спільноті найчастіше згадують v2.1.16), task-листи стали персистентними: вони зберігаються на диску (зазвичай у ~/.claude/tasks/), переживають закриття термінала й частково компенсують втрату «оперативної пам’яті» моделі при компресії.
Найпрактичніший прийом, який я використовую та рекомендую командам: запускати Claude Code так, щоб він «приклеювався» до конкретного task-листа через змінну оточення:
- CLAUDE_CODE_TASK_LIST_ID=my-project — і далі ви працюєте в одному й тому ж списку завдань, навіть якщо сесія переривається.
Для керування task-листом в інтерфейсі є швидкі команди (у різних збірках трапляються /tasks, перемикання через Ctrl+T) та режими планування на кшталт Plan Mode. Я дивлюся на це як на «вбудований шар оркестрації»: агент не повинен щоразу згадувати, що він робить — він має кожен крок звірятися зі списком, відмічати виконане та явно обирати наступний пункт.
Друга опора — субагенти. У Claude Code їх зазвичай піднімають через меню/команди керування агентами (наприклад, /agents, /agents create), а в оркестрації фігурують виклики інструментів типу TaskCreate({ subject: "..." }). Суть для мене проста: я розвантажую «голову» головного агента. Замість того щоб тримати в одному контексті аналіз вимог, правки коду, прогон тестів, читання логів та оновлення документації, я роблю окремі виконавці під повторювані або паралельні шматки.
Є важливе обмеження з практики: паралельність не можна роздувати нескінченно. Я зазвичай стартую з 2–5 субагентів, бо після цього зростає шум координації, а не продуктивність. У спільноті згадують верхні межі близько 7 паралельних агентів, але це вже режим «потрібен диспетчер», а не «само поїде».
Business & Automation Impact
Якщо перекласти це мовою бізнесу, то task-листи та субагенти перетворюють Claude Code з «розумного автодоповнення» на інструмент ІІ автоматизації для реально довгих циклів: від постановки до PR, тестів та деплою. Я не розглядаю це як косметику. Це зміна контурів контролю: замість контролю за пам’яттю моделі ми контролюємо процес через артефакти (список завдань, чекпоінти, звіти субагентів).
Хто виграє першим:
- Продуктові команди, де багато рутинного SDLC: однотипні сервіси, інтеграції, міграції, рефакторинг модулів.
- Аутсорс/інтегратори, яким потрібно передбачувано вести кілька потоків робіт, фіксувати прогрес та відтворювати результат.
- Власники внутрішньої платформи, які хочуть стандартизувати «як агент робить задачі», а не сподіватися на талант окремого промпт-інженера.
Хто програє: ті, хто продовжує керувати агентом «простирадлом промпту» без структури. Я бачив, як такі команди отримують ілюзію швидкості у перші 20 хвилин, а потім втрачають день на розбір, чому агент «зробив не те» після компакшна або перестрибнув через залежність.
У моїх проєктах в Nahornyi AI Lab я закладаю task-лист як обов’язковий шар для впровадження ШІ в розробку: він замінює частину ручного project management на рівні мікрокроків. Але, щоб це запрацювало, список має бути вимірюваним. Не «зроби авторизацію», а «додай endpoint /login, покрий 6 кейсів тестами, онови OpenAPI, прожени лінтер, прилади логи CI». Такий формат різко знижує дрейф і дає вам аудит слідів роботи.
Субагенти, своєю чергою, дають повторюваність. Я часто виділяю ролі на кшталт:
- агент «тести та відтворення багів» (ганяє, збирає логи, формулює мінімальний repro);
- агент «код-рев’юер» (перевіряє диф, стиль, крайні випадки);
- агент «документація/спеки» (синхронізує README, ADR, changelog).
У сумі це впливає на AI-архітектуру процесу: головний агент стає оркестратором, а не «комбайном». І це напряму економить гроші, бо зменшується кількість перезапусків, відкатів та «давай ще раз, але правильно».
Strategic Vision & Deep Dive
Мій неочевидний висновок: task-листи та субагенти — це не «фіча Claude Code», а практичний міст до наступного рівня: агент як процес, а не як чат. Як тільки команда приймає, що основним носієм прогресу стає список завдань та артефакти виконання, можна будувати серйознішу інтеграцію штучного інтелекту з інженерним середовищем.
Я це вже бачу в патернах впровадження. Коли ми в Nahornyi AI Lab робимо розробку ШІ рішень для бізнесу, найстійкіші контури виходять там, де:
- task-лист пов’язаний з реальними джерелами правди (issue tracker, CI, репозиторій);
- кожен пункт має «Definition of Done» та перевірку (тест/лінтер/запит до API);
- субагенти працюють «хвилями»: паралельні задачі без залежностей — разом, залежні — суворо послідовно.
Є й пастки. Перша — надто загальний task-лист. Агент буде чесно «робити таску за таскою», але кожна таска виявиться розмитою, і ви отримаєте красиву імітацію прогресу. Друга — надто багато агентів. Координація з’їдає контекст і час, а ви починаєте керувати керуванням. Третя — відсутність ритуалу звірки: я прямо прописую в проєктному CLAUDE.md правило «перед кожною дією перевіряй task-лист, після — оновлюй статус та артефакти».
Далі буде зсув у бік «інженерії поведінки» агентів: не підбирати магічні промпти, а проєктувати контури пам’яті (task-листи), делегування (субагенти) та контролю (артефакти CI/тестів). Хайп закінчиться там, де агент не доводить довгі ланцюжки до результату; утилітарність починається там, де процес стійкий навіть після компакшна та перезапусків.
Якщо ви хочете перетворити Claude Code на передбачувану систему, а не на лотерею, я запрошую обговорити вашу задачу з Nahornyi AI Lab. Напишіть мені — Vadym Nahornyi — і я запропоную архітектуру впровадження: від структури task-листів і ролей субагентів до інтеграції з вашим SDLC та метрик якості.