Comments 4
Написано, вроде, разумно. Но зачем так сложно? Ведь есть же уже куча процессных фреймворков. По-моему агент (даже если он про управление) - это просто "экзоскилет" уже существующего члена команды проекта. Какие могут быть правила для экзоскилета?
Это, собственно, один из главных вопросов.
У меня нет ощущения, что нужен ещё один «-изм» поверх PMBoK, PRINCE2, ISO и всего остального. Если агент - это просто экзоскелет существующего участника проекта, который по команде помогает писать, считать, напоминать и структурировать, то вы правы, никаких специальных правил тут почти не нужно. Это просто хороший инструмент.
Давайте на примере кодинг-агентов. Если взять самый простой уровень (автодополнение, подсказку по функции и т.п.) тогда да, это скорее экзоскелет. Такой усилитель разработчика. Он помогает писать быстрее, но сам не становится участником процесса разработки. Никаких особых правил тут действительно не нужно, кроме обычной инженерной гигиены.
Но кодинг-агент в современном смысле - это ведь уже не совсем «умная клавиатура». Он читает репозиторий, сам ищет, где менять код, сам предлагает архитектурный ход, пишет тесты, чинит пайплайн, открывает PR, иногда ещё и комментирует, почему сделал именно так. То есть он влияет не только на скорость рук разработчика. Он начинает влиять на саму логику изменений в системе. И вот в этот момент почти никто уже не говорит: «Да это просто экзоскелет, какие тут могут быть правила». Наоборот, сразу возникают вполне взрослые вопросы.
Что агенту вообще разрешено трогать? Что он может менять автоматически, а что только через review? Кто отвечает за уязвимость, если агент написал код убедительно, но плохо? Достаточно ли того, что тесты зелёные? Можно ли ему доверять миграции, рефакторинг, изменения в критических для безопасности местах? Нужен ли лог его действий? Нужен ли rollback по умолчанию?
То есть как только агент начинает не подсказывать, а действовать внутри процесса, правила почему-то становятся совершенно естественной темой. С управлением проектами, на мой взгляд, происходит ровно то же самое. Если агент просто помогает РП оформить протокол, собрать статус, напомнить о дедлайне и делает это всегда по одной и той же цепочке - это действительно экзоскелет. Но если он уже сам мониторит коммуникации, сам выделяет «важное», сам формирует сводную картину проекта, сам предлагает, что эскалировать, а что считать рабочим отклонением - это уже не просто усилитель. Это участник контура управления, пусть и без формальной ответственности.
А раз так, то и правила нужны примерно того же класса, что и у кодинг-агента. Не абстрактная бюрократия ради бюрократии, а довольно приземлённые вещи. Об этом концепция выше.
Поэтому мой тезис здесь довольно простой: не всякий агент требует новых правил. Но и сводить любого агента к «экзоскелету» уже не получается. С кодинг-агентами это стало видно раньше и нагляднее. С агентами в управлении проектами мы, похоже, подходим к той же точке.
Возможно вы правы. Со второго раза чтение концепции уже не так сложно дается. Но я все равно не смог осилить до конца. Впрочем я и pmbook тоже не с первого раза осилил )
Доброго времени. Мне ,концепцию читать было более интересно, чем манифест.
Манифест скорее для первого прикосновения к теме. Концепция - чтобы понять о чем собственно речь.
Мне показалось, что важность вопросов, выведенных на первый уровень концепции, не одинаковая. Например, место про типы сигналов. Не понял важность.
Но в целом, интересно. Захотелось прокомментировать несколько разделов и обсудить с авторами или просто заинтересованными людьми
Почему ИИ-агентам для управления проектами нужны общие правила