Техподдержка для разработчиков переходит от чат-ботов к трём ролям ИИ-агентов

Два года назад «ИИ в поддержке» означал чат-бота с кнопками, который отвечал по шаблону и раздражал пользователей. В 2026-м службы поддержки для разработчиков строят другую схему. Это не один умный бот, а три группы агентов с разными задачами. Первые копаются в логах и коде, вторые собирают контекст для инженера, третьи по команде человека открывают Pull Request с исправлением. Так описывает тренд свежий материал на Habr.

Три роли вместо одного бота

Главное изменение в разделении труда. Классический бот пытался закрыть обращение сам, и на сложных случаях это ломалось: нужно было одновременно понимать продукт, читать стек-трейс и подбирать ответ. Теперь каждая задача уходит узкому агенту.

• Агент-диагност читает логи CI, трейсы ошибок, историю коммитов и ищет вероятную причину падения билда.
• Агент-подготовщик собирает для инженера версию SDK, окружение, шаги воспроизведения и связанные тикеты.
• Агент-исполнитель готовит патч и открывает Pull Request, но только после явной команды человека.
• Контур контроля включает ревью, прогон тестов и журнал действий каждого агента.

Третья роль самая показательная. Агент не вливает изменения сам, а предлагает их в виде PR, и решение остаётся за инженером.

Почему именно поддержка разработчиков

Для агентов это удобная среда. Обращения приходят со структурированными данными: конфиги, версии, трассировки. У задачи есть проверяемый результат, потому что билд либо зелёный, либо красный. А репозиторий даёт агенту и источник правды, и песочницу, где ошибку можно поймать до продакшена. В обычной клиентской поддержке такой обратной связи почти нет, там «правильность» ответа приходится оценивать косвенно.

Есть и экономика. Основное время инженера поддержки уходит не на исправление, а на сбор контекста: уточнить версию, попросить логи, найти похожий случай. Именно эту рутину агенты забирают первой, и польза видна даже без автоматических PR.

Где риски

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

С чего начинать команде

Начинать разумно с диагноста в режиме «только чтение», без права что-либо менять. Права на запись стоит давать позже и на узких классах проблем: сломанная зависимость, нестабильный тест, ошибка в конфигурации. Перед запуском нужно заранее договориться о метриках, иначе оценивать станет нечем:

• доля тикетов, где собранный контекст оказался верным;
• время до первого содержательного ответа;
• доля PR, принятых без правок;
• число повторных обращений по тому же вопросу.

Отдельно стоит маскировать секреты до попадания логов в модель, а PR создавать в изолированных ветках. Если связка агентов не снижает долю повторных обращений, значит, она ускоряет только сам процесс, а не решение проблем.