Ещё недавно главный вопрос при внедрении искусственного интеллекта звучал примерно так: «Как это сделать?»

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



Ещё недавно главный вопрос при внедрении искусственного интеллекта звучал примерно так: «Как это сделать?». Как подключить модель к Jira, как дать ей доступ к GitHub, как написать агента, настроить MCP, собрать workflow и заставить всё это работать стабильно. Сегодня техническая часть стала заметно дешевле. Агента под конкретную задачу можно собрать за несколько часов. Модели умеют работать с инструментами, MCP стандартизирует доступ к внешним системам, фреймворки берут на себя оркестрацию, память и выполнение.

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

Именно поэтому мы пришли к модели: перед тем как строить агента, сначала нужно понять, где его вообще имеет смысл строить. Сейчас вокруг AI много разговоров про context engineering, agent harnesses, memory, orchestration и MCP. Всё это важно, но в основном отвечает на вопрос «как сделать агента эффективнее?». Нас больше интересует другой уровень: как сделать эффективнее процесс, частью которого становится агент? Потому что агент почти никогда не существует сам по себе. В процессе остаётся человек: кто-то ставит цель, кто-то принимает результат, кто-то отвечает за решение, кто-то должен понять, что произошло после выполнения. А вокруг них уже существуют Jira, Confluence, GitHub, почта, календарь, документы и другие рабочие инструменты.

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

Представим две команды. В первой разработчик открывает Jira и сразу понимает задачу. Acceptance criteria заполнены, документация актуальна, все изменения связаны с pull request, решения фиксируются. Создание отдельного агента, который будет «восстанавливать контекст задачи», скорее всего, даст небольшой эффект. Во второй команде задача выглядит так: «Добавить поддержку нового тарифа. Подробности обсуждали на встрече». Разработчик идёт в Confluence. Документ последний раз обновлялся восемь месяцев назад. После этого он ищет похожий pull request, пишет коллеге и в какой-то момент узнаёт, что часть решения обсуждали в чате, а архитектурное ограничение знает только один человек. Вот здесь уже появляется интересная точка для автоматизации. Не потому что «AI сейчас модный», а потому что существует повторяемая ручная работа: поиск, сопоставление, восстановление контекста, проверка связей, подготовка следующего действия.

Именно такие места сначала нужно научиться находить. Для этого мы используем понятие «контекстный долг». Контекстный долг — это издержки из-за разрозненной, устаревшей или недостающей информации внутри рабочего процесса. Например, разработчик ушёл в отпуск, и часть работы остановилась, потому что только он знает устройство конкретной области. Новичок несколько недель ходит по людям с вопросами, ответы на которые уже звучали раньше, но нигде нормально не зафиксированы. В Jira десятки задач без содержательного описания. Изменения в GitHub невозможно связать с задачей, ради которой они появились. Документация существует, но никто не уверен, можно ли ей доверять. Половина встречи уходит на восстановление предыдущих договорённостей.

Каждый такой случай сам по себе ещё не означает, что здесь нужен AI-агент. Но вместе они показывают места, в которых процесс требует большого количества ручного восстановления контекста. А это уже хорошие кандидаты для исследования. Самый простой вариант выглядел бы красиво: подключаем корпоративные системы, AI анализирует компанию и через пять минут выдаёт: «Создайте пять агентов. Они сэкономят вам 327 часов в месяц». Проблема в том, что такой результат практически невозможно проверить.

Поэтому мы стараемся отделять наблюдаемые факты от интерпретации. Факт: у 42% задач нет содержательного описания. Гипотеза: сотрудники тратят заметное время на восстановление требований. Возможность: агент может собирать связанный контекст и помогать готовить описание. Но из первого утверждения автоматически не следуют второе и третье. Возможно, команда сознательно использует Jira только как короткий список задач. Возможно, требования находятся в другой системе. Возможно, эти задачи настолько простые, что проблема вообще не имеет экономического значения. Поэтому аудит контекста не должен превращаться в магический oracle для автоматизации бизнеса. Он должен давать человеку наблюдаемую картину процесса и помогать находить места, которые стоит исследовать глубже.

Сейчас такой аудит собирает сигналы из Jira, Confluence, GitHub и подключённого календаря. Мы смотрим на разные части рабочего процесса отдельно. Для задач проверяется наличие содержательного description, acceptance criteria, priority, estimate, assignee и связи с epic или parent task. Задача без описания сама по себе не означает проблему. Но если значительная часть backlog требует дополнительного объяснения перед началом работы, появляется повторяемый ручной процесс: найти человека ? получить объяснение ? восстановить контекст ? начать работу. Вот это уже интересно с точки зрения автоматизации.

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

Сам по себе аудит ничего не автоматизирует. Его задача — показать места, где процесс требует слишком много ручного восстановления контекста, координации или переключений между системами. Дальше начинается более интересная часть: из найденной проблемы нужно сформулировать конкретный workflow, который имеет смысл изменить. Допустим, аудит показывает, что большая часть задач приходит без технического контекста, разработчики регулярно ищут связанные документы и pull request, а после реализации вручную обновляют Jira. Это уже не просто «плохие задачи». Это повторяемый процесс: поиск контекста ? проверка пробелов ? выполнение ? обновление артефактов. Вот вокруг такого процесса уже имеет смысл строить агента. Причём не абстрактного «AI-сотрудника», а агента с конкретной ролью, источниками данных, разрешёнными действиями и человеком, который остаётся точкой контроля.

После этого аудит нужен снова. Только теперь вопрос меняется: не «где у нас проблема?», а «изменилось ли что-нибудь после автоматизации?» Стало ли меньше времени уходить на восстановление контекста? Снизилось ли количество ручных действий? Стало ли меньше возвратов и уточнений? Пользуется ли команда новым workflow? Если нет — значит, мы либо автоматизировали не тот процесс, либо неправильно его изменили. Поэтому аудит — не конечная функция. Это первый и последний шаг одного цикла: сначала найти место, где AI действительно может создать ценность, потом встроить его в процесс, а затем проверить, создал ли он эту ценность на самом деле.

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


Телеграм: t.me/ainewsline

Источник: vk.com

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