podlodka_ai_grably.md

Субагенты не нужны

Если вы заглянете в твиттер/linkedin, то увидете кучу рассказов про agents swarm и вот это все.

К сожалению, практика показывает, что пока что большая часть таких рассказов – попытка хайпануть, а успешных внедрений в процессы компаний нет.

Сегодня я расскажу, что реально работает и стоит инвестиций времени, а что – шум и оверинжиниринг.

Спойлер: название доклада – кликбейт, на самом деле в 90% случаев они не нужны

Общие тренды

1. Переход от копайлота к ИИ-работникам, работающим автономно
2. Разделение ролей

Пруфы: Новые анонсы субагентов в Codex, параллельных агентов в Claude Code

Как было раньше

Игрушечный пример, когда прошу сделать предварительный рисерч, а в итоге промежуточные шаги занимают 100к токенов в контексте основного агента

Решение – вынести рисерч в отдельный тред, а в основной помещать только результаты

Показываю, как это можно сделать вручную запуском двух cli tools Но мы пытаемся уйти от тривиальной ручной работы

Как работает: Subagent vs Subtask

• Subtask = отдельный тред
• Subagent = Subtask + unique prompt, tools, permissions

Показываю на практике с запросом на рисерч реализации subagents в CC Потом показываю, как создавать специализированного read-only рисерч агента

! Чаще всего достаточно Subtask

Почему с появлением Skills субагенты почти не нужны

Субагенты – выбор динамического промпта в зависимости от задачи + тулы + subtask Первая часть заменяется скиллами, а тулы перестали быть проблемой – context rot пофикшен новой реализацией claude code и уходом от mcp к skills.

Получается, в большинстве случаем достаточно создать subtask с конкретным запросом на использование скилла.

Переносим рисерч из субагента в скилл, проверяем работу

Ralph Wiggum

Зацикливаем агента на автономную работу – наша задача стать тимлидом

Способы

1. Через внешний скрипт
2. Через агента оркестратора

Идея: забрать у себя возможность микроменеджирить

Как ревьюить?

Так же как с людьми – ревьюим только PR, а не конкретные изменения или коммиты

Сначала ревьюим с помощью агента (/review). Кстати, на практике это один из самых ROI-шных кейсов применения агентов на больших репо

Как формировать роли в "команде"

Отсылка к недавнему исследованию Cursor с имплементацией браузера.

Основной тейк – не переусложнять.

Базовый минимум: разделяем роль менеджера и исполнителя Опционально: добавляем ревьюера / тестировщика

А где все-таки субагенты нужны?

Когда нужны кастомные Permissions. Это не про инструменты, которые даем агенту, а про то, что ему запрещаем.

Примеры:

• QA агент с Playwright MCP (опционально, показать пример)
• Мультиагентная система, где есть read-only оркестратор и исполнители

Инсайты из практики (настройка AI-first процессов разработки в компании клиента)

• Тут будут инсайты через неделю
• Точно будет что-то про yolo мод в докере и ограничения
• И про автоматизацию git worktree на каждую сессию

Сравнение имплементаций сабагентов/сабтасков в Codex/ClaudeCode/Cursor/OpenCode

Тут сравнительная табличка с основными отличиями, вроде параллельного запуска агентов

И самый важный урок:

Из практики внедрения видно, что команды, которые сразу пытаются делать сложные системы – увязают и забивают.

Закон Галла: "Сложная система, которая работает, неизменно эволюционировала из простой системы, которая работала. Сложная система, разработанная с нуля, никогда не работает и не может быть исправлена, чтобы заработать. Нужно начинать сначала с работающей простой системы."

Правильный флоу:

1. Просто все добавляем все в единый CLAUDE.md
2. Постепенно выносим куски в отдельные Skills
3. Вызываем сабтаски вручную (промптом), пока не выведем успешные паттерны
4. Только после этого выносить в отдельные субагенты те части, где есть четкие специализации по permissions. И это опционально
5. Гораздо важнее дать системе качественный feedback loop и уйти от микроменеджмента (Ralph Wiggum)

Доп материалы:

1. Оригинальный Ralph Wiggum
2. Oh-My-Opencode (сложно, но для вдохновения)
3. Эксперимен Cursor с созданием браузера