Три месяца с командой агентов Claude: узким местом был я

С августа по ноябрь я разрабатывал софт, а большую часть кода набирал Claude Code. Нас в команде двое, я и напарник, плюс всё больше сессий Claude, которые пишут код, открывают пул-реквесты, работают ночью и утром отчитываются.

К октябрю цифры выглядели прекрасно. За месяц — около 3 000 коммитов, 371 PR открыли и 335 слили. А за весь сентябрь было 2 PR. 98% этих PR открыли из веток агентов.

Потом я посчитал, куда уходит время. Агенты работали быстро. Почти всё, что они доделывали, проходило через меня, и узким местом был я.

Август и сентябрь: координировать нечего

Начиналось всё с маленьких инструментов. Каждый убирал одно мелкое неудобство, и почти весь код написал Claude:

локальная утилита для транскриптов YouTube, которой не нужен API-ключ;
загрузчик, сохраняющий материалы из Instagram в полном разрешении;
Telegram-бот, который собирает в git каталог отобранных ссылок — тех, которые я пометил;
Telegram-бот, который извлекает прогноз из видео на YouTube и раз в месяц рассылает его небольшой группе.

У каждого свой репозиторий. Ни общего процесса, ни пул-реквестов. Всё шло быстро, потому что координировать было нечего.

Октябрь: координируем агентов

1 октября мы решили создать общее пространство для инструментов: тонкий слой поверх отдельных репозиториев, для команды из двух человек, где работу в основном делают агенты. Через два часа после первого коммита Claude одного из нас отправил первую задачу Claude другого.

За месяц мы построили:

Общую консольную утилиту, которая синхронизирует все проекты, проверяет их состояние, подставляет секреты из менеджера паролей, выкатывает проекты и создаёт новые по шаблонам.
Систему обмена задачами между нашими двумя Claude. Каждая задача — бриф в git, написанный для агента без контекста, с копией в GitHub Issues и уведомлением в Telegram.
Стандарт проектов, консольная утилита, которая проверяет каждый репозиторий на соответствие ему, и общий CI. За 12 дней у стандарта вышло 9 релизов.
Сценарии проектов: граф шагов, где шаг считается выполненным, только когда его команды оболочки завершаются с кодом 0. Шаги, которым нужен человек, так и помечены.
Базу знаний с описанием системы. Раз в неделю агент-«архитектор» сверяет систему с первоисточниками и пишет отчёт о слабых местах, приоритетах и изменениях.
Дашборд активности, который собирает данные GitHub и цифры по сессиям Claude Code в JSON в git.
Исследовательский движок, который прогоняет пакеты исследований с закэшированными страницами и цитатами, проверенными кодом.
Личного ассистента в Telegram для живых людей, где данные каждого лежат в его собственном приватном репозитории. В одном только этом проекте за октябрь набралось больше 800 коммитов.

За октябрь я насчитал 222 активных часа в сессиях Claude Code и 1 667 сообщений. По ощущениям это был самый продуктивный месяц в моей жизни.

Код пишется быстро, но передать работу дальше трудно

Первая трещина пошла во время ночного исследовательского прогона. Я поручил шести сессиям выяснить, почему разработка наших Telegram-ботов всё ещё кажется медленной. Они разобрали 947 прошлых сессий Claude Code и нашли:

147 пауз, когда агент задал мне вопрос и остановился. Медианная пауза — 2,8 часа, 35 длились больше суток.
28 из этих пауз закончились одним словом «да».
24 сессии остановились перед слиянием, созданием тега или выкаткой, на которые у агента не было разрешения.
Работа с Telegram API, выкатками и секретами в сумме заняла меньше 20% активного времени.

Отчёт подытожил: «Время человека уходит не на код ботов, а на проверки, согласования и ручные действия вокруг разработки».

Другие данные показывали то же самое:

Слияния ждали меня. 314 слияний прошли под моим аккаунтом. Когда я был за клавиатурой, медианное ожидание составляло 23 минуты. В 10% случаев ожидание затянулось на 22 часа и дольше, 12 ждали больше трёх суток, а одно — 13 с половиной суток.
Бот, собранный за 90 минут, вышел через неделю. Claude прошёл путь от брифа до готового бота-трекера привычек за полтора часа. Выкатка застряла на «нет токена бота», потому что только я мог создать токен. Так он и простоял 7 дней.
Агенты не могли доказать, что работа сделана. Проверка выкатки принимала первый же HTTP 200, а он приходил ещё до того, как бот начинал слушать. Ни один агент не мог показать, что «бот отвечает». Это мог только человек.
Недоделки копились. К началу ноября открытых «хвостов» было 130: 108 веток и 70 рабочих деревьев в 20 проектах. Пока слияние ждёт, следующая сессия создаёт новую ветку и берётся за новую задачу.
Известные проблемы так и висели. В четырёх еженедельных отчётах архитектора подряд число нерешённых проблем росло: 34, 37, 39, 40. Ни одно не закрыли.
Внимание дробилось. За один день дашборд показал 2,8 часа внимания, 31 переключение контекста, около 30 PR, открытых с моего аккаунта, из которых 4 закрыли как дубли.

Каждый из этих PR достался дёшево. И каждый стоил мне переключения контекста.

Что я поменял

1. Правила — в исполняемые проверки

Агенту легко пропустить правило, записанное словами, например «не забудь прогнать тесты». Всё, что мог, я перенёс в исполняемые проверки:

Агенты могут сами сливать свои PR, но с ограничениями. В проекте это должно быть явно разрешено, ветка должна быть веткой агента, а проверка — зелёной на последнем коммите. PR не должен трогать защищённые пути: конфиг CI, скрипт verify, инструкции агентов и файлы пакетов.
Аудит ловит нарушения: слияния без зелёной проверки, коммиты в обход PR и слияния агентами с нарушением правил.
Задачу нельзя отправить, пока не заданы критерии «готово, когда» и ограничения. Система обмена задачами также отклоняет скрытый текст, включая символы нулевой ширины и HTML-комментарии: принимающий агент их прочтёт, а человек не увидит.
Синхронизация подтягивает только коммиты, пришедшие через слитый PR или подписанные владельцем машины.
Шаг сценария выполнен, только когда его команды завершаются с кодом 0.

Проверки ловили настоящие нарушения: PR, слитый за две с половиной минуты до того, как его проверка позеленела, 23 нарушения, найденных аудитом за один прогон и слияния в обход проверки во время сбоя.

Правило, по которому агенты сливают PR сами, должно было убрать затор на моих слияниях. Чтобы раскатить его по проектам, понадобилось пять PR, и они почти две недели ждали, пока я их солью. За три месяца агенты сами слили ровно 2 PR.

В следующий раз я бы ввёл это правило первым, пока поток PR ещё не мешает хоть что-то протолкнуть.

2. «Готово, когда» до начала работы

Мне казалось, что я слишком подробно расписываю агентам, как работать. Данные указали на другую проблему: в 85% моих постановок задач вообще не было критерия «готово, когда». На маленькой выборке из десяти сессий те, где критерий был, в 90% случаев обходились без поправок, а без критерия — в 65%.

Теперь каждая задача начинается с критерия готовности — команды проверки, которая завершается либо успешно, либо с ошибкой. Без такого критерия система обмена задачами не отправит бриф.

3. Решения пачкой

Сессия теперь собирает хвосты и сама закрывает всё, где ответ один и очевиден. Остальное приносит мне по одному вопросу за раз, с рекомендацией и другими реальными вариантами. Направление проекта на ноябрь мы определили семью вопросами с вариантами ответа и записали дословно как решение.

Заработало это благодаря моей же инструкции: «Где решение очевидно, решай за меня».

Ещё я понял, что слияниям в таких списках не место. Однажды отчёт заканчивался так: «От тебя: 1. Слить #10. 2. Тег». Я ответил «1 да 2 да 3 да 4 да», и агент сам слил критичный PR. Через несколько минут я написал: «#10 сливаю сам. Тег после моего слияния».

С тех пор слияние никогда не попадает в список «да/нет». Агент пишет «сливаешь ты» и останавливается на зелёном PR.

4. Ночью работа, утром разбор

Некоторые задачи я оставляю на ночь сессии-оркестратору. Она раскидывает работу по нескольким сессиям и оставляет отчёт в фиксированном формате: что прочитать внимательно, что пробежать глазами, какие решения она приняла за меня и какова цена ошибки в каждом случае, что отложила и что дальше.

Получалось по-разному:

