AI code review: jak automatycznie przeglądać pull requesty

Polecenia z tego poradnika zostały uruchomione 9 października 2026 w czystym systemie (Ubuntu 24.04.5 LTS, Node.js 24.21.0, Python 3.12.3). Wyniki pod poleceniami pochodzą z tego uruchomienia.

AI code review to przegląd zmian w kodzie przez narzędzie AI, które wskazuje potencjalne problemy i proponuje poprawki. Automatyzację można uruchamiać po otwarciu pull requesta, a zależnie od konfiguracji również po kolejnych commitach. Na przykład GitHub pozwala ustawić oba momenty w regułach automatycznych przeglądów Copilota.

Polecam zacząć od jednego repozytorium: bot zgłasza uwagi, autor je weryfikuje, a człowiek podejmuje decyzję o scaleniu. Do tego potrzebne są kryteria przeglądu, testy i pomiar trafności komentarzy. GitHub wskazuje wprost, że Copilot może pomijać problemy, zgłaszać fałszywe alarmy i proponować błędne poprawki, dlatego zaleca weryfikację uwag oraz przegląd przez człowieka.

Dokumentację sprawdziłem 9 października 2026 r.

W skrócie

• Polecam oddać botowi pierwszy przegląd, np. sprawdzenie obsługi błędów w zmienionym endpoincie.
• W pilotażu zachowałbym zatwierdzanie zmian przez programistę i dotychczasowe wymagania testów.
• Wybór narzędzia zacząłbym od porównania sposobów uruchamiania oraz konfiguracji reguł.
• Sukces oceniałbym po potwierdzonych problemach i czasie weryfikacji, a nie liczbie komentarzy.

Jak włączyć AI code review w proces zespołu

Pull request, w skrócie PR, przedstawia zmiany do przeglądu przed scaleniem z docelową gałęzią. Diff pokazuje różnice w plikach. W proponowanym przeze mnie procesie AI analizuje zmianę, autor sprawdza zgłoszenia, a recenzent ocenia całość wraz z wynikami testów.

flowchart TD
    A[Otwarcie PR] --> B[Przegląd AI]
    A --> C[Testy i analiza statyczna]
    B --> D[Weryfikacja uwag]
    D --> H{Potrzebne poprawki?}
    H -->|Tak| E[Poprawki autora]
    E --> D
    E --> C
    H -->|Nie| I[Weryfikacja zakończona]
    I --> J{"Aktualne wyniki testów<br/>i zakończona weryfikacja uwag?"}
    C --> J
    J -->|Nie: czekaj| J
    J -->|Tak| F[Przegląd człowieka]
    F --> G[Decyzja o scaleniu]

Przy zmianie płatności poprosiłbym AI o sprawdzenie, co stanie się po ponowieniu żądania. Autor powinien zweryfikować scenariusz podwójnego obciążenia, a recenzent ocenić zgodność z zasadami produktu. Obsługę tego przypadku polecam też sprawdzić testem regresji, czyli testem chroniącym przed powrotem błędu.

Formatterowi zostawiłbym formatowanie, linterowi sprawdzanie ustalonych reguł, a AI pytania o zachowanie zmienionego kodu. Taki podział polecam zapisać w instrukcjach, żeby bot nie zajmował zespołu uwagami o wcięciach.

Copilot, Bugbot czy CodeRabbit?

Porównuję mechanizmy pracy z PR-ami. Nie wskazuję zwycięzcy jakościowego bez sprawdzenia narzędzi na tym samym kodzie.

Jeżeli zespół korzysta z Copilota, zacząłbym od sprawdzenia jego przeglądów na istniejącym repozytorium. Gdy potrzebuję innego sposobu konfiguracji, porównałbym pozostałe narzędzia na tych samych zmianach: endpoincie API, migracji bazy i poprawce obsługi błędu.

Jak ustawić automatyczny przegląd na GitHubie

Pilotaż zacząłbym od automatycznych przeglądów własnych PR-ów. Ta konfiguracja jest dostępna w planach Copilot Pro, Pro+, Max oraz z licencją Business lub Enterprise; nie jest dostępna dla kont zarządzanych. Warunki i kroki opisuje instrukcja osobistych ustawień code review.

Przy Copilocie otrzymanym od organizacji musi ona również włączyć code review w politykach, zgodnie z warunkami dostępności funkcji.

1. Kliknij zdjęcie profilowe w prawym górnym rogu GitHuba i wybierz Copilot settings.
2. W menu bocznym, pod Copilot, wybierz Code review.
3. Włącz Automatic Copilot code review.
4. Jeśli potrzebujesz przeglądu po kolejnych commitach, włącz Review new pushes.
5. Jeśli chcesz uwag także podczas pracy nad draftem, włącz Review draft pull requests.

Po konfiguracji otwórz przykładowy PR i sprawdź, czy pojawił się przegląd. Następnie dodaj commit, jeśli włączono sprawdzanie nowych pushów. Oczekiwanym wynikiem jest kolejna ocena zmian zgodna z wybranym trybem.

Przy wdrożeniu dla zespołu GitHub pozwala ustawić automatyczne przeglądy przez reguły repozytorium lub organizacji. Polecam zacząć od gałęzi domyślnej, korzystając z instrukcji konfiguracji reguł.

Jakie instrukcje przekazać recenzentowi AI

Copilot obsługuje instrukcje dla całego repozytorium w .github/copilot-instructions.md. Podczas przeglądu czyta je z gałęzi zawierającej zmiany, zgodnie z dokumentacją własnych instrukcji. Polecam opisać oczekiwane zgłoszenie: miejsce, warunek wystąpienia i skutek błędu.

W repozytorium na GitHubie wybierz gałąź zawierającą zmiany PR-a, a następnie przez Add file i Create new file utwórz plik .github/copilot-instructions.md:

Podczas przeglądu kodu pisz komentarze po polsku.

Skupiaj się na błędach zachowania, bezpieczeństwie i regresjach.
Pomijaj uwagi o formatowaniu, które sprawdza formatter lub linter.

Dla zgłaszanego problemu wskaż plik, warunek wystąpienia
i możliwy skutek. Jeśli brakuje kontekstu, nazwij tę niepewność.

Przy zmianach API sprawdzaj walidację danych, autoryzację
i zachowanie po ponowieniu żądania.

Przy proponowanej poprawce opisz test, który wykryje błąd.
Nie twierdź, że test został wykonany, jeśli go nie uruchomiono.

Zapisz plik i uruchom przegląd w tej kolejności:

1. Kliknij Commit changes..., wpisz opis commita i wybierz zapis w bieżącej gałęzi PR-a.
2. Kliknij Commit changes, aby zapisać plik na GitHubie, zgodnie z instrukcją tworzenia plików.
3. Dopiero po zapisaniu pliku otwórz PR i pod Reviewers, obok Copilota, kliknij Request. Jeśli Copilot już przeglądał ten PR, użyj przycisku ponownego przeglądu obok jego nazwy w Reviewers, zgodnie z instrukcją uruchamiania przeglądu.

To moja przykładowa treść instrukcji, którą należy dostosować do projektu. Oczekiwany rezultat to uwagi odnoszące się do tych kryteriów; sprawdziłbym go na PR-ze zmieniającym walidację API. Samo zapisanie reguły nie daje gwarancji, że model wykryje każdy błąd.

Jak ocenić trafność i koszt przeglądów

Polecam pilotaż na 20 kolejnych PR-ach. To proponowana próbka robocza, nie branżowy standard ani obietnica miarodajnego benchmarku.

1. Dla każdego komentarza zapisz: potwierdzony problem, fałszywy alarm, sugestia opcjonalna albo brak możliwości rozstrzygnięcia.
2. Zmierz czas potrzebny autorowi na sprawdzenie uwag.
3. Odnotuj problemy znalezione przez człowieka lub testy, które bot przeoczył.
4. Zestaw wyniki z kosztem przeglądów i liczbą uruchomień na PR.

Przykładowo: 8 potwierdzonych problemów na 20 rozstrzygniętych zgłoszeń oznacza trafność 40% w tej próbce. To ilustracja obliczenia, nie wynik narzędzia. Sugestie opcjonalne policzyłbym osobno, żeby propozycja zmiany nazwy nie miała tej samej wagi co błąd autoryzacji.

W Copilocie koszty obejmują kredyty AI za przegląd oraz minuty GitHub Actions za możliwości agentowe, zgodnie z opisem rozliczania code review. Dlatego w pilotażu sprawdziłbym również koszt całego PR-a po wszystkich poprawkach.

Jak ograniczyć dostęp do kodu

Przed podłączeniem narzędzia polecam sprawdzić zakres dostępu do repozytoriów, zasady przechowywania danych i ustawienia użycia kodu przez dostawcę. Zacząłbym od jednego repozytorium oraz wyznaczył osobę odpowiedzialną za konfigurację integracji.

W szczególności sprawdziłbym, kto może zmieniać instrukcje przeglądu. Polecam ręcznie oceniać zmianę samego pliku instrukcji, np. usunięcie wymogu sprawdzenia autoryzacji. Przy PR-ze dotyczącym autoryzacji zachowałbym obowiązkowy przegląd programisty znającego model uprawnień aplikacji.

FAQ

Czy AI code review zastąpi przegląd programisty?

W moim proponowanym procesie człowiek zatwierdza zmianę. GitHub zaleca uzupełnianie przeglądów Copilota oceną człowieka, ponieważ model może przeoczyć problem lub zaproponować błędny kod. Przykładową poprawkę autoryzacji polecam zweryfikować także testem odmowy dostępu.

Czy Copilot może zatwierdzić pull request?

Tak, po włączeniu odpowiednich ustawień może wystawić zatwierdzenie spełniające wymagania repozytorium. Funkcja jest w public preview, a domyślnie przegląd nie liczy się jako wymagane zatwierdzenie, co opisuje instrukcja zatwierdzania przez Copilota. W pilotażu polecam zachować zatwierdzenie człowieka.

Czy bot sprawdza każdy nowy commit?

Zależy to od narzędzia i ustawień. W Copilocie ponowny automatyczny przegląd wymaga opcji Review new pushes; można też poprosić ręcznie o kolejny przegląd. Po poprawieniu zgłoszonego błędu sprawdziłbym, którego commita dotyczy ostatnia ocena.

Czy AI code review jest bezpieczne dla prywatnego kodu?

Nie traktowałbym samego statusu repozytorium jako wystarczającego kryterium wyboru integracji. Polecam sprawdzić osobno uprawnienia aplikacji i zasady przetwarzania danych. Przykład decyzji: dopuścić pilotaż dopiero po ustaleniu zakresu dostępu do kodu.

Co dalej

Polecam wpisać przeglądy PR-ów w szersze zasady pracy. Jeśli kolejną decyzją jest wybór narzędzia dla zespołu, porównaj Cursora, Claude Code i Copilota na tych samych zmianach.