AI-триаж GitHub/Jira-тікети

AI-агент на базі AI-моделі підключається до вашого репозиторію GitHub та/або інстансу Jira і обробляє кожен новий тікет в момент його створення.

Система витягує смисл із неструктурованого тексту заголовка та опису, класифікує тикет за внутрішньою таксономією команди та виконує стандартні дії тріажу без участі інженера.

Що робить автоматизація на практиці:

1. Забирає новий тікет через вебхук (GitHub Issues API або Jira Webhooks) одразу після створення.
2. Витягує ключові сутності з опису: тип (bug/feature/question), задіяний компонент або модуль, згадані версії, оточення, стек-трейс.
3. Визначає пріоритет за правилами команди: рівень критичності, кількість постраждалих користувачів, вплив на бізнес.
4. Проставляє мітки та компоненти відповідно до затвердженої таксономії.
5. Шукає дублікати — семантичний пошук за вже відкритими тікетами за останні 6-12 місяців.
6. Призначає власника: за компонентом, за картою відповідальності за модулями, по черзі всередині команди.
7. Залишає коментар із коротким структурованим резюме для інженера — що зламалось, де, як відтворити, схожі тикети.
8. Ескалює в Slack канал команди, якщо тікет позначено як критичний або схожий на інцидент у продакшні.

Ефект із практики впровадження: старший інженер витрачав 3 години на тиждень на ручний тріаж — стало 20 хвилин швидкої перевірки граничних кейсів. Час до встановлення міток скоротився з 18 годин до 2 годин. Дублікати ловляться автоматично — раніше йшло до 1-2 днів до того, як хтось помічав повтор.

Що автоматизація НЕ робить

Чесні межі відповідальності AI-агента:

• Не приймає інженерних рішень. Тріаж проставляє розмітку та призначає власника, але не вирішує «фіксити зараз чи ні» і «в який спринт» — це залишається за техлідом.
• Не закриває тікети. Навіть явні дублікати агент позначає та лінкує, але фінальне закриття робить людина — це страховка від хибних збігів.
• Не працює з приватною архітектурою без контексту. Агенту потрібна заповнена таксономія міток, карта відповідальності за модулями та приклади коректно розмічених тикетів.

Архітектурно автоматизація будується як легковісний сервіс між трекером задач і LLM: webhook ловить подію, збирається контекст (текст тікету, схожі відкриті тикети, карта відповідальності за модулями, раніше розмічені приклади), LLM повертає структурований JSON із класифікацією, відповідь застосовується до тікету через API платформи. Все загорнуто в логіку повторних спроб та участь людини для спірних кейсів.

Технічна послідовність

1. Вебхук від GitHub або Jira надходить на сервіс тріажу (FastAPI або Node) при подіях issues.opened і issues.edited.
2. Сервіс збирає контекст: заголовок, опис, автор, наявні мітки, список потенційних дублікатів (топ-5 за семантичною схожістю з векторного індексу).
3. Сервіс формує промпт для AI-моделі: передається таксономія міток, карта відповідальності за модулями, приклади-зразки раніше коректно розмічених тікетів та сам текст нового тикету.
4. Claude повертає JSON: { labels, priority, component, owner, duplicate_candidates, summary, confidence }.
5. Сервіс валідує JSON за схемою: якщо рівень впевненості нижче порогу (наприклад, 0.75) — позначає тікет тегом needs-human-triage і не призначає власника.
6. Для впевнених кейсів сервіс проставляє мітки й призначає відповідального через GitHub або Jira API, залишає коментар із резюме та посиланнями на схожі тикети.
7. Критичні тікети ескалуються у Slack-канал команди через вхідний вебхук.
8. Кожна дія записується в журнал аудиту — простежується, що і чому агент змінив.

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

Чому custom-code, а не готовий no-code

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

Участь людини як стандарт

Агент не працює на повній довірі. Два механізми забезпечують безпеку:

1. Поріг впевненості — при рівні нижче порогу рішення позначається needs-human-triage, мітки не проставляються.
2. Щотижневий перегляд — раз на тиждень техлід звіряє 20 випадкових рішень агента з реальністю, приклади-зразки оновлюються, якість не деградує.

Підсумок: більша частина тікетів розмічається без участі інженера, спірні кейси йдуть на ручний тріаж — але вже з підготовленим агентом резюме та кандидатами в дублікати, що все одно прискорює роботу.

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

Дані та доступи:

• GitHub Personal Access Token (область доступу repo) або Jira API token з правами на запис міток, відповідального виконавця і коментарів.
• Затверджена таксономія міток — список типів (bug/feature/task), пріоритетів і компонентів. Зазвичай 15-40 категорій.
• Карта відповідальності за модулями: яка людина або команда відповідає за який компонент або модуль.
• 100-200 коректно розмічених тікетів за останні 6-12 місяців — для прикладів-зразків і побудови векторного індексу дублікатів.
• API ключ Anthropic для AI-моделі.

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

• Сервер або хмарна платформа для сервісу тріажу (VPS, Render, Railway, AWS Lambda — підійде будь-який варіант).
• PostgreSQL з pgvector або Qdrant/Weaviate для векторного індексу.
• Slack workspace і вхідний вебхук, якщо потрібна ескалація критичних тікетів.

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

• Техлід або старший інженер як відповідальний за автоматизацію — узгоджує таксономію і перевіряє якість перші 2-3 тижні.
• 30-40 хвилин на тиждень у відповідального на щотижневий перегляд рішень агента у перший місяць, далі 15 хвилин.
• Команда приймає правила: дублікати лінкуються автоматично, але закриває їх людина.

Таймлайн впровадження:

Для складності «тиждень» очікуваний строк — 2-4 тижні. Тиждень 1 — узгодження таксономії і підготовка набору прикладів-зразків. Тиждень 2 — реалізація сервісу і підключення вебхуків. Тиждень 3 — режим спостереження (агент записує рішення в журнал, але не застосовує), калібрування порогу впевненості. Тиждень 4 — перехід у продакшн з ручним переглядом.