Григорий Любачев, директор по развитию корпоративного мессенджера «Пачка», участник АРПП «Отечественный софт»
За последний год ИИ-агенты стали привычным рабочим инструментом: с их помощью готовят спецификации, отчёты, договоры и презентации. Однако эффект от них распределился неравномерно. В свежем исследовании крупной консалтинговой компании 80% респондентов отметили рост личной продуктивности благодаря ИИ. Положительное влияние на прибыль компании увидели только 37%.
На мой взгляд, одно из главных объяснений этого разрыва в том, что агенты ускорили создание документов, но не их проверку и согласование.
Где возникает узкое место
Подготовить документ вместе с агентом сегодня можно за час. Дальше его нужно прочитать, понять логику решений, задать вопросы автору и дождаться ответа и новой версии. Эту часть работы по-прежнему выполняют люди — те же самые и в том же темпе.
К тому же документы разрастаются. Глава одной из крупных e-commerce-платформ описал новую форму «ленивой работы». Раньше так называли ситуацию, когда сделано слишком мало, теперь — когда сделано слишком много. Сотрудник получил от агента десять страниц и переслал их коллегам, не вчитываясь. Своё время он сэкономил, но разбираться теперь приходится другим.
Почему разработчикам проще
Первой с потоком артефактов, созданных с помощью ИИ, столкнулась разработка. По данным отраслевого исследования, при активном использовании ИИ медианное время проверки кода выросло в 5,4 раза. Отрасль отвечает автоматизацией: линтерами (анализ кода – ред.), тестами, агентами-ревьюерами, возможностью откатить изменения. В одной из ИИ-лабораторий, где агент проверяет почти каждое изменение кода, доля изменений с содержательными замечаниями выросла с 16 до 54%.
У юристов, кадровых служб и продуктовых команд таких инструментов нет. Для договора не существует линтера, для регламента — кнопки «откатить». Их проверка — это переписка и ожидание.
Что теряется между автором и проверяющими
Мы столкнулись с этой проблемой в собственной разработке, когда перешли к подходу, при котором каждая новая функция начинается со спецификации (spec-driven development, SDD). Автор готовит её вместе с агентом. Тот изучает кодовую базу и базу знаний, задаёт десятки уточняющих вопросов, и примерно за час появляется документ на десять страниц. Спецификаций стало в разы больше, а каждую по-прежнему проверяет человек.
Ключевой вывод оказался неочевидным. Самое ценное в этом процессе — не итоговый документ, а диалог, из которого он вырос: рассуждения автора, отброшенные варианты, ограничения. Всё это остаётся в рабочей сессии автора с агентом, а ревьюер видит только результат. Поэтому каждый его вопрос уходит автору: тот возвращается в сессию, уточняет у агента и пересказывает ответ. Уже обсуждённое обсуждается повторно. В нашем случае исправленная версия после замечания появлялась через 2,5–5,5 часа.
Отсюда простая идея: проверяющему нужен доступ не только к документу, но и к контексту, в котором он создавался. Реализовать эту идею можно по-разному. Можно приложить к документу журнал принятых решений, можно открыть коллегам историю работы с агентом, а можно дать им возможность задавать вопросы агенту автора напрямую. Мы проверили последний вариант: ревьюер обращался к агенту с вопросами и замечаниями, а автор следил за обсуждением и подключался при необходимости.
Эксперимент был небольшим — одна спецификация, один ревьюер, — но результаты показательны:
• путь от замечания до исправленной версии сократился до 11 минут (медиана);
• ответ на вопрос по документу приходил за 1–2 минуты;
• участие автора потребовалось в одном обращении из четырёх.
Вот как это выглядело в переписке:
Не только для разработки
Подход применим везде, где автор готовит документ с агентом, а вопросы ему задают коллеги. Юрист может спросить, почему в договоре выбрана именно эта формулировка, и попросить альтернативу. Продуктовая команда, пресс-служба и руководство могут сверить факты и тон пресс-релиза, не пересылая версии по кругу. Дизайнеры, редакторы и менеджеры — согласовать страницы сайта, макеты интерфейса или рекламные материалы, пока агент собирает версии по замечаниям.
С чего начать
Документы теперь создаются по-новому, и проверять их тоже нужно по-новому. Проверка, которая ждёт людей, съедает ускорение от агентов. Задача не в том, чтобы заменить проверяющих, а в том, чтобы убрать ожидание между ними.
Для первого шага достаточно пилота на одном типе согласований:
• выбрать документы, вокруг которых идёт настоящее обсуждение, а не рутинные заявки;
• замерить текущий срок согласования и время, которое тратят участники;
• дать проверяющим доступ к контексту подготовки документа в любой удобной форме и сравнить результаты.
Такой пилот нейтрален и измерим: время ожидания и число обращений к автору легко посчитать до и после.
Компании, которые научатся проверять так же быстро, как создают, получат от ИИ-агентов тот эффект, который большинство пока видит лишь в личной продуктивности сотрудников.
