Parallel Agent Dispatch

Зачем это отдельная тема

Открыть пять сессий и раскидать по ним задачи выглядит очевидным способом ускориться, и на этом обсуждение обычно кончается. Между тем каждая сессия требует переключения, каждая возвращается за решением, и суммарное ускорение может оказаться нулевым или отрицательным при полной субъективной уверенности, что «что-то происходит». Крайняя форма описана как отдельный вид выгорания: несколько месяцев работы в несколько потоков дают падение когнитивных способностей, а не рост выработки.

Существенно то, что это не новая задача. Человек, раздающий работу нескольким исполнителям и принимающий результат, — предмет теории массового обслуживания, и вопрос «что улучшать первым» имеет там ответ, выводимый из параметров, а не из вкуса.

Человек здесь диспетчер, а не планировщик

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

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

Пятый параметр — стратегия выбора следующей задачи из очереди; о ней ниже отдельно.

Переделки — главный рычаг, и зависимость нелинейная

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

Практический вывод из этой формы важнее самих чисел: снижение с 90% до 70% даёт больше, чем с 50% до 30%. Оптимизировать надо худший тип задач, а не средний, и приемлемым уровнем называют 40–50% — выше него с типом задач надо что-то делать, а не терпеть.

Как снижать. Причины переделок разбираются по типам задач, а не вообще: смотреть, почему именно этот класс результатов уходит обратно. Источник данных — собственные журналы сессий; разбор дешёвой моделью даёт список типов задач и список причин, дальше по каждой причине ищется, чем её закрыть. Дальше причина закрывается тем, чем закрывается: правилом в файле инструкций, умением, инструментом, обратной связью, которую агент может получить сам (Harness Optimization — там же планка, отсеивающая правки, которые ничего не изменят). Любой формальный гейт — тест, линтер, проверка типов, критерий приёмки — закрывает одну или несколько причин переделки, и в этом его ценность измерима.

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

Ревью — второй рычаг, и пока идёт ревью, агенты стоят

Ревью — единственная точка, где занят человек и одновременно простаивают все агенты. Из симуляции: семь задач на семи агентах при ревью в одну минуту укладываются примерно в полтора часа; при четырёх минутах у человека появляется сплошная полоса ревью, и агенты ждут; при восьми минутах агенты перестают быть нужны вовсе.

Снижается это ускорением восприятия результата, а не сокращением внимания: плотность подачи на единицу площади. Схема вместо полотна markdown, диаграмма на декларативном языке с формальным валидатором, полноценный HTML-артефакт, где помещается больше и появляется интерактив.

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

Постановка — третий рычаг, автономность — четвёртый

Время постановки стоит примерно наравне с ревью, и уходит оно в основном на то, чтобы человек сам вошёл в контекст. Что его сокращает: параллельные субагенты, разбирающие кодовую базу одновременно вместо одного последовательного прохода; быстрые модели на этапе планирования; описание, где что лежит; режим интервью, когда агент опрашивает человека перед постановкой, — но вопросы стоит собирать пачкой, а не по одному за раз, иначе интервью само становится узким местом (Human in the Loop — бюджет уточняющих вопросов и критерий их допуска).

Время автономной работы — самый слабый из четырёх рычагов, но действующий: удвоение автономного времени в симуляции задействовало на два агента больше при неизменных остальных параметрах. Растёт оно детальной спецификацией с формальными критериями завершения и группировкой мелких однотипных правок в один заход.

Число агентов — не рычаг, а следствие зрелости

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

Правило простое: агентов добавляют, когда человек начал явно простаивать. Практический потолок на незрелой системе — три плюс-минус один; десяток и больше требует, чтобы работа по остальным четырём параметрам была уже сделана.

Токсичные задачи

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

Аналогия называет форму точно: трое подчинённых получают задачу за час и сутки работают сами, а четвёртый возвращается каждые пятнадцать минут, и каждый раз надо заново вникать, что он сделал. В симуляции десять задач на починку багов с задействованием четырёх агентов выполняются за то же время, что две токсичные задачи, на которых удаётся задействовать одного агента.

Из этого следует оценка, которую стоит помнить: 15% токсичных задач в потоке съедают около половины времени. И худший сценарий здесь не сама токсичная задача, а её неверная классификация: попав в поток как обычная, она останавливает всё, и причина остаётся невидимой.

Выходов три, и выбор между ними зависит от того, повторится ли задача:

• делегировать человеку, у которого обвязка настроена именно под этот класс;
• сделать руками — часто быстрее, чем объяснять агенту, и это нормальный исход, а не поражение;
• сделать потоковой — если задача повторяющаяся, то есть снизить ей время ревью и вероятность переделки теми же средствами, что и всем остальным типам.

Стратегия выборки: группировка по типу

Порядок, в котором задачи берутся из очереди, — самостоятельный параметр, и разница между стратегиями измерима. В той же симуляции смена стратегии с «первый вошёл — первый вышел» на группировку по типу сократила общее время выполнения восьми задач с примерно шести с половиной часов до четырёх с небольшим — без единого изменения в самих задачах или в обвязке.

Причина в стоимости переключения контекстов: внутри одного типа она близка к нулю. Практический размер батча — три-пять однотипных задач подряд.

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

Что модель намеренно не считает

Два параметра исключены сознательно, и обе причины стоит знать, потому что они и есть границы применимости.

Токены не учитываются. Довод: они дешевеют, доступных обвязок становится больше, а на этапе освоения экономия вредна — она гасит эксперименты. Довод спорный и зависит от того, кто платит; если бюджет ограничен жёстко, стоимость надо вносить в модель отдельной осью (Unit Economics AI).

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

Чего эта модель не доказывает

Числа выше получены из симуляции, а не из замера на людях: они показывают форму зависимости, а не значения для конкретной команды. Параметры каждый считает свои, и именно в этом польза — модель отвечает не «сколько у вас будет», а «что чинить первым при таких параметрах».

Из внешних подтверждений есть одно и с другой стороны — упомянутый выше замер с приростом около процента после учёта переделок. Этого достаточно, чтобы принять порядок рычагов всерьёз, и недостаточно, чтобы считать сами коэффициенты перенесёнными.

Связано с

• Human in the Loop — ревью и уточняющие вопросы как канал, через который человек становится узким местом
• Harness Optimization — чем чинить найденную причину переделок и какая правка вообще заслуживает заведения
• Agent First Repository — среда, снижающая переделки конструкцией: проверки, которые агент запускает сам
• Quality Metric Design — как формулировать критерий, чтобы измеряемое соответствовало нужному
• Bounded Tool Output — плотность подачи результата, только со стороны контекста агента, а не глаз человека
• Unit Economics AI — ось стоимости, которую эта модель выносит за скобки