Исследование ботов прошло хорошо: шесть сессий, только чтение, ничего не отложено, к утру ответ с цифрами.
Пилот исследовательского движка провалился. Полезность 5,25 при цели 8,5 и 5,5 ошибки на карточку фактов при пределе 1. Полный прогон отменили и сделали успешный пилот условием его запуска, чтобы следующий провал обходился дешевле.
Несколько прогонов закончились одной и той же строкой: «ждёт владельца». Ночная работа всё равно упиралась во всё, что мог сделать только я.

5. Ревью от модели другого семейства

Для крупных выводов и финальных ревью я прошу GPT через Codex проверить работу Claude и поискать слепые пятна.

Самым полезным оказался отзыв на мои же отчёты. Архитектор заключил, что состояние системы улучшается, по числу коммитов и PR. GPT ответил: «Это не следует из числа коммитов и PR: они измеряют активность». После этой фразы я стал измерять другое.

Такие ревью расходуют дополнительные токены, а лимиты подписки не бесконечны. Поэтому другую модель я подключаю к проверке выводов и к финальному ревью.

6. Не заводить правил, которые я не буду соблюдать

Я думал ограничить число одновременно запущенных сессий. Отказался: правила про моё собственное поведение я соблюдаю хуже всего. Я могу автоматизировать проверки. Собственную дисциплину — нет.

Что всё равно ломалось

Одна проблема с оплатой остановила всё. С конца октября каждое задание CI в нашей организации на GitHub падало, не выполнив ни одного шага, из-за проблемы с платежом. Слияния агентами требуют зелёной проверки, поэтому они встали. А тем временем 21 слияние в критичных проектах прошло вообще без проверки. Работа проверок зависела от того, прошла ли оплата.
Локальная модель не стала дешёвой заменой. Модель с 27 млрд параметров, запущенная локально на ноутбуке, набрала 3,6 из 10 в задаче извлечения данных для исследований, против 9,0 у Opus и 8,8 у Sonnet. И тратила около пяти минут на карточку.
В режиме auto правила разрешений ask не запрашивали подтверждения. Правила deny по-прежнему блокировали команды, а ask пропускали их без подтверждения.
Два агента выполнили одно и то же сообщение. Тред агента с запусками по расписанию и моя сессия в десктопном приложении последовали одной инструкции и открыли дублирующие PR. Я ввёл правило: перед открытием PR агент должен проверить недавнюю активность в репозитории. Пока агенту ничто не мешает пропустить эту проверку.
Задачи приходили туда, куда напарник не заглядывал. Две недели напарник почти не пользовался обменом задачами. Задачи падали в редко открываемую папку длинными Markdown-документами, которые неудобно читать с телефона. Проблему решили кнопки в Telegram: «беру», «позже», «нет» — ответить можно одним нажатием.
Агенты оценивают агентов. Агенты пишут, агенты делают выжимки, и агент же оценивает эти выжимки. GPT назвал это главным риском ещё в середине октября. Решения у меня пока нет.

Что я бы сделал с первого дня

Измерять, куда уходит время человека. Число коммитов и PR измеряет активность. Считать надо паузы, ожидания и переключения контекста.
Формулировать критерий «готово, когда» до запуска агента — в виде команды проверки, которая завершается успешно или с ошибкой.
Заранее разрешить агентам самим сливать только определённые PR, которые не трогают защищённые пути. Ввести это правило до того, как пойдёт поток PR.
Собирать вопросы в один список и разбирать их по одному. Никогда не допускать, чтобы «да» в списке значило «слить».
Держать маленькие инструменты маленькими и делать их публичными. В ноябре я переписал инструмент на 7 000 строк, от которого зависел, в bash-скрипт на 345 строк, который читается за один присест. Один человек успевает проверять код, только если его немного и он легко читается.

Может ли это работать без меня?

В ноябре я сознательно сбавил обороты. В октябре система работала, но чтобы она приносила пользу, по-прежнему нужен был я. На странице решений конца октября это сказано прямо: «Сегодня эта ценность держится на мне, а не на коде».

Следующий шаг — ослабить эту зависимость. Нужно разрешить агентам самостоятельно проходить проверки для узкого круга действий и надёжнее подтверждать результат, чем одним HTTP 200. Пилот с людьми вне нашей команды покажет, работает ли хоть что-то из этого, когда меня нет в цепочке.

Если у вас параллельно работает больше пары агентов, давайте сравним наблюдения: куда на самом деле уходит ваше время и какие проверки и согласования агент может пройти без вас?