Еще недавно главный вопрос при внедрении AI звучал примерно так: «Как это сделать?» Как подключить модель к Jira, как дать ей доступ к GitHub, как написать агента, настроить MCP, собрать workflow и заставить все это работать стабильно.
Сейчас техническая часть стала заметно дешевле. Прототип агента под конкретную задачу можно собрать за несколько часов. Модели умеют работать с tools, MCP стандартизирует доступ к внешним системам, frameworks берут на себя orchestration, memory и выполнение.
Из-за этого изменился сам вопрос. Теперь гораздо важнее понять: а стоит ли вообще здесь делать агента? И если стоит, то в какой именно части процесса он принесет реальный эффект?
Можно потратить неделю на создание хорошего агента и потом обнаружить, что сотрудники используют его два раза в месяц. Можно автоматизировать процесс, который и так занимал пять минут. Можно встроить AI в плохо устроенный workflow и в итоге просто автоматизировать существующий хаос. А можно найти повторяемый процесс, в котором несколько человек каждый день тратят время на поиск информации, восстановление контекста и ручные действия между несколькими системами.
Вот в последнем случае агент уже перестает быть демо и становится частью рабочего процесса.
Когда мы начали глубже разбираться с этой проблемой, у нас постепенно сложилась довольно простая модель:
Discover → Build → Measure
Перед тем как строить агента, сначала нужно понять, где его вообще имеет смысл строить.
Проблема уже не в создании агентов
Сейчас вокруг AI много разговоров про context engineering, agent harnesses, memory, orchestration и MCP. Все это важно, но в основном отвечает на вопрос: как сделать агента эффективнее?
Нас в какой-то момент начал больше интересовать другой уровень: как сделать эффективнее сам процесс, частью которого становится агент?
Потому что агент почти никогда не существует сам по себе. В процессе остается человек: кто-то ставит цель, кто-то принимает результат, кто-то отвечает за решение, кто-то должен понять, что произошло после выполнения. А вокруг них уже существуют Jira, Confluence, GitHub, почта, календарь, документы и другие рабочие инструменты.
Поэтому внедрение агента — это не только техническая задача. Это изменение рабочего процесса. И прежде чем менять процесс, нужно сначала увидеть, как он работает сейчас.
Один и тот же агент может быть полезным в одной команде и бесполезным в другой
Представим две команды. В первой разработчик открывает Jira и сразу понимает задачу. Acceptance criteria заполнены, документация актуальна, все изменения связаны с pull request, решения фиксируются. Создание отдельного агента, который будет «восстанавливать контекст задачи», скорее всего, даст небольшой эффект.
Во второй команде задача выглядит так:
Добавить поддержку нового тарифа. Подробности обсуждали на встрече.
Разработчик идет в Confluence. Документ последний раз обновлялся восемь месяцев назад. После этого он ищет похожий pull request, пишет коллеге и в какой-то момент узнает, что часть решения обсуждали в чате, а архитектурное ограничение знает только один человек.
Вот здесь уже появляется интересная точка для автоматизации. Не потому что «AI сейчас модный», а потому что существует повторяемая ручная работа: поиск, сопоставление, восстановление контекста, проверка связей, подготовка следующего действия.
Именно такие места мы и начали искать.
Контекстный долг как след проблемы
В какой-то момент нам понадобилось понятие, которым можно было бы описать такие ситуации. Так мы пришли к контекстному долгу.
Контекстный долг — это издержки из-за разрозненной, устаревшей или недостающей информации внутри рабочего процесса.
Например, разработчик ушел в отпуск, и часть работы остановилась, потому что только он знает устройство конкретной области. Новичок несколько недель ходит по людям с вопросами, ответы на которые уже звучали раньше, но нигде нормально не зафиксированы. В Jira десятки задач без содержательного описания. Изменения в GitHub невозможно связать с задачей, ради которой они появились. Документация существует, но никто не уверен, можно ли ей доверять. Половина встречи уходит на восстановление предыдущих договоренностей.
Каждый такой случай сам по себе еще не означает, что здесь нужен AI-агент. Но вместе они показывают места, в которых процесс требует большого количества ручного восстановления контекста. А это уже хорошие кандидаты для исследования.
Почему нельзя просто спросить AI, что автоматизировать
Самый простой вариант выглядел бы красиво. Подключаем корпоративные системы, AI анализирует компанию и через пять минут выдает:
Создайте пять агентов. Они сэкономят вам 327 часов в месяц.
Проблема в том, что такой результат практически невозможно проверить.
Поэтому мы стараемся отделять наблюдаемые факты от интерпретации.
Например:
Факт: у 42% задач нет содержательного описания.
Гипотеза: сотрудники тратят заметное время на восстановление требований.
Возможность: агент может собирать связанный контекст и помогать готовить описание.
Но из первого утверждения автоматически не следуют второе и третье. Возможно, команда сознательно использует Jira только как короткий список задач. Возможно, требования находятся в другой системе. Возможно, эти задачи настолько простые, что проблема вообще не имеет экономического значения.
Именно здесь мы поняли, что нам нужен не «AI, который сам решит, что автоматизировать», а способ получить наблюдаемую картину процесса. Так появилась идея контекстного аудита.
Как мы начали измерять контекстный долг
Когда мы попробовали превратить эту идею в аудит, первым вопросом стало: а что вообще можно измерить, не придумывая за компанию то, чего мы на самом деле не знаем?
В итоге мы начали с тех следов, которые уже остаются в рабочих системах: Jira, Confluence, GitHub и календаре. Причем довольно быстро выяснилось, что каждый такой сигнал нужно трактовать очень осторожно.
Jira: насколько задачи готовы к передаче
В Jira мы начали смотреть на самые очевидные вещи: есть ли содержательное description, acceptance criteria, priority, estimate, assignee и связь с epic или parent task.
Но задача без описания сама по себе еще ничего не доказывает. Если же значительная часть backlog требует дополнительного объяснения перед началом работы, появляется повторяемый ручной процесс:
найти человека → получить объяснение → восстановить контекст → начать работу
Вот это уже интересно с точки зрения автоматизации.
Confluence: насколько знания можно использовать
С документацией возникла похожая проблема. Самый очевидный сигнал — давность последнего обновления. Но старая страница не обязательно неправильная. Документ об архитектурном принципе вполне может оставаться актуальным несколько лет.
Поэтому мы не стали трактовать возраст страницы как verdict. Для нас это скорее сигнал: вот документ, актуальность которого стоит проверить.
То же самое с количеством содержимого и связями между страницами. Отсутствие ссылок само по себе не делает документацию плохой, но в совокупности с другими сигналами может показать, что знания сложно использовать в реальном процессе.
GitHub: можно ли восстановить причину изменений
В pull request мы смотрели, существует ли связь с задачей, можно ли подтвердить эту связь и насколько большим получилось обсуждение.
И здесь та же проблема с интерпретацией. Двадцать комментариев к PR не означают автоматически плохую постановку задачи. Это может быть просто сложная техническая работа.
Но если одновременно появляются длинные обсуждения, плохо описанные задачи и слабая связь между кодом и Jira, становится интереснее смотреть уже не на отдельный PR, а на весь процесс целиком.
Что делать после контекстного аудита
Когда мы получили первые результаты аудита, появилась следующая проблема. Сам по себе аудит ничего не автоматизирует. Можно найти десятки плохих задач, устаревших документов и потерянных связей, но от этого рабочий процесс автоматически лучше не становится.
Поэтому следующим шагом для нас стало не исправление каждой найденной метрики, а попытка понять, какой повторяемый процесс стоит за этими сигналами.
Допустим, большая часть задач приходит без технического контекста. Разработчики регулярно ищут связанные документы и pull request, уточняют детали у коллег, а после реализации вручную обновляют Jira.
Это уже не просто набор «плохих задач». За ним виден повторяемый workflow:
поиск контекста → проверка пробелов → выполнение → обновление артефактов
Вот вокруг такого процесса уже имеет смысл строить агента.
Причем не абстрактного «AI-сотрудника», которому дали доступ ко всему, а агента с конкретной ролью, источниками данных, разрешенными действиями и человеком, который остается точкой контроля.
И здесь мы вернулись к тому, с чего начинали. Сначала нужно найти процесс, потом что-то в нем изменить, а после этого снова посмотреть на данные.
Стало ли меньше времени уходить на восстановление контекста? Снизилось ли количество ручных действий? Стало ли меньше возвратов и уточнений? Пользуется ли команда новым workflow вообще?
Если нет — значит, мы либо автоматизировали не тот процесс, либо неправильно его изменили.
В итоге контекстный аудит для нас оказался не конечной точкой, а частью цикла:
Discover → Build → Measure
Сначала мы пытаемся увидеть места, где команда теряет время на восстановление информации, координацию и ручную работу между системами. Затем выбираем конкретный процесс и пробуем встроить туда автоматизацию. После этого возвращаемся к измерению и смотрим, изменилось ли что-нибудь на самом деле.
Когда мы начинали заниматься агентами, основным вопросом для нас был: как сделать хорошего агента?
Сейчас мне кажется, что этот вопрос постепенно становится вторичным.
Создать агента становится все проще. Гораздо сложнее понять, где его создание действительно оправдано.
И именно поэтому контекстный долг оказался для нас полезной моделью: не как очередной score, который нужно улучшать ради самого score, а как способ увидеть процессы, где люди снова и снова вручную восстанавливают то, что рабочая система должна была сохранить сама.
