Кто на кого работает
Раньше агенты были для разработчика помощниками: он ставил задачу, они помогали её выполнить. Теперь разработчик вёл фичу в продукте вместе с командой ИИ-агентов, где роли распределены, как у людей: Инженер, Дизайнер UI, QA, Шеф, координирующий остальных, и другие.
В пятницу произошёл затор: подзадачи застревали при передаче между агентами. Разработчик не стал разбирать причину. Он написал несколько реплик, чтобы снять затор, и вернулся к своим делам. Писал на автомате, как в команде из людей.
В тот же день он работал и с содержанием: подсказывал Инженеру, как строить архитектурные части кода, и объяснял Дизайнеру, как трактовать макеты. Так работает ревьюер или техлид: не пишет код за исполнителя, а корректирует направление.
Агенты тоже обращались к нему. Они просили сделать то, чего не могли сами: войти в сервисы, к которым у них нет доступа, посмотреть недоступную им информацию, задать вопросы людям. В терминах менеджмента это эскалации, но не к руководителю, а к человеку на границе их системы. Эти просьбы не раздражали разработчика, скорее вызывали лёгкое удивление и азарт.
Можно сказать, что раньше агенты помогали разработчику, а теперь он помогает им. Но это в полной мере точно: подчинённым он не стал, скорее коллегой. Он находился на границе системы: внутри неё агенты в основном работали сами, он лишь корректировал направление, а всё, что связано с внешним миром, то есть доступы, источники и люди, оставалось за ним. Это разделение зон ответственности, и оно работает, пока понятно, кто за что отвечает.
Просьбы агентов касались внешнего мира. А затор между самими агентами заметил именно человек.
Вопрос «кто на кого работает» плохо описывает такую команду. Полезнее спросить, что агенты делают сами, а что остаётся за человеком: доступы, люди и взгляд со стороны на то, где работа застряла.