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

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

Автор сравнивает разработчика с «GIL» в системе AI Agent — тем самым блокировщиком в одном потоке, который ограничивает итоговую пропускную способность параллельной системы. Несколько агентов могут работать одновременно, но как только дело доходит до архитектурных решений, ревью кода и разрешения конфликтов, все должно снова пройти через мозг разработчика. Таким образом, больше агентов не обязательно означает больший выход продукта, это может лишь удлинить очередь задач на проверку и погрузить разработчика в более частые переключения контекста и когнитивную усталость.

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

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

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

Ниже представлен оригинальный текст:

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

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

Недавно я участвовал в панельной дискуссии на Google I/O вместе с Ричардом Серотером, Аджей Хаммерли и Сиерой Яспан, где мы обсуждали, как сейчас выглядит разработка ПО и как она может развиваться дальше. Под конец Ричард спросил нас: какую одну вещь разработчики, послушав нас, должны вынести для себя и изменить?

Я озвучил мысль, которая не дает мне покоя последние несколько месяцев: ощущение, что ты очень занят, отнюдь не равно реальной продуктивности. Вы можете одновременно запустить 20 агентов и чувствовать себя загруженным до предела. Но это не значит, что вы выполнили работу, соответствующую 20 агентам.

Ранее в той же дискуссии Ричард дал этой проблеме название. Он сказал: «То, о чем ты сейчас говоришь, и есть налог на оркестрацию. Тебе не удастся успешно управлять 20 агентами в своей голове».

Он был абсолютно прав. Я хочу разобрать эту концепцию более полно, потому что это не вопрос самодисциплины, а вопрос архитектуры.

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

Асимметрия, которую не учитывают

В рабочем процессе с агентами существует скрытая асимметрия.

Запустить агента очень дешево. Достаточно одного нажатия клавиши или одного промпта. Но завершить цикл работы агента совсем не дешево. Кто-то должен проверить, правильный ли результат он вернул, и согласовать его с изменениями, внесенными другими агентами.

Этот кто-то — вы. И вас всего один.

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

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

Вы — тот самый ресурс в одном потоке

Если вы писали параллельный код, у вас уже есть интуиция для понимания этой проблемы. Просто раньше вы применяли эту интуицию не там.

В Python есть глобальная блокировка интерпретатора, или GIL. Вы можете создать сколько угодно потоков, но в любой момент времени только один поток может выполнять байт-код Python, потому что все они должны сначала захватить эту блокировку.

Вы — GIL для ваших AI Agent.

Они все могут работать одновременно. Но как только их работа требует настоящего понимания архитектуры системы или разрешения конфликтов слияния, она должна сначала захватить эту блокировку. А эта блокировка всего одна, и она у вас.

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

В разработке с агентами эта последовательная часть — суждение.

Запуск 8 агентов не ускорит время вашего принятия решений. Он только удлинит очередь задач, ожидающих вашей обработки.

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

Добавление агентов оптимизирует ту часть, которая изначально не была ограничением. Настоящее ограничение — этап ревью, и пропускная способность всей системы в точности равна пропускной способности этого этапа.

Налог на оркестрацию — это структурный разрыв между производственной мощностью агентов и тем, что вы реально можете слить воедино. Он возникает, когда вы заставляете ресурс в одном потоке управлять параллельной системой.

Упорством структурный потолок не преодолеть

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

Оба эти чувства абсолютно реальны, и они происходят из одной и той же причины.

У этой усталости есть очень конкретный источник: это ощущение, когда последовательный процессор постоянно загружен на 100% без какого-либо запаса.

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

ЦП может сделать это за микросекунды, и даже тогда архитекторы стараются избегать частых переключений. Вам же на это требуются минуты, и контекст никогда не восстановить идеально.

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

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

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

Вы либо платите этот налог осознанно, либо позволяете ему незаметно разрушать ваше понимание собственной системы.

Проектируйте свое внимание как систему

Поэтому вы должны относиться к своему вниманию как к дефицитному последовательному ресурсу.

Вы же не стали бы проектировать распределенную систему, совершенно не думая об узких местах. Так проявите такое же уважение к своему мозгу.

Вот несколько методов, которые реально работают для меня:

Расширяйте команду агентов в соответствии со способностью к ревью, а не с возможностями интерфейса.

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

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

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

Классифицируйте задачи.

Когда Ричард спросил меня, как я с этим справляюсь, я упомянул этот метод. Я делю задачи на две кучки.

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

Вторая — сложные задачи, где самой работой является принятие решения. Например, странный баг или проектирование архитектуры.

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

Пакетное ревью.

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

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

Используйте эту блокировку только для принятия решений.

Не тратьте свой мозг на то, что машина может проверить сама. Пусть агенты пишут проходящие тесты или генерируют скриншоты.

Пусть они сами докажут те 80% скучной, но проверяемой части. Тогда ваше дефицитное внимание потребуется лишь для тех 20%, которые действительно требуют человеческого суждения.

Защищайте свое последовательное время.

Узкому месту нужно ваше лучшее время, а не обрывки, оставшиеся между проверками агентов.

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

Оркестрация — это не настоящая работа. Это лишь накладные расходы вокруг работы.

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

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

Занятость не равна продуктивности

Это чрезвычайно важно, потому что такой сценарий неудачи для вас самих практически невидим.

20 запущенных агентов создают ощущение «взрыва продуктивности». Панель управления забита, все движется. Но это ощущение уже оторвано от реального слияния качественного кода в основную ветку.

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

Сиера упомянула исследование Маргарет-Энн Стори о долгах. Мы говорили и о техническом долге, и о когнитивном долге.

Налог на оркестрацию, который вы не заплатили, заставит вас накапливать оба этих долга одновременно.

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

Итак, настоящий вывод таков: запустить агента — не умение. Любой может запустить 20.

Настоящее умение — спроектировать систему вокруг того ресурса, который нельзя клонировать и нельзя распараллелить.

Этот ресурс — ваше внимание.

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