Параллельная работа затягивает: раз несколько агентов дали ускорение, кажется, что ещё пара даст ещё больше, и рука сама тянется запустить очередную сессию. Но у fan-out есть точка, после которой каждая новая ветка не добавляет скорости, а отнимает её - и умение вовремя остановиться оказывается важнее умения запустить. Именно этому умению учатся дольше всего.
Наивная установка - "параллелизм всегда хорош, а остановка это откат назад". Отсюда привычка на любое уточнение задачи плодить новую сессию, а на любую развилку в обсуждении - ещё одного агента. Кажется, что так исследуешь задачу шире и ничего не упустишь; на деле - размазываешь одну и ту же задачу по границам, которых не существует, и теряешь общую нить.
Ломается это ровно тогда, когда ветки перестают быть независимыми друг от друга. Есть набор сигналов, каждый из которых по отдельности говорит "хватит": задачи начали делить один изменяемый контракт; критерии приёмки поплыли и меняются на ходу; очередь review растёт быстрее, чем вы её закрываете; агенты повторяют одно и то же исследование; стоимость независимых вариантов уже превысила их ценность. Любого одного из этих сигналов достаточно, чтобы остановить fan-out, - дальше параллелизм работает против вас, а не на вас.
Почему именно эти сигналы, а не другие. Все они, по сути, об одном - об исчезновении той независимости, на которой параллелизм только и держится. Общий изменяемый контракт означает, что ветки на самом деле правят одно и то же, лишь с разных сторон. Плывущие критерии означают, что нет общей мишени, и каждый агент целится в своё понимание задачи. Дублирующееся исследование означает, что работа не разделена, а просто размножена. Как только независимость исчезла, каждая лишняя ветка лишь множит то, что придётся потом сводить вручную.
Профессиональный ход после стопа - не бросить наработанное, а собрать его в одно место. Собранное несколькими сессиями складывают в один Space - контейнер, где под одну задачу сведены сессии, pull request-ы, файлы и общий накопленный контекст, так что новый агент входит в курс дела без пересказа с нуля. На этом общем материале человек принимает архитектурное решение, обновляет план и запускает уже одну интеграционную ветку вместо десятка расходящихся. Space превращает разрозненные выходы в общий контекст, а не в кучу конфликтов.
Отдельно стоит сказать о дублировании сессий. Duplicate session уместен для действительно альтернативной гипотезы: два принципиально разных подхода к решению, которые честнее проверить порознь и затем сравнить по результату. Но плодить дубль на каждое мелкое уточнение формулировки - значит превращать инструмент сравнения гипотез в способ расфокусировать одну задачу на ровном месте. Это инженерная граница применения, а не запрет продукта: дубль оправдан развилкой в самом замысле, а не в словах, которыми задачу описали.
Цена незамеченного вовремя стопа вполне конкретна. Расходящиеся ветки на общем контракте дают конфликтующие diff-ы, которые кто-то потом сводит руками, теряя часы. Растущая очередь review переносит узкое место с машины на человека, и оно там и остаётся. Повторное исследование жжёт токены на уже известное, ничего не добавляя к результату. В сумме параллелизм, который давно перестал экономить, начинает стоить и времени, и внимания, и денег - и тем дороже, чем позже его наконец остановили.
Обратная сторона правила столь же честна: пока ни одного из сигналов нет, параллелизм оправдан, и тормозить его из одной осторожности не нужно. Независимые артефакты, стабильные критерии приёмки, управляемая очередь review и не пересекающееся исследование - это признаки, что ветки всё ещё работают на вас и делят задачу по-настоящему. Стоп - это ответ на конкретный сработавший сигнал, а не общая боязнь fan-out как такового.
Проверять, держится ли ещё параллельная работа, стоит по короткому и жёсткому контролю. У каждой сессии - ровно один владелец результата. Файлы или worktree между ветками не конфликтуют. Есть общий acceptance contract, единый для всех. Назначен человек, принимающий финальный merge. Пока все четыре пункта выполнены, ветки независимы и параллелизм законен; как только хоть один из них поплыл - это и есть сигнал сводить работу в Space и возвращать решение человеку, а не запускать ещё сессию.
Типичные провалы здесь - всегда о пропущенном стопе. "diff-ы не сходятся" - ветки давно делили один контракт, а fan-out при этом продолжали. "review не успевает" - очередь неуклонно росла, но новые сессии всё запускали по инерции. "агенты ходят по кругу" - повторяли одно исследование, потому что его не свели в Space вовремя. Признак один во всех случаях: параллелизм держали как самоцель, а не как средство с чётким условием применимости. Знать сигналы стопа и сводить работу в Space по первому же из них - и рой агентов не превращается в болото.