В MWS рассказали, что их ИИ-агент полностью решал около 45% задач по техподдержке, а еще примерно в 40% случаев доводил расследование до полезного промежуточного результата. Для тех, кто следит за тем, как ИИ-агенты в компании выходят за рамки подсказок в чате, это важный сигнал: речь уже не о генерации текста и кода, а о попытке встроить модель в реальные инженерные процессы.
Эту тему на восьмом митапе MWS для DevOps и SRE разобрали специалисты МТС Web Services и Orion Soft, сообщает Habr / Карьера. Главная мысль звучит довольно трезво: чем больше автономии получает агент, тем меньше он похож на «умного помощника» и тем больше требует от самой компании. Ему нужны не только модель и промпт, но и доступ к внутренним данным, понятные регламенты, свежая документация и жесткие границы полномочий.
О практическом кейсе рассказал Владимир Дробот, SRE Lead в МТС Web Services. Его команда разбирала типичные инциденты, где не всегда нужна редкая экспертиза, но почти всегда нужен дисциплинированный набор шагов: прочитать обращение, найти похожие случаи, свериться с базой знаний, посмотреть логи, при необходимости сходить в систему задач или в базу данных. Именно эту рутинную, но не совсем примитивную цепочку действий и передали агенту. Система индексирует корпоративную базу знаний, историю обращений и данные из таск-трекера, а затем подбирает сценарий расследования под конкретный запрос. Если проблема похожа на уже случавшуюся, агент ищет прецеденты; если нет, проверяет логи, подготавливает запросы и собирает фактуру для инженера.
Результаты, которые MWS озвучила на старте, выглядят достаточно приземленно, чтобы им можно было верить. Около 45% задач агент закрывал полностью, еще примерно 40% разбирал частично: инцидент не исчезал сам собой, но инженер получал не пустой ответ от чат-бота, а уже собранное расследование с полезными зацепками и следующими шагами. Оставшиеся 15% требовали дополнительной проверки из-за ошибок или галлюцинаций. Собственно, в этих цифрах и проходит реальная граница автоматизации. Пока агенту не дают права без оглядки менять что-то в критичных системах. Он может предложить действие, подготовить запрос, собрать доказательства, но финальное «делаем» остается за человеком. Иначе один удачный день автоматизации легко превращается в очень длинную ночь для дежурной смены.
Из этого кейса вытекает неприятная для любителей волшебных кнопок мысль: качество агентной системы растет не только и не столько от смены модели. Если агент ошибается, проблема часто оказывается в другом месте. Где-то не хватает данных в документации, где-то сценарий расследования описан слишком общо, где-то знания лежат в головах сотрудников, а не в доступной системе. По сути, ИИ-агенты в компании обучаются почти так же, как новые инженеры: им дают инструкции, проверяют результат, исправляют пробелы и возвращают накопленный опыт обратно в контур. Чем лучше организованы внутренние знания, тем полезнее агент. Если знания размазаны по чатам, устным договоренностям и забытым wiki, никакая модель этот бардак аккуратно не замаскирует.
Похожий вывод озвучил Андрей Боровков, Tech Lead DevRails AI в МТС Web Services. Его команда строит среду управляемых агентов для разных ролей внутри разработки: от продуктовых аналитиков до DevOps-инженеров. На бумаге все выглядит соблазнительно: модели быстро пишут код, значит и разработка должна разгоняться сопоставимыми темпами. На практике ускорение упирается в работу вокруг кода. Модель не знает, почему команда когда-то приняла неудобное архитектурное решение, какие интеграции считаются хрупкими, где уже были инциденты и какие ограничения в проекте нельзя трогать. Боровков привел показательный эпизод: агент решил, что внутренняя Kafka недоступна извне по ошибке, и попытался открыть внешний доступ. Формально действие выглядело логичным, фактически команде потом пришлось разбираться с последствиями. Проблема была не в синтаксисе и не в способности генерировать код, а в том, что агент не понимал контекст проекта.
Отсюда меняется и роль самого инженера. На митапе прямо говорили, что специалист не исчезает, а смещается выше по уровню абстракции. Если раньше инженер руками выполнял длинную механическую часть ревью или расследования, теперь он все чаще выступает оркестратором: настраивает взаимодействие людей, агентов, документации и внутренних систем. В MWS агент, например, может не просто накидать список замечаний, а собрать карту рисков: показать архитектурные конфликты, потенциальные гонки, эксплуатационные проблемы, взаимные блокировки. Решение все равно принимает человек, но время уходит уже не на перебор очевидного, а на проверку действительно опасных мест. Это меняет набор навыков: ценность смещается от чистого умения писать код к способности быстро валидировать результат, понимать границы допустимого и проектировать сам процесс работы с агентами.
Еще один сдвиг касается документации. Если агенту доверяют действия внутри проекта, документация перестает быть унылым приложением к коду и превращается в часть инфраструктуры. В команде Боровкова стараются фиксировать архитектуру, доменную область, API, инструкции и плейбуки так, чтобы ими пользовались и люди, и агенты. Более того, отдельный агент может проверять, не разъехались ли код и сопутствующие материалы после изменений. Подход здешний вполне инженерный: один источник контекста для всех участников процесса, без двух параллельных версий реальности. Иначе разработчик будет работать по одному набору правил, а виртуальный сотрудник по другому, а такие расхождения обычно заканчиваются не философской дискуссией, а инцидентом.
В докладе Orion Soft прозвучал смежный, но важный для общей картины мотив. Никита Ефимов рассказывал про управление операторами в закрытом сегменте и отдельный оператор-менеджер для централизованной установки, версионирования и обновления компонентов. Это не история про ИИ в чистом виде, но логика та же: как только автоматизация становится сложнее одной команды или одного скрипта, нужен слой управления, который знает связи, зависимости и порядок действий. Для агентных систем этот слой особенно важен. Один универсальный агент «на весь SDLC» пока выглядит красивее на слайде, чем в продакшене. Гораздо реалистичнее модель со специализированными ролями: один агент разбирает инциденты, другой помогает с ревью, третий следит за документацией, и у каждого свои инструменты и права.
Для российского IT-рынка здесь, пожалуй, главный вывод не в том, что компании срочно заменят инженеров виртуальными сотрудниками. Скорее начинается более скучная, но и более полезная стадия: бизнес учится превращать ИИ из эффектной демки в управляемый производственный инструмент. Победят не те, кто просто прикрутит модель к чату, а те, кто сумеет собрать для нее контекст, права доступа, процесс проверки и внятную зону ответственности. И вот это уже не выглядит как мода на сезон.