В 2026 году поддержка разработчиков перестала быть набором разрозненных ботов. Компании строят комбинации специализированных агентов: одни анализируют логи и код, другие готовят контекст для инженера, третьи по команде человека открывают Pull Request с исправлением. Такой подход позволяет автоматизировать рутинные операции, не отдавая критические решения машине. Главный сдвиг заключается в том, что ИИ перешёл от ответов на вопросы к выполнению действий. Агенты диагностируют инциденты, перезапускают pods, правят конфигурацию и создают Pull Request. Однако почти все production-системы работают по схеме «человек в петле»: агент предлагает решение, инженер его утверждает. Это не техническое ограничение, а осознанный предохранитель, снижающий риски ошибок.

Архитектурный паттерн, повторяющийся в кейсах разных компаний, — разделение на оркестратор и агентов-исполнителей. Оркестратор понимает запрос, разбивает его на шаги и раздаёт подзадачи. Каждый агент получает только необходимые инструменты (доступ к GitLab, Kubernetes, логам, базе данных) и жёсткие лимиты по токенам, времени и количеству вызовов. Если дать одной модели триста инструментов и десять правил, она начнёт путаться даже на простых вопросах. Разделение позволяет оркестратору сохранять «чистую голову», а агентам — фокусироваться на конкретной подзадаче.

Показательный кейс — Electrolux с мультиагентной системой для поддержки разработчиков и инфраструктурных операций. Один из агентов диагностирует проблемы с transit gateway. В демонстрационном сценарии инженер спрашивает, всё ли в порядке с конфигурацией, и агент отвечает утвердительно. Тогда инженер намеренно ломает соединение, выключив dev-окружение, и задаёт тот же вопрос. Агент точно определяет проблему: в security groups нет правила, разрешающего трафик из CIDR-диапазона другого окружения. Представитель Electrolux подчёркивает, что это не подобранный пример, а первое, что он попробовал, что говорит о реальных диагностических возможностях.

Другой пример — Life360 с 88 миллионами пользователей. Сначала компания использовала ботов под каждую задачу, и сотрудники не знали, кого звать. Затем попробовали одного «всё умеющего» агента, но он стал медленным и поверхностным, и люди вернулись к прямому обращению в IT. Решение — оркестратор Mimir, названный в честь скандинавского бога мудрости. Сотрудник пишет @Mimir в Slack, и оркестратор сам решает, какому субагенту передать запрос: ITSM, Jira, Confluence, управление Slack или кодинг. Отдельно строится Crash Agent, который идентифицирует падение приложения, находит путь в коде, предлагает патч и открывает Pull Request для ревью инженером. Момент, когда агент прошёл весь путь и открыл Pull Request, показал, что можно реально закрыть петлю.

Отдельная категория кейсов — когда агенту дают «руки» поэтапно. В серии статей на Хабре «Эй, агент, исправь мой билд» автор описывает эволюцию: сначала агенты были строго read-only, они смотрели в логи, метрики и код, писали отчёты, но ничего не меняли. Потом появилась фаза исполнения. Ключевое решение: фазу определяет не модель, а код. Первое сообщение в треде уходит в анализ. Если для исправления нужны изменения, задача переводится в статус verdict_ready, и система ждёт человека. Инженер читает отчёт и отвечает «сделай» — только тогда запускается executor-workflow, который вносит изменения и открывает Pull Request. «LLM предлагает категорию, но суффикс _execute вычисляется кодом из статуса. Галлюцинация модели не может ни запустить исполнение раньше времени, ни вернуть задачу с готовым вердиктом обратно в анализ». Ни одна задача не доходит до исполнения без явного ответа инженера в треде. Это «дешёвый, но принципиальный предохранитель».

Следующий шаг эволюции — системы, которые сами ведут расследование. В кейсе MTS Web Services описан переход от классического RAG к автономному агенту. Сначала RAG-система помогала искать по Jira и Confluence, но выдавала сырые куски документации, и инженеру всё равно приходилось собирать картину в голове. Плюс был критический изъян: нужно было знать, что искать. Тогда команда построила агента, который сам проводит первичное расследование: анализирует описание тикета, составляет план, определяет, какие данные ему нужны, делает поисковые запросы, агрегирует информацию из нескольких источников и отдаёт инженеру структурированный анализ с гипотезами. Ключевое отличие от RAG: агент не ждёт, пока человек задаст правильный вопрос, а сам решает, что искать, исходя из контекста тикета. Результаты после внедрения: 40% тикетов — правильное решение, 45% — неполное решение, 15% — неправильное. Итого примерно в 85% тикетов система оказалась полезна хотя бы частично. Один из показательных кейсов: менеджер клиента создал задачу на консультацию, сам изучил ответ ИИ и закрыл тикет без участия инженеров поддержки.

Coinbase подошли к построению ИИ-поддержки с позиции observability-first. Их принцип: «glass box before building the agent» — сначала прозрачность, потом агент. Они развернули несколько агентов: Discord AI Chat — меню-ориентированный интерфейс для разработчиков; Slack Triage — внутренний агент, который показывает, какие сообщения из Discord требуют внимания; Support Engineer Assistant — ассистент внутри сервисной команды. Такой подход позволяет контролировать работу агентов и вмешиваться при необходимости. В отличие от альтернатив, где агенты работают как чёрный ящик, Coinbase делает ставку на объяснимость и мониторинг. Для российского рынка описанные практики пока не стали массовыми, но интерес растёт. Крупные компании, такие как MTS Web Services, уже внедряют автономных агентов для расследования инцидентов. Однако остаются открытые вопросы: как масштабировать такие системы, как обеспечивать безопасность и соответствие требованиям, как обучать инженеров работать с агентами. Перспективы связаны с дальнейшим развитием мультиагентных архитектур и увеличением автономности при сохранении контроля человека. Что будет дальше — пока неясно, но направление задано.