Бот для перегляду запитів на з’єднання з кодом з відкритим кодом: LangGraph, Node.js та GitHub Webhooks

Запити на pull request накопичуються майже в кожній команді. Зазвичай лише старші інженери помічають тонкі проблеми: запити типу N+1, жорстко закодовані секрети, крайні випадки, які ніхто не обробив. Вони також є найзайнятішими, тому перегляди запитів відбуваються поспішно або відкладаються, і в будь-якому разі щось все одно потрапляє далі.

Інструменти для перегляду AI у комерційних проектах зазвичай є закритими або дорогими, часто й те, й інше. Альтернативою є бот, який невелика команда може запустити у власних репозиторіях, без необхідності надсилати код у „чорну скриньку“. Наведений нижче дизайн — це бот з відкритим кодом, який стежить за новими запитами на pull request у GitHub, переглядає кожен з них за допомогою багатоетапного агента LangGraph та надсилає конкретні коментарі на рівні окремих рядків як примітки до PR.

Що відбувається, коли відкривається PR

1. Webhook GitHub передає повідомлення про подію.
2. API GitHub через Octokit отримує інформацію про зміни.

Агент LangGraph перевіряє кожен етап змін по черзі на наявність проблем із безпекою, продуктивністю та архітектурними аспектами.

Бот публікує коментар до PR із відгуками, які вказують на конкретні рядки коду.

Огляд зберігається в базі даних, тож історія змін накопичується з часом.

Саме поетапна перевірка є ключовою. Одне запитання до LLM з проханням „переглянути цей код“ зазвичай призводить до розмитих, загальних зауважень. Розділення завдання на перевірку безпеки, продуктивності та архітектури дає більш точні результати, оскільки кожен етап має лише одну функцію.

Технологічна стек

База даних PostgreSQL для історії переглядів Інтеграція з GitHub Octokit Webhooks Express middleware з перевіркою підпису

Ця стек-технологія залишається близькою до того, що вже використовують більшість команд Node.js. Метою не було показати нову фреймворк-систему — метою було створити щось, що команда може розмістити та довіряти.

Потік та структура

Пайплайн працює від відкритого PR через перевірений webhook до агента, а потім повертається у вигляді коментаря:

GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Кожна перевірка у потоці LangGraph є окремим вузлом. Команда може тестувати, налаштовувати або вимикати одну перевірку, не впливаючи на інші, що допомагає тоді, коли людям важливі лише результати перевірки безпеки, і вони не хочуть бачити коментарі щодо архітектури для кожного PR.

Два фрагменти коду, які варто показати

По-перше, перевірка підпису webhook. Без неї будь-хто, хто знає URL webhook, може надсилати фальшиві події та ініціювати неправдиві перевірки:

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

Він дуже малий, проте його пропуск є поширеною помилкою у інструментах, які працюють за допомогою webhook.

По-друге, ланцюг обробки LangGraph складається з окремих вузлів, а не з одного великого запиту:

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

Кожен вузол отримує інформацію про відмінності та повертає лише свої власні результати, які потім об’єднуються в один коментар. Таким чином дебагування стає простішим. Якщо перевірка продуктивності показує щось дивне, потрібно перевірити лише один вузол, а не величезний набір даних.

Що спрацювало

• Розділення перевірки на окремі частини – безпеку, продуктивність та архітектуру – дало значно кращі та більш конкретні відгуки, ніж єдиний запит. Це було найбільше покращення якості в усьому проекті.
• Перевірка підписів webhook з самого початку означала, що безпека була частиною дизайну, а не щось, що додавалося пізніше.
• Зберігання історії перевірок у PostgreSQL, навіть у простій формі, дозволило пізніше помітити певні закономірності, наприклад, які типи проблем постійно з’являлися у різних PR-запитах.

Що залишилося складним

• Хибні позитивні результати є неминучим наслідком використання таких технологій. Оцінка на основі LLM іноді позначає речі, які не є проблемами, і документація має відкрито про це повідомляти. Довіра має більше значення, ніж вражаючий перелік функцій.
• Витрати зростають. Три виклики LLM на кожну PR є більш точними, ніж один, але вони коштують дорожче та займають більше часу. Невеликій команді потрібен баланс між якістю оцінки та сумою, яку вона може собі дозволити.
• Щоб коментарі виглядали так, ніби їх написала людина, знадобилось більше ітерацій формулювання запитів, ніж для розробки логіки LangGraph. Коментарі мають бути короткими, конкретними та посилатися на номер рядка, адже ніхто не читає п’ятипараґрафовий есей від ШІ у треді PR.

Цей бот є одним із низки невеликих проектів з відкритим кодом, які застосовують технології оркестрації LLM з LangChain та LangGraph до конкретних проблем робочих процесів — таких як запитання та відповіді щодо документів за допомогою RAG, запитання та відповіді щодо правил для послуг, орієнтованих на громадян, та перетворення голосових нотаток на користувацькі історії у стилі Agile, замість створення універсальних демонстрацій. Це не готовий продукт, який можна розгорнути будь-де. Це функціональна вихідна точка, на якій команда може будувати та вдосконалювати рішення для власних умов.

Спробувати локально

Репозиторій легко запустити. Клонуйте його, встановіть залежності та запустіть сервер розробки:

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

У документі README описано повний процес налаштування, змінні середовища та способи підключення GitHub webhook. Зворотний зв’язок щодо хибно позитивних результатів чи ідеї щодо роботи LangGraph — саме такі повідомлення найбільше допомагають.