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.