AI-триаж GitHub/Jira issues

AI-агент на базе AI-модели подключается к вашему репозиторию GitHub и/или инстансу Jira и обрабатывает каждый новый issue в момент его создания. Система извлекает смысл из неструктурированного текста заголовка и описания, классифицирует тикет по внутренней таксономии команды и выполняет стандартные действия триажа без участия инженера.

Что делает автоматизация на практике:

1. Забирает новый issue через webhook (GitHub Issues API или Jira Webhooks) сразу после создания.
2. Извлекает ключевые сущности из описания: тип (bug/feature/question), затронутый компонент или модуль, упомянутые версии, окружение, stacktrace.
3. Определяет приоритет по правилам команды: severity, affected users, business impact.
4. Проставляет labels и components в соответствии с утверждённой таксономией.
5. Ищет дубликаты — семантический поиск по уже открытым issues за последние 6-12 месяцев.
6. Назначает владельца: по компоненту, по module ownership, по round-robin внутри команды.
7. Оставляет комментарий с кратким структурированным резюме для инженера — что сломалось, где, как воспроизвести, похожие тикеты.
8. Эскалирует в Slack канал команды, если issue помечен как critical или похож на production incident.

Эффект из практики внедрения: senior-инженер тратил 3 часа в неделю на ручной триаж — стало 20 минут быстрой проверки пограничных кейсов. Time-to-label сократилось с 18 часов до 2 часов. Дубликаты ловятся автоматически — раньше уходило до 1-2 дней до того, как кто-то замечал повтор.

Что автоматизация НЕ делает

Честные границы ответственности AI-агента:

• Не принимает инженерные решения. Триаж проставляет разметку и назначает владельца, но не решает «фиксить сейчас или нет» и «в какой sprint» — это остаётся за tech lead.
• Не закрывает issues. Даже явные дубликаты агент помечает и линкует, но финальное закрытие делает человек — это страховка от ложных совпадений.
• Не работает с приватной архитектурой без контекста. Агенту нужна заполненная таксономия labels, module ownership map и примеры корректно размеченных тикетов.

Архитектурно автоматизация строится как slim-сервис между issue tracker и LLM: webhook ловит событие, собирается контекст (текст issue, похожие открытые тикеты, module ownership, ранее размеченные примеры), LLM возвращает структурированный JSON с классификацией, ответ применяется к issue через API платформы. Всё обёрнуто в retry-логику и human-in-the-loop для спорных кейсов.

Техническая последовательность

1. Webhook от GitHub или Jira прилетает на сервис триажа (FastAPI или Node) при событиях issues.opened и issues.edited.
2. Сервис собирает контекст: заголовок, описание, автор, существующие labels, список потенциальных дубликатов (top-5 по embedding similarity из векторного индекса).
3. Сервис формирует промпт для AI-модели: передаётся таксономия labels, module ownership map, few-shot примеры ранее корректно размеченных issues и сам текст нового тикета.
4. Claude возвращает JSON: { labels, priority, component, owner, duplicate_candidates, summary, confidence }.
5. Сервис валидирует JSON по схеме: если уровень confidence ниже порога (например, 0.75) — помечает issue тегом needs-human-triage и не назначает владельца.
6. Для confident-кейсов сервис применяет labels и assignee через GitHub или Jira API, оставляет комментарий с резюме и линками на похожие тикеты.
7. Критичные issues эскалируются в Slack канал команды через incoming webhook.
8. Каждое действие пишется в audit log — прослеживается, что и почему агент изменил.

Компоненты решения

Почему custom-code, а не готовый no-code

Для триажа issues важны три вещи, которые слабо покрываются готовыми конструкторами: точный контроль над промптом и few-shot примерами (ваша таксономия специфична), векторный индекс дубликатов с persistent store embeddings и прозрачный audit log. Всё это решается на ~500-800 строк Python или TypeScript с LLM-клиентом, векторной БД (pgvector, Qdrant) и двумя API-интеграциями. Типичный стек: FastAPI + PostgreSQL с pgvector + AI-модель через Anthropic SDK + Octokit или Jira REST.

Human-in-the-loop как дефолт

Агент не работает на полном доверии. Два механизма обеспечивают безопасность:

1. Confidence threshold — при уровне ниже порога решение помечается needs-human-triage, labels не проставляются.
2. Weekly review — раз в неделю tech lead сверяет 20 случайных решений агента с реальностью, few-shot примеры обновляются, качество не деградирует.

Итог: большая часть issues размечается без участия инженера, спорные кейсы уходят на ручной триаж — но уже с подготовленным агентом резюме и кандидатами в дубликаты, что всё равно ускоряет работу.

Для запуска триажа команде нужны готовые данные, доступы и минимальная организационная подготовка.

Данные и доступы:

• GitHub Personal Access Token (scope repo) или Jira API token с правами на запись labels, assignee и комментариев.
• Утверждённая таксономия labels — список типов (bug/feature/task), приоритетов и компонентов. Обычно 15-40 категорий.
• Module ownership map: какой человек или команда отвечает за какой компонент или модуль.
• 100-200 корректно размеченных issues за последние 6-12 месяцев — для few-shot примеров и построения векторного индекса дубликатов.
• API ключ Anthropic для AI-модели.

Инфраструктура:

• Сервер или managed-платформа для сервиса триажа (VPS, Render, Railway, AWS Lambda — подойдёт любой вариант).
• PostgreSQL с pgvector или Qdrant/Weaviate для векторного индекса.
• Slack workspace и incoming webhook, если нужна эскалация критичных issues.

Готовность команды:

• Tech lead или senior-инженер как owner автоматизации — согласует таксономию и проверяет качество первые 2-3 недели.
• 30-40 минут в неделю у owner на weekly review решений агента в первый месяц, далее 15 минут.
• Команда принимает правила: дубликаты линкуются автоматически, но закрывает их человек.

Таймлайн внедрения:

Для complexity «week» ожидаемый срок — 2-4 недели. Неделя 1 — согласование таксономии и подготовка few-shot датасета. Неделя 2 — реализация сервиса и подключение webhooks. Неделя 3 — shadow mode (агент пишет решения в log, но не применяет), калибровка confidence threshold. Неделя 4 — переход в production с human review.