Обновить

ИИ-продакт — следующий уровень автономности или избыточная бюрократия?

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели8.3K
Всего голосов 3: ↑3 и ↓0+5
Комментарии4

Комментарии 4

Самая сильная часть кейса, на мой взгляд, - перевод словесного регламента в исполняемую механику. Это действительно убирает у модели возможность каждый раз заново трактовать процесс. Я бы добавил еще защиту на границе повторных запусков: стабильный idempotency key для продуктовой задачи и журнал уже выполненных внешних эффектов. Иначе watchdog или ретрай могут повторно создать коммит, отправить письмо, открыть задачу или запустить деплой, хотя предыдущий агент успел выполнить действие, но не записал финальный статус. Для оценки эффективности 350 закрытых задач тоже лучше дополнить стоимостью принятого изменения, долей доработок и откатов, cycle time и числом вмешательств человека. Интересно, учитываете ли вы повторные запуски и отклоненные результаты отдельно от успешно доставленных изменений?

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

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

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

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

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

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

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

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

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

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

Он не может самостоятельно:

  • менять назначение продукта или его целевую аудиторию;

  • выбирать между сопоставимыми продуктовыми вариантами, если у одного из них нет очевидного преимущества;

  • расширять круг доступа к рабочим системам или чувствительным данным и выдавать новые права;

  • совершать действия, требующие расхода реальных денег, если бюджет и границы такого расхода не были согласованы заранее;

  • совершать необратимые или юридически значимые действия без отдельного подтверждения человека.

При этом у него есть права:

  • запускать задачи из бэклога, которые включены в принятый план;

  • проверять работу системы вживую в заранее разрешённых контурах — например, отправлять тестовые запросы через мой Telegram от моего имени;

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

  • останавливать работу и блокировать выкатку результатов, которые технически корректны, но ухудшают пользовательский опыт или не решают задачу, ради которой создавались;

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации