ВЕБ ШТУРМ
Обсудить →

Subagent-driven development: как мы построили webshturm.ru за день — 50+ коммитов через Claude Code

Веб Штурм
  • Claude Code
  • subagents
  • DevOps
  • AI workflow

Этот сайт (webshturm.ru) построен с нуля за один день: 50+ коммитов, 27 страниц, JSON-LD на каждой, Pagefind поиск, hybrid Astro 6 deploy с CI/CD и автоматическим rollback. Без subagent-driven подхода это было бы невозможно — лимит контекста одного разговора закончился бы на середине Phase 3. Делимся, как устроен паттерн координатор + рой специализированных subagent’ов.

Контекст

Классическое использование Claude Code — один длинный разговор с одним контекстом. Работает на маленьких задачах, но ломается на проектах с десятками файлов и несколькими тысячами строк: контекст переполняется, цепочки правок теряют связность, начинаются галлюцинации.

Anthropic в июле 2025 выпустил Subagents — отдельный инструмент Agent, который позволяет диспатчить подзадачу в свежий контекст и получить компактный результат обратно. Это меняет архитектуру разработки: координатор держит структуру проекта в голове, subagent’ы делают конкретные единицы работы.

Архитектура: координатор + специализированные subagent’ы

В нашем случае рой делился на три типа:

Research subagent’ы (3 параллельных)

Все три запущены одновременно одной отправкой. Полтора-два месяца ручной работы за 5-7 минут.

Content subagent’ы (последовательно)

Code subagent’ы (по фазам)

Координатор не пишет код руками вообще — он только пишет промпты, проверяет результаты, фиксирует решения и катит рефакторинги.

Параллельный dispatch (главная экономия времени)

Параллельный запуск через единичную отправку с несколькими Agent-вызовами:

// Псевдокод координатора (по факту это просто несколько tool-calls в одном сообщении)
await Promise.all([
  dispatchAgent({ name: 'research-A', prompt: '...' }),
  dispatchAgent({ name: 'research-B', prompt: '...' }),
  dispatchAgent({ name: 'research-C', prompt: '...' }),
]);

Если запускать последовательно — общее время = сумма времени каждого. Параллельно — максимум одного. На 3-4 subagent’ах экономия 60-75%.

Гоча: 4 параллельных subagent’а легко упираются в Anthropic rate-limit. Эмпирическое правило — 2-3 одновременно безопасно, 4+ — половина упадёт.

Идемпотентные промпты — выживание при сбое

Subagent может упасть на середине: rate-limit, API-таймаут, исчерпание контекста. Перезапуск с нуля — теряешь то, что он успел. Решение — писать промпты так, чтобы повторный запуск ничего не ломал и подхватывал сделанное.

Конкретные приёмы:

# 1. git add -A в конце захватит всё, что субагент успел сделать
git add -A
git commit -m "..."

# 2. Файлы создаются через Write (overwrite), не Edit — повторный запуск перезаписывает
Write({ file_path: '...', content: '...' })

# 3. Проверка существования "что уже сделано" в начале
if [ -d /opt/webshturm-site ]; then echo "already initialized"; fi

В нашей сессии Phase 5a subagent упал на rate-limit после 8 tool-вызовов. Перезапустили с тем же промптом — он подхватил незакоммиченные изменения, докатил до конца, закоммитил всё одним блоком. Никакого ручного спасения.

Snapshot-rollback в CI как safety net

Subagent может выдать корректный, но логически сломанный код, который проходит тесты и build, но валит smoke на проде. Защита — снимок dist/ перед каждым деплоем + автоматический rollback при fail smoke.

Фрагмент .gitea/workflows/deploy.yml:

- name: Backup dist (snapshot for rollback)
  run: |
    ssh root@$HOST "cp -a /opt/webshturm-site/dist /opt/webshturm-site/dist.bak.$(date +%s); \
                    ls -td /opt/webshturm-site/dist.bak.* | tail -n +4 | xargs -r rm -rf"

- name: Deploy
  run: rsync -avz --delete app/dist/ root@$HOST:/opt/webshturm-site/dist/

- name: Smoke + rollback on fail
  run: |
    for route in / /services/ /cases/ozsm/ /blog/ /search; do
      STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://webshturm.ru${route}")
      if [ "$STATUS" != "200" ]; then
        ssh root@$HOST 'LAST=$(ls -td /opt/webshturm-site/dist.bak.* | head -1); \
                        rm -rf /opt/webshturm-site/dist; mv "$LAST" /opt/webshturm-site/dist; \
                        systemctl restart webshturm-site.service'
        exit 1
      fi
    done

Держим последние 3 снимка. При красном smoke — восстановление за 5-10 секунд. За 50 деплоев у нас не было ни одной ручной интервенции.

Что мы из этого вынесли

Ссылки