Jak skonfigurowałam dwóch agentów do wstępnego review kodu

Zdjęcie dodane przez Kevin Ku: Pexels

W debacie o przyszłości pracy dewelopera często słyszymy, że AI nas zastąpi. Ja, stanowczo mówię: Sztuczna Inteligencja nie zastąpi w pełni człowieka w procesie produkcji kodu. Nasza rola – rozumienie kontekstu biznesowego, subtelności architektonicznych i ocena ryzyka – pozostaje niezastąpiona.

Postrzegam AI jako DOPALACZ Kompetencji. To nie jest substytut, lecz wyrafinowany asystent, który znacząco podnosi jakość i szybkość feedbacku, jaki otrzymujemy. Dzięki niemu łatwiej nam wykrywać anomalie we własnym kodzie, a przy tym jest to nieocenione źródło praktycznej nauki.

Jednym z elementów gdzie używam AI jest review kodu. To dla mnie świetny moment aby sprawdzić swój kod przed wypchnięciem go do repo. Ale również jest to okazja do nauki na co zwracać uwagę gdy sprawdzam kod innych programistek i programistów.

Wiem, że można zaciągnąć do pracy protokoły MCP albo użyć komend Claude Code. Ale celowo robię to w prostszej wersji – żeby każdy początkujący mógł spróbować, zrozumieć mechanizm i dostosować go pod swoje potrzeby bez dodatkowej konfiguracji.

Poniżej przedstawiam Wam, jak skonfigurowałam lokalny, dwufazowy mechanizm AI do automatycznej weryfikacji zmian kodu.

1. Izolacja Środowiska: Czysty Kod, Czyste Review

Podstawą efektywnego Code Review jest praca na świeżej, niezakłóconej wersji kodu. Wierzę, że przeprowadzanie review w tym samym miejscu, w którym intensywnie kodujecie, może prowadzić do zanieczyszczenia kontekstu.

Dlatego proces weryfikacji umieściłam w izolowanym klonie repozytorium. To podejście zapewnia, że mój asystent AI ma dostęp do najnowszej, czystej wersji kodu do porównania.

2. Architektura Konfiguracji: Mój Folder .ai

Potrzebujemy miejsca, gdzie będziemy przechowywać precyzyjne instrukcje dla naszego modelu. Stworzyłam dedykowany katalog .ai w głównym katalogu repozytorium do review.

Kluczowa Reguła: Ten katalog musi być wykluczony z systemu kontroli wersji. Dodanie go do pliku .gitignore gwarantuje, że moje instrukcje (nazywam je Prompt Bookami) pozostaną prywatne i lokalne.

Wewnątrz folderu znajdują się dwa pliki instrukcji: review_thorough.md i review_fast.md. To są dwie konfiguracje, dedykowane różnym poziomom głębokości analizy.

3. Zaawansowana Metodyka: Dwufazowy Mechanizm Weryfikacji

Na poczatku używałam jednego agenta ale bardzo szybko przekonałam się, że dostaję dużo false positives, które potem musze weryfikować.

Więc wprowadziłam dwustopniowy proces, który ma za zadanie eliminować False Positives (fałszywe alarmy) – największą bolączkę pojedynczych modeli.

W pliku instrukcyjnym review_thorough.md wymagam od AI wykonania dwóch faz:

Faza 1: Agent Krytyk (Intensywna Analiza)

Pierwszy model wykonuje intensywny, krytyczny review. Jego zadaniem jest bezlitosne i dociekliwe wykrycie każdego potencjalnego błędu, naruszenia standardów czy wątpliwości architektonicznych.

Faza 2: Agent Weryfikator (Redukcja Szumu)

Drugi model jest uruchamiany bez kontekstu wniosków z Fazy 1. Działa jako filtr antyszumowy. Jego jedyną rolą jest ponowna ocena znalezionych problemów i precyzyjne odrzucenie wszystkiego, co wygląda na błąd, ale nim faktycznie nie jest.

Dopiero po połączeniu wyników z obu faz dostaję wysoce wiarygodną i gotową do działania listę ustaleń.

4. Precyzyjny Zakres

Aby feedback, który otrzymuję, był merytoryczny i dotyczył wyłącznie mojej pracy, AI ma instrukcję aby nie sprawdzać całej funkcjonalności. W instrukcji definiuję, że ma analizować jedynie różnicę (diff) pomiędzy moim obecnym branchem roboczym a gałęzią bazową (develop lub main).

Instrukcja wykonawcza dla AI zawiera taki zapis o zakresie:

[Execution]
execute both phases

[Prompt]
run git diff develop to get changes, read each changed file completely, perform primary review, verify each finding, write final review, and notify when complete with summary.

5. Raport i Uruchomienie – Efektywność CLI

Finalnym rezultatem procesu jest zwięzły, ustrukturyzowany raport, który jest łatwy do przyswojenia i bezpośredniego wykorzystania przy tworzeniu Merge Requesta.

Co Otrzymuję w Raporcie:

• Podsumowanie Zmian: Krótki opis kontekstu ułatwiający zrozumienie, co się zmieniło.
• Kategoryzacja Błędów: Ustalenia wg poziomu ryzyka (Krytyczne, Wysokie, Medium, Małe).
• Ocena Ryzyka Projektowego.
• Rekomendacje: Sugerowane rozwiązania wraz z technicznymi komentarzami.

Uwaga Techniczna: Cała struktura raportu (podsumowanie, kategorie błędów, ocena ryzyka) jest zdefiniowana bezpośrednio w pliku MD (Prompt Book), co pozwala mi precyzyjnie kontrolować, co ma zostać zwrócone przez model AI.

Szybkie Uruchomienie za Pomocą Aliasów

Proces jest uruchamiany lokalnie za pomocą narzędzia CLI zintegrowanego z modelem AI.

Komenda bazowa wygląda następująco:

cat .ai/commands/review_thorough.md | claude --print

Na koniec, żeby nie musieć pamiętać skomplikowanej komendy ustawiłam aliasy, które umożliwiają mi odpalenie review bez sięgania do readme:

# Aliasy w .zshrc lub .bashrc
alias reviewfull='cat .ai/commands/review_thorough.md | claude --print'
alias reviewquick='cat .ai/commands/review_fast.md | claude --print'

Dzięki temu, w każdym projekcie, gdzie mam to skonfigurowane, mogę natychmiast wywołać pełne, dwufazowe review za pomocą prostej komendy reviewfull. A potem skupić się na review mając już bazę.