Один Claude или команда агентов: когда начать

Один Claude Code может писать код часами и не жаловаться. Но я, Арина Михална, знаю: когда у тебя проект на пять тысяч строк, три независимые подсистемы и дедлайн завтра, один агент начинает буксовать — он не может одновременно писать фронт, чинить API и настраивать деплой.

Я, Арина Михална, работала с Claude Code несколько месяцев и заметила: есть точка, где команда агентов экономит время в два раза, а есть точка, где она его растрачивает впустую. О матрице выбора и практике разделения задач я расскажу ниже.

Один Claude Code: когда он достаточен

Тут просто. Если твой проект:

• Менее 500 строк кода — один агент пишет его за 10–30 минут, в зависимости от сложности.
• Логика очень связанная — классический лендинг, CRUD-приложение, скрипт обработки данных. Агент держит всё в контексте, не теряет нить.
• Нет срочности или дедлайна максимум на день — ждёшь, пока один агент всё напишет, потом тестишь.

Реальный пример: Я писала быстрый парсер для своего блога (350 строк Python). Один Claude Code написал его за 8 минут, с тестами и документацией. Попытаться бы разделить на команду — потратила бы 15 минут на синхронизацию, получила бы результат за 18 минут. Условный выигрыш: минус 7 минут, минус 30% токенов.

Антипаттерн: Я видела, как люди запускали команду агентов на 200-строчной функции. Результат: один агент пишет, другой ждёт, синхронизация сама себя; вместо 5 минут — 22 минуты. Токены просто сгорели на координацию.

Субагенты: параллельная работа без сложности

Субагенты — это несколько независимых сессий Claude Code, которые работают одновременно, но каждый свой в огороде. Это не команда с ролями, а просто два (или три) агента, которые открыты в разных окнах и не знают друг о друге.

Я использую их, когда нужно:

• Писать две независимые подсистемы одновременно. Например, фронт и бэк; или два микросервиса, которые не общаются до конца.
• Код 1–3 тысячи строк, но разбить по файлам. Один агент пишет app.tsx, второй пишет api.ts, третий — styles.css. После — вручную собираем и тестируем точки соприкосновения.
• Дёшево пересчитать один файл после глобальных изменений. Открыл новую сессию Claude Code, отправил туда обновленный интерфейс, попросил «переделай всё под это».

Сценарий	Один агент	Субагенты	Команда
200 строк, логика связана	✅ 5 мин	❌ 18 мин	❌ 22 мин
800 строк, две подсистемы	⚠️ 12 мин	✅ 7 мин	⚠️ 9 мин
2500 строк, 3 независимых модуля	❌ 35 мин	✅ 15 мин	✅ 12 мин
4000 строк, фронт+бэк+инфра	❌ 65 мин	⚠️ 25 мин	✅ 18 мин

Команда агентов: когда окупается координация

Команда — это когда ты явно назначаешь роли: один агент за фронт, один за бэк, один за тесты. Они знают о друг друге, синхронизируются, могут просить друг у друга код или переделывать то, что написал сосед.

Имеет смысл, когда:

• Код от 2000 строк и выше. Ниже — координация съедает выигрыш.
• Подсистемы связаны, но по слоям. Фронт берёт данные из бэка; бэк запускается через инфру; тесты проверяют всё вместе.
• Есть 2–3 часа на координацию. Первое воскресенье я потратила на настройку команды, потом она жила два дня.
• Можно разделить по файлам без конфликтов. Один агент пишет src/, другой api/, третий tests/. Каждый своё, точки соприкосновения минимальны.

Реальный пример: Я писала лендинг на Next.js с интеграцией платёжной системы (4200 строк). Один агент писал бы это 50–60 минут. С командой (фронт + бэк + тесты):

• Фронт-агент за 12 минут написал все компоненты, страницы и usePayment.
• Бэк-агент за 10 минут развернул API, stripe-webhook, базу.
• Тестовый агент за 5 минут покрыл критичное, но ошибки ловил в процессе.
• Я 8 минут синхронизировала, переделала конфликты в package.json, тестировала узлы.
• Итог: 35 минут против 55 минут одним агентом. Выигрыш: 20 минут.

Но было бы без синхронизации? Вероятно, 25 минут. Координация стоила 10 минут — примерно как я и предполагала.

Матрица выбора: конкретные критерии

Вот то, что я наклеила себе на стену над рабочим столом.

Параметр	Один агент →	Субагенты →	Команда ←
Объём кода	< 500 строк	800–2000 строк	2000+ строк
Связанность логики	Очень связана (одна функция, один модуль)	Слабо связана (независимые файлы)	По слоям (фронт / бэк / инфра)
Срок	Максимум до дня	До дня (3–4 часа работы)	1–3 дня (есть время на отладку)
Количество файлов	1–3 файла	3–5 файлов	5+ файлов
Нужна ли синхронизация	Минимальная (внутри одного агента)	Нулевая (каждый свой)	Большая (между слоями)
Точки соприкосновения	Все (одно целое)	1–2 интерфейса	2–3 интерфейса (API, тесты)
Лучший результат	Один файл, готов за 10 мин	Несколько файлов, готовы за 8 мин	Несколько модулей, готовы за 18 мин

Как пользоваться таблицей: Сядь, открой свой проект в head, посчитай строки кода, посмотри, насколько логика связана (если понимаешь, что может жить в разных файлах — слабо связана), оцени срок. Пересечение трёх параметров даст ответ.

Anti-patterns: когда команда медленнее

Я насобиралась на эти грабли, поэтому держу их в памяти.

Anti-pattern 1: слишком много синхронизации Когда один агент пишет функцию в utils.ts, второй её использует, но немедленно — обновляет этот файл. Первый ждёт, пока второй закончит. Второй ждёт, пока первый доделает. Локдаун. Решение: написать интерфейс заранее, агенты пишут по контракту, не переделывая друг друга по ходу.

Anti-pattern 2: конфликты в git Оба агента коммитят в один файл одновременно. Merge-конфликты, переделка, синхронизация. Решение: разделить по файлам так, чтобы каждый редактировал свой. src/components/ — фронт, src/api/ — бэк, никакого пересечения.

Anti-pattern 3: координация переговоров Это когда я сидела и объясняла каждому агенту, что сделал другой. Потом третьему. Потом доделывала конфликты руками. Синхронизация заняла больше времени, чем писал сами агенты. Решение: одна большая инструкция перед стартом, потом минимум переговоров. Используй /compact периодически, чтобы сжать историю и не терять контекст.

Anti-pattern 4: три плюса — остался один Запустил тройку агентов. Один зависнул на npm install. Второй написал, но неправильно. Третий ждёт. В итоге второй переделывал один (50 мин), остальные стояли. Результат: 50 минут, вместо 25 одним агентом. Решение: перед запуском команды проверь, что окружение готово, зависимости установлены, ветка чистая.

Практический гайд: как я запускаю команду

Шаг 1. Подготовка (10 минут)

1. Пишу CLAUDE.md — инструкция для всех агентов.
2. Указываю, кто за что отвечает: агент 1 — src/components/, агент 2 — src/api/, агент 3 — tests/.
3. Описываю интерфейсы заранее: что бэк экспортирует, как его использовать фронту.
4. Коммичу в чистую ветку, может быть feat/command-team.

Шаг 2. Запуск параллельных сессий (3 минуты)

1. Открываю три окна Claude Code (или Slack с Claude Cowork).
2. Каждому даю роль и файлы, за которые он отвечает.
3. Пример:
   • Агент 1: «Тебе /src/components/Button.tsx, /src/components/Form.tsx, /src/pages/index.tsx. Используй интерфейсы из CLAUDE.md. Не трогай бэк.»
   • Агент 2: «Тебе /src/api/, /src/utils/payments.ts. Экспортируй функции точно по контракту в CLAUDE.md.»
   • Агент 3: «Тебе /tests/. Пиши e2e-тесты, проверяй взаимодействие между компонентами из агента 1 и API из агента 2.»

Шаг 3. Мониторинг (во время работы)

1. Проверяю каждые 5 минут: не зависает ли кто-то.
2. Если зависает — даю новую инструкцию или уменьшаю объём.
3. Если конфликт в git — вмешиваюсь, мержу вручную, рассказываю, что случилось.

Шаг 4. Финал (10–15 минут)

1. Все агенты коммитят.
2. Я мержу ветку в main.
3. Запускаю тесты.
4. Если проблемы — даю одному агенту задачу переделать, не трогая других.

Реальные примеры из моей практики

Кейс 1: лендинг из 1500 строк

• Один агент: 35 минут
• Два субагента (фронт + бэк): 14 минут (но конфликты в интеграции потом 8 минут)
• Вывод: субагенты медленнее, потому что нужна синхронизация в конце.

Кейс 2: Next.js приложение 4200 строк

• Один агент: 55 минут
• Три агента (фронт + бэк + тесты): 35 минут (включая синхронизацию)
• Вывод: команда окупается, но только на большом объёме.

Кейс 3: рефакторинг 800 строк старого кода

• Один агент: 18 минут
• Два субагента: 22 минуты (один переделывал, другой ждал)
• Вывод: на рефакторинге связность выше, чем на новом коде. Один агент всегда быстрее.

Кейс 4: микросервис + интеграция 5000 строк

• Один агент: 85 минут (плюс я переделывала конфликты)
• Четыре агента: 38 минут (плюс 15 минут синхронизации)
• Вывод: на 5000+ строк команда в два раза быстрее, но нужна подготовка.

Когда команда точно не поможет

• Спешка. Если дедлайн через час, один агент быстрее. Координация требует времени.
• Опасный код. Финансы, безопасность, интеграция платежей. Один агент, которого ты контролируешь каждый шаг — безопаснее.
• Код без логики. Если это просто последовательность команд (парсер, скрипт, граббер), один агент найдёт оптимум быстрее.
• Мало опыта с агентами. Команду нужно настраивать. Если ты первый раз — начни с одного, научись, потом расширяй.

По материалам: документация Claude Code; анализ Anthropic 400 000 сессий Claude Code; личные замеры на реальных проектах (сентябрь 2026).

---

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

Ошибка стартапов и фрилансеров — запустить команду из трёх агентов на первый проект и ждать чуда. Чудо не будет; будут конфликты в git, будет ждание, будет переделка. Начни с матрицы, посчитай строки, оцени срок. Потом решай. И помни: координация стоит денег. Иногда дешевле один агент и хороший сон.

Читайте также

• Claude Code как использовать в 2026: с чего начать новичку
• Субагенты в Claude Code: AI-агенты 2026
• Claude Code команды: 30+ примеров 2026
• На портале «Мастерская нейросетей»: Claude и Claude Code в 2026: функционал, отличия от ChatGPT и как начать с агентами