Bot do przeglądania prośb o włączenie zmian o otwartym kodzie źródłowym: LangGraph, Node.js i GitHub Webhooks

Zapytania typu pull request gromadzą się niemal w każdym zespole. Zazwyczaj tylko doświadczeni inżynierowie potrafią dostrzec subtelne problemy: zapytania typu N+1, hardkodowane hasła, przypadki krawędziowe, którymi nikt się nie zajął. Są to również najbardziej zajęci pracownicy, więc przeglądanie zmian odbywa się pośpiesznie lub jest odkładane, a w obu przypadkach coś przechodzi bez kontroli.

Narzędzia do przeglądania AI o charakterze komercyjnym zazwyczaj są zamknięte lub drogie, często jedno i drugie. Alternatywą jest bot, który mały zespół może uruchomić w swoich własnych repozytoriach, bez konieczności wysyłania kodu do „czarnej skrzynki”. Poniższy projekt to bot o otwartym kodzie źródłowym, który śledzi nowe zapytania typu pull request na GitHubie, przegląda każde z nich za pomocą wieloetapowego agenta LangGraph i publikuje konkretne informacje na poziomie poszczególnych wierszy jako komentarze do PR.

Co się dzieje, gdy otwiera się PR

1. Webhook GitHuba przekazuje informację o wydarzeniu.
2. API GitHuba, za pośrednictwem Octokit, pobiera różnice między wersjami kodu.

Agent LangGraph sprawdza każdy etap różnic stopniowo, szukając problemów z bezpieczeństwem, wydajnością oraz kwestii architektonicznych.

Bot publikuje komentarz pod PR z informacjami zwrotnymi wskazującymi na konkretne linie kodu.

Recenzja jest zapisywana w bazie danych, dzięki czemu historia zmian gromadzi się z upływem czasu.

Kluczowe jest dokładne sprawdzanie każdego etapu. Jedno polecenie skierowane do modelu LLM z prośbą o „przegląd tego kodu” zazwyczaj daje ogólne, niejasne uwagi. Podzielenie zadania na sprawdzenie bezpieczeństwa, wydajności i architektury przynosi bardziej precyzyjne wyniki, ponieważ każdy etap ma jedną, określoną rolę.

Stack technologiczny

Baza danych PostgreSQL do przechowywania historii przeglądów Integracja z GitHubem Octokit Webhooki Express middleware z weryfikacją podpisu

Ta architektura jest bliska temu, co już używają większość zespołów Node.js. Celem nie było prezentowanie nowego frameworka, lecz coś, co zespół może uruchomić i w czym może mieć pewność.

Przepływ i struktura

Pipeline działa od otwartego PR, przez zweryfikowany webhook do agenta, a następnie z powrotem w postaci komentarza:

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

Każda weryfikacja w procesie LangGraph stanowi odrębny węzeł. Zespół może testować, dostosowywać lub wyłączać pojedynczą weryfikację bez wpływu na pozostałe, co jest przydatne, gdy ludzie interesują się wyłącznie ustaleniami dotyczącymi bezpieczeństwa i nie chcą widzieć opinii na temat architektury przy każdym PR.

Dwa fragmenty kodu wartych pokazania

Najpierw weryfikacja podpisu webhooka. Bez niej każdy, kto odkryje adres URL webhooka, może wysyłać fałszywe zdarzenia i wywoływać nieautentyczne przeglądy:

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));
}

Jest mały, ale pomijanie go to powszechny błąd w narzędziach opartych na webhookach.

Po drugie, strumień LangGraph składa się z oddzielnych węzłów, a nie z jednego dużego promptu:

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

Każdy węzeł otrzymuje różnicę i zwraca tylko swoje własne wyniki, które następnie łączy się w jeden komentarz. Dzięki temu debugowanie staje się łatwiejsze. Jeśli sprawdzenie wydajności zwróci coś niezwykłego, trzeba sprawdzić tylko jeden węzeł, a nie cały ogromny prompt.

Co zadziałało

• Rozbicie przeglądu na oddzielne sprawdzenia bezpieczeństwa, wydajności i architektury dało znacznie lepsze, bardziej konkretne informacje niż prompt łączący wszystko. Był to największy wzrost jakości w całym projekcie.
• Weryfikacja podpisów webhook od samego początku oznaczała, że bezpieczeństwo było częścią projektu, a nie czymś dodanym później.
• Zachowywanie historii przeglądów w PostgreSQL, nawet w prostej formie, umożliwiło późniejsze zidentyfikowanie wzorców, takich jak rodzaje problemów, które ciągle pojawiały się w różnych PR-ach.

Co pozostało trudne

• Fałszywie pozytywne wyniki są nieuniknione. Systemy oparte na LLM czasami wykrywają rzeczy, które nie stanowią problemów, a dokumentacja powinna jasno o tym informować. Zaufanie jest ważniejsze niż imponująca lista funkcji.
• Koszty się kumulują. Trzy wywołania LLM na każdą prośbę o przegląd są dokładniejsze niż jedno, ale są droższe i zajmują więcej czasu. Mały zespół musi znaleźć równowagę pomiędzy jakością przeglądu a ceną, jaką może sobie pozwolić.
• Ustalenie takiego stylu komentarzy, by brzmiały jak tekst napisany przez człowieka, wymagało więcej modyfikacji promptów niż sama logika LangGraph. Komentarze powinny być krótkie, konkretne i odnosić się do numeru wiersza, ponieważ nikt nie czyta pięcioparagrafowego eseju AI w temacie prośby o przegląd.

Bot jest jednym z serii małych eksperymentów otwartego oprogramowania, które wykorzystują mechanizmy orkiestracji modeli językowych z LangChain i LangGraph do rozwiązywania konkretnych problemów w procesach pracy, takich jak pytania i odpowiedzi dotyczące dokumentów przy użyciu RAG, pytania i odpowiedzi związane z politykami w usługach skierowanych do obywateli oraz przekształcanie notatek głosowych w historie użytkowników typu Agile, zamiast tworzenia ogólnych demonstracji. Nie jest to gotowy produkt gotowy do użycia wszędzie – to funkcjonalny punkt wyjścia, na którym zespół może budować dalej i dostosowywać go do swoich potrzeb.

Próba lokalna

Repozytorium można szybko uruchomić. Sklonuj je, zainstaluj wymagane zależności i uruchom serwer deweloperski:

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

README opisuje pełną konfigurację, zmienne środowiskowe oraz sposób podłączenia webhooka z GitHuba. Informacje o fałszywie pozytywnych wynikach lub pomysły dotyczące funkcjonowania LangGraph są tymi raportami, które najbardziej pomagają.