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 и метрик качества.