Automatyczny przegląd kodu w 2026 roku: uruchom go na każdym PR bez kupowania stanowiska.

Automatyczny przegląd kodu to zadanie CI, które wysyła twój diff do modelu językowego, publikuje uwagi na odpowiednich liniach i oznacza kontrolę statusu jako nieudaną, gdy znajdzie coś poważnego. Aby uruchomić to przy każdym pull requescie bez subskrypcji na użytkownika, należy samodzielnie hostować otwartoźródłowy harness: skopiuj do repozytorium workflow liczący około piętnastu linii, dodaj jeden klucz API i płać tylko za tokeny zużywane przez każdy przegląd. Nie ma liczby miejsc do kupienia, bo nie ma miejsc. Implementacja referencyjna, którą utrzymujemy, to repozytorium Orca-Code-Review — publiczne, na licencji MIT, a od czasu utworzenia 25 czerwca 2026 roku jest kodem stojącym za akcją OrcaCode Review GitHub Action. Dołączona konfiguracja routingu domyślnie ustawia przebieg przeglądu na DeepSeek V4 Flash, a niezależnego weryfikatora na GLM-5.3; oba możesz zmienić. W tym artykule omawiamy, co faktycznie uruchamia się przy każdym pushu, co konfigurujesz, ile to kosztuje w tokenach oraz tryby awarii, na które trafisz w drugim tygodniu.

Krótka wersja. Każdy push dostaje jeden przegląd. Ustalenia są zamieszczane bezpośrednio w zmienionych liniach. Ustalenia P0 i P1 oblewają kontrolę i blokują merge; czysty przebieg przechodzi. Możesz wywołać ponowny przegląd na żądanie, komentując /orcacode-review. Workflow mieszka w twoim repozytorium; logika przeglądu mieszka w opublikowanej akcji; wybór modelu mieszka w przepisie routingu, który możesz edytować w swoim workspace. Recenzent czyta diff oraz pliki repozytorium i nigdy nie wykonuje kodu twojego PR. I uczciwe zastrzeżenie z góry: wyłapuje prawdziwe błędy, ale wciąż nie wyłapuje tych, które wymagają człowieka, który wie, dlaczego kod jest taki, jaki jest.

• Jeden workflow + jeden sekret + rachunek za tokeny. Bez licencji per stanowisko w żadnym momencie.

• Harness jest open source. Skopiuj go, sforkuj, przejrzyj i przypnij do SHA commita.

• Model jest ustawieniem, a nie dostawcą. Zmień recenzenta, edytując przepis routingu, a nie przepisując YAML lub podbijając akcję.

• Zbyt duże diffs nic nie kosztują. Strażnik rozmiaru uruchamia się przed modelem.

• Czyta twój kod, ale nigdy go nie uruchamia. To właśnie ta właściwość bezpieczeństwa sprawia, że pull_request_target jest w ogóle bezpieczny w użyciu.

Jak faktycznie działa automatyczny przegląd kodu

Każdy zautomatyzowany system przeglądu to te same trzy składniki w różnych przebraniach: zdarzenie, wykonawca i recenzent.

To wydarzenie jest wyzwalaczem. Dostarczany workflow wyzwala się na zdarzeniach pull request — opened, synchronize (nowy push), ready_for_review (szkic staje się gotowy) — oraz na komentarzu do PR. Ponieważ działa na pull_request_target, definicja workflow jest odczytywana z gałęzi bazowej, dlatego workflow musi istnieć na gałęzi bazowej, zanim będzie mógł zostać uruchomiony dla PR. Jedna recenzja na push; ten concurrency blok anuluje poprzednie uruchomienie, więc szybka sekwencja pushów nie kolejkuje pięciu recenzji nieaktualnego kodu.

Runner to GitHub Actions na ubuntu-latest. Zadanie wymaga trzech uprawnień: dostępu do odczytu zawartości, dostępu do zapisu w pull requestach (aby zamieszczać komentarze w kodzie) oraz dostępu do zapisu w issues (aby publikować podsumowanie i usuwać nieaktualne komentarze).

recenzent jest modelem językowym. Akcja pobiera głowę PR, składa diff oraz kontekst repozytorium wybrany przez silnik, i wysyła to do modelu recenzji. Wynik to zestaw uwag, z których każda jest oznaczona stopniem ważności i przypisana do pliku i linii. Akcja dodaje je jako komentarze inline PR oraz zapisuje jeden komentarz podsumowujący w regionie znaczników na górze opisu PR, nadpisywany w miejscu przy każdym pushu.

bramka to kontrola statusu. GitHub nie wie, co oznacza „review”; wie tylko, czy kontrola review przechodzi. Bramkę czynisz rzeczywistą, oznaczając tę kontrolę jako wymaganą w ochronie gałęzi. To jest cały mechanizm blokowania scalania — żadnych wywołań API administracyjnego, żadnych etykiet, tylko niezaliczona wymagana kontrola.

Co się nie dzieje: nic nie wykonuje kodu PR. Silnik tylko czyta. To właśnie ten jeden niezmiennik sprawia, że uprzywilejowany pull_request_target wyzwalacz jest bezpieczny w użyciu z płatnym kluczem API.

Otwartoźródłowy harness jest wyróżnikiem.

Wszystko powyższe jest prawdziwe w przypadku wielu narzędzi. To, co nie jest prawdą w przypadku większości, to fakt, że całość jest możliwa do inspekcji i samodzielnego hostowania — i właśnie to zapewnia repozytorium Orca-Code-Review. Jest to publiczne repozytorium GitHub na licencji MIT (JavaScript, utworzone 25 czerwca 2026 r.), które pakuje recenzję jako wielokrotnego użytku kompozytowe GitHub Action oraz instalator, i jest to ten sam kod hostowana aplikacja OrcaCode Reviewuruchamia.

Spędź dziesięć minut w drzewie, a będziesz mógł nazwać każdy element, który dotyka twojego PR:

• action.yml — akcja złożona (composite action), około piętnastu udokumentowanych parametrów wejściowych. Nigdzie nie ma w niej zaszytych na stałe nazw modeli.

• workflows/orca-code-review.yml — przykładowy przepływ pracy konsumenta, mniej więcej piętnaście linii, które kopiujesz do .github/workflows/.

• recipes/ — DSL routingu. To tutaj faktycznie wybierany jest model.

• rules/ — skala dotkliwości (P0–P3), obowiązkowy format wyniku oraz dyrektywa dotycząca konwencji, która przekazuje własny dokument konwencji projektu do przeglądu jako niezaufane dane referencyjne.

• scripts/ — precyzyjny filtr (L1 plus sędzia L2), ochrona diff, bramka scalania, raport uruchomienia i licznik tokenów. Każdy to mały, czytelny .mjs plik z testami.

• skills/setup-orca-code-review — umiejętność, którą instalator umieszcza w twoim agencie kodowania, obejmująca instalację, rekonfigurację, rozwiązywanie problemów i odinstalowanie.

• .claude-plugin/ — co pozwala Claude Code zainstalować umiejętność jako samoaplikujący się plugin.

Instalacja to jedno polecenie, które uczy Twoją AI, czym jest produkt, i na tym kończy:

npx @orcarouter/code-review

CLI wykrywa, z których agentów kodujących korzystasz — katalog obejmuje 36 platform, od Claude Code, Cursor, Codex, OpenCode i Windsurf po GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode i inne — instaluje skill i przekazuje dalej. Następnie pytasz swojego agenta w prostym języku: “skonfiguruj OrcaCode Review w tym repozytorium,” “blokuj tylko P0,” “dlaczego przegląd nie został uruchomiony?” Skill prowadzi cały cykl życia: tworzy workflow, przeprowadza cię przez klucz API, ustawia bramkę i zadaje tylko pytania, które naprawdę są twoje.

Claude Code może zamiast tego zainstalować umiejętność jako wtyczkę, co zapewnia jej aktualność w miarę rozwoju repozytorium:

Dodaj wtyczkę Continuum-AI-Corp/orca-code-review z marketplace

/zainstaluj wtyczkę orca-code-review

Żaden agent? Cykl życia to po prostu podkomendy — init zapisuje przepływ pracy, reconfigure zmienia reguły blokowania i limity diffów, doctor diagnozuje przeglądy, które nie działają lub nie są publikowane, uninstall usuwa go (najpierw usuwając wymagany check). Skill to główne wejście, a nie jedyne drzwi. Albo skonfiguruj to ręcznie: skopiuj przepływ pracy, dodaj jeden sekret o nazwie ORCAROUTER_API_KEY, a następnie oznacz review check jako wymagany.

Silnikiem pod spodem jest Open Code Review firmy Ali​baba, przypięte do dokładnej wersji i licencjonowane na Apache-2.0. OrcaCode decyduje, jak przeprowadzić przegląd; OrcaRouter decyduje, jaki model go uruchamia. Rachunek porównujący samodzielne hostowanie a hosting zarządzany — ile „za darmo” naprawdę kosztuje, gdy samodzielnie hostujesz recenzenta open source — jest omówiony w naszym artykule na temat otwartego przeglądu kodu.

Co uruchamia się po kolei przy każdym pushu?

Warto znać kolejność, ponieważ każdy krok może niezależnie zakończyć się niepowodzeniem lub zostać pominięty:

• Strażnik diffa uruchamia się jako pierwszy, zanim model w ogóle zadziała. Jeśli diff merge-base przekracza 512 KB lub obejmuje więcej niż 300 plików, przegląd jest pomijany i pojawia się powiadomienie. Wartość domyślna to on-oversized-diff: fail, więc diff rozszerzony ponad limity nie może przejść przez wymaganą bramkę bez przeglądu. Jest to również kontrola kosztów: zbyt duży PR kosztuje zero tokenów.

• Silnik przegląda diff.Jeden przebieg, współbieżność per plik domyślnie 24, z limitem czasu rzeczywistego wynoszącym 20 minut na przebieg.

• Filtr precyzji poddaje surowe wyniki dalszemu przetwarzaniu. L1, filtr deterministyczny, weryfikuje zadeklarowany fragment istniejącego kodu każdego znaleziska względem przejrzanego commita i przenosi lub odrzuca niezgodności. L2, sędzia LLM, grupuje znaleziska według przyczyny źródłowej i odrzuca klastry o niskim stopniu pewności. Obie warstwy działają w trybie soft-fail: błąd zachowuje znaleziska z poprzedniego etapu i nigdy nie przerywa przeglądu.

• Bramka ma zastosowanie. Problemy P0 i P1 powodują niepowodzenie kontroli; podsumowanie PR uwzględnia każdy problem, w tym te wyciszone z diffa.

• Licznik drukuje, ile to kosztowało. Ten licznik rejestruje rozliczenie tokenów dla każdego wywołania — prompt, completion, tokeny z pamięci podręcznej oraz model wybrany przez router — i drukuje tabelę sum w dzienniku zadań.

• Opcjonalny raport uruchomienia przesyła liczniki ważności i metadane bramki do płaszczyzny kontrolnej OrcaRouter na potrzeby panelu analitycznego. Nie zawiera kodu, diffa ani treści ustaleń.

Co faktycznie konfigurujesz

Są trzy powierzchnie i mają bardzo różny promień rażenia.

1. Plik przepływu pracy. Przepływ pracy odbiorcy jest celowo minimalny. Dane wejściowe, które warto modyfikować, znajdują się w akcji: block-on (które poziomy ważności powodują niepowodzenie kontroli — domyślnie P0,P1), fix-first (które poziomy ważności wcześnie przerywają wyczerpujący przegląd), auto-review-authors (lista dozwolonych autorów podlegających automatycznemu przeglądowi), max-diff-kb i max-diff-files i on-oversized-diff (zabezpieczenie rozmiaru), timeout-minutes, concurrency, meter i report. Każdy z nich ma udokumentowaną wartość domyślną, więc nowy przepływ pracy to pięć linii YAML plus sekret.

2. Panel. Przy settings: true (domyślnie), każde uruchomienie pobiera ustawienia repozytorium z OrcaRouter → Apps → OrcaCode Review: model, tryb przeglądu, zasady scalania, poziomy ważności raportów, tryb cichy, wyczerpujący przegląd, własna rubryka i zabezpieczenia. Ustaw settings: "false", a plik przepływu pracy ma pierwszeństwo — żadna wartość panelu nie może go nadpisać. Jeśli nigdy nie otworzysz konsoli, nie tracisz niczego z zestawu narzędzi; po prostu konfigurujesz w YAML.

3. Przepis routingu — ten, którego ludzie przeoczają. Akcja nigdy nie wymienia modelu z nazwy. Zamiast tego wstrzykuje surowe fakty jako nagłówki żądań — na którym poziomie (tier) zapisano uruchomienie, czy poprzednie przejście znalazło P0/P1, oraz znacznik lens, gdy żądanie pochodzi od sędziego L2 — a przepis DSL routera workspace'u mapuje te nagłówki na konkretny model. Dostarczany przepis domyślnie ustawia przegląd na DeepSeek V4 Flash, a sędziego na GLM-5.3, celowo kierując oba do osobnych modeli. Zmiana modelu, który przegląda Twój kod, to edycja tego przepisu we własnym workspace'u: bez zmiany wersji akcji, bez przepisywania YAML-a, bez ponownego wdrożenia.

Kontrakt wag to dwa niezależne ustawienia, a nie jedno. Polityka scalania decyduje o tym, co blokuje scalenie; raportowanie wag decyduje o tym, co trafia na diff. Domyślne ustawienia dostarczane z produktem to: P0/P1 blokują, P2/P3 przepuszczają. Waga, która blokuje, jest zawsze raportowana, niezależnie od ustawienia raportowania — nieudana kontrola bez wyjaśnienia na diffie jest gorsza niż zbyt hałaśliwa. P0 oznacza możliwy do wykorzystania błąd bezpieczeństwa, utratę danych, awarię na normalnej ścieżce działania lub zepsuty build; P1 oznacza rzeczywisty, ale ograniczony błąd; P2 oznacza prawdziwą wadę, która ujawnia się tylko przy nietypowym warunku wstępnym; P3 to kwestia stylu. Gdy wahasz się między dwoma poziomami, reguła mówi: wybierz niższy.

Ile to kosztuje

Za token, a nie za stanowisko. Wybierasz model na OrcaRouter, rozliczenia naliczane są za zużyte tokeny, a licznik sprawia, że liczba dotycząca pojedynczego uruchomienia jest widoczna, a nie owiana tajemnicą. Mechanika GitHuba, licznikowy przegląd kodu Copilota od 1 czerwca 2026 roku oraz sposób, w jaki zewnętrzni recenzenci wpisują się w ten przepływ pracy, opisaliśmy w naszym przewodniku po przeglądach kodu na GitHubie. Pełne porównanie kosztów pole po polu — produkty za stanowisko a te rozliczane za tokeny, z przykładem obliczeniowym — znajdziesz w naszym porównaniu narzędzi do przeglądów kodu AI, a pytanie, ile tokenów kosztuje pojedynczy przebieg przeglądu, gdy recenzent faktycznie eksploruje repozytorium (rozróżnienie bot kontra agent), znajduje się w naszym artykule o agentach do przeglądów kodu. Nowością, jaką wnosi ten artykuł, jest kształt rachunku: skaluje się on wraz z ilością przeglądanego kodu, a nie z liczbą osób, które go przeglądają.

Dwie kontrole wydatków są istotne od pierwszego dnia. W publicznym repozytorium, pull_request_target omija bramkę zatwierdzania forków w GitHubie, a klucz przeglądu jest rozliczany z portfela — obca osoba może otworzyć PR i uruchomić płatne przeglądy. Ustaw budżet portfela z alertami dla klucza i ustaw auto-review-authors na coś w rodzaju OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR tak, aby nieznani autorzy nie byli automatycznie recenzowani. A strażnik diffów, jak już wspomniano, oznacza, że bardzo duże PR-y nic nie kosztują.

Co się psuje

Automatyczny przegląd to CI. Psuje się jak CI, a tryby awarii w większości nie są winą modelu:

• Workflow nigdy się nie uruchamia. W przypadku pull_request_target workflow jest odczytywany z gałęzi bazowej — workflow dodany tylko w gałęzi PR nie zostanie uruchomiony, dopóki nie zostanie scalony. Sprawdź również, czy aplikacja jest włączona, auto_review jest włączone, PR nie jest szkicem (w trybie ready_for_review szkice są pomijane) oraz czy Actions są włączone w repozytorium (w repozytoriach sforkowanych są one domyślnie wyłączone).

• /orcacode-review nic nie robi. Wyzwalacz komentarza wymaga, aby komentarz zaczynał się od jednej z czterech pisowni — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — oraz aby komentujący był WŁAŚCICIELEM, CZŁONKIEM lub WSPÓŁPRACOWNIKIEM. Spacja na początku przerywa dopasowanie. Polecenie zewnętrznego kontrybutora jest celowo ignorowane w milczeniu: polecenie uruchamia uprzywilejowany przepływ pracy posiadający płatny klucz.

• Błąd uwierzytelnienia. Sekret jest źle nazwany lub nie istnieje, klucz został unieważniony lub przekroczono budżet, albo przepływ pracy został przełączony na pull_request (który nie może odczytywać sekretów z forków).

• Kontrola jest czerwona z komunikatem “diff too large”. To strażnik rozmiaru działający zgodnie z konfiguracją. Podziel PR, podnieś limity albo ustaw on-oversized-diff: pass — i pamiętaj, że przy wymaganej kontroli pass oznacza, że odpowiednio duży PR przechodzi przez bramkę bez przeglądu.

• Przegląd działa, ale nie pojawiają się żadne komentarze. Trzy przyczyny, wszystkie niegroźne lub wynikające z konfiguracji: czyste uruchomienie publikuje podsumowanie zamiast komentarzy w kodzie; tryb cichy wycisza P2 w momencie publikowania (bramka i raport nadal to uwzględniały); albo filtr precyzji odrzucił ustalenia — L1 odrzuca ustalenia, których fragment nie pasuje do commita, L2 odrzuca klastry o niskim poziomie ufności. Liczby poziomów ważności w logu zadania powiedzą ci, która to przyczyna.

Postawa bezpieczeństwa warta jest jasnego przedstawienia, ponieważ to ona sprawia, że cały projekt jest bezpieczny. Silnik odczytuje wyłącznie diff i pliki repozytorium; nigdy nie wykonuje kodu PR. Recenzent nie ma uprawnień do scalania — ustalenia mogą zablokować scalenie lub dodać komentarz, ale żadna ścieżka kodu nie pozwala, aby wynik modelu zatwierdził lub zmodyfikował repozytorium. Nieoznaczone ustalenie działa w trybie fail-safe i jest traktowane jako blokujące, a nie doradcze. Raport uruchomienia nie zawiera ani kodu, ani treści ustaleń. Dwupoziomowe rozwiązanie, które wychwytuje to, czego przeoczy przegląd jednoprzebiegowy, jest tematem naszego artykułu o bezpieczeństwie przeglądu kodu AI; powyższy model zagrożeń jest udokumentowany w pliku SECURITY.md repozytorium.

Kiedy automatyczna recenzja jest niewłaściwym narzędziem

To jest błędne częściej, niż przyznają dostawcy narzędzi. Odpuść sobie, gdy:

• Problem to kontekst, a nie objętość. Jeśli przeglądy są wolne, ponieważ recenzenci muszą zrozumieć, dlaczego kod został napisany w ten sposób, to model LLM czytający diff niewiele wnosi. Nie ma pamięci wątku z zeszłego miesiąca ani wyczucia historii systemu.

• Diff to głównie kod wygenerowany lub zależności dołączone do repozytorium. Wynik automatycznego formatowania, pliki szkieletowe, migawki zależności. Przeglądanie tego pochłania tokeny i generuje szum, a to właśnie tam dyrektywa konwencji pomaga najmniej — kod nie jest w stylu projektu z wyboru.

• Zespół już przegląda wszystko parami.Automatyczny przegląd to dźwignia wolumenu. Jeśli każda zmiana jest już recenzowana przez człowieka, który był w pokoju, maszyna dodaje drugą opinię, która zwykle jest mniej poinformowana niż pierwsza.

• Nikt nie czyta ustaleń. Recenzja, na którą nikt nie reaguje, to proces, który wiecznie pozostaje zielony, mimo że zawodzi. To najczęstsza cicha awaria i żaden filtr precyzji jej nie naprawi.

• Przegląd musi uruchomić kod. Jeśli potrzebujesz zestawu testów dla PR, przegląd LLM jest niewłaściwym narzędziem. Czyta; nie wykonuje. Skan bezpieczeństwa, który wymaga zbudowania i uruchomienia artefaktu, powinien trafić do osobnego zadania o ściśle określonym zakresie — pamiętaj, że przepływ pracy przeglądu nigdy nie może zostać rozszerzony o uruchamianie kodu kontrolowanego przez PR.

• Repozytorium jest małe lub tymczasowe. Poniżej pewnego tempa zmian przegląd generuje więcej narzutu niż błędy, które wyłapuje.

Fałszywe pozytywy i to, co filtrowanie precyzji naprawia, a czego nie.

Każdego recenzenta AI oskarża się o to, że woła wilka. Uprząż atakuje ten problem na dwóch warstwach i warto precyzyjnie określić, która warstwa naprawia który błąd.

Warstwa deterministyczna (L1) eliminuje widmowe znaleziska: silnik czasami wskazuje kod, którego nie ma — fragment, który się przesunął, znalezisko skopiowane do pliku siostrzanego. L1 weryfikuje fragment istniejącego kodu każdego znaleziska względem faktycznie przejrzanego commita oraz przenosi do właściwego miejsca lub odrzuca niezgodności. To naprawia klasę fałszywych pozytywów „ta linia w ogóle nie istnieje”, która jest mechaniczna i weryfikowalna.

Warstwa sędziowska (L2) eliminuje duplikat i nieuzasadnione zgłoszenie: sędzia LLM grupuje ustalenia według przyczyny źródłowej i odrzuca klastry, których pewność spada poniżej progu sędziowskiego (domyślnie 0,5). To naprawia „ten sam błąd zgłoszony na trzy sposoby” i spekulatywne ustalenie.

To, czego nie naprawia żadna z tych warstw, warto powiedzieć wprost. Błędne, ale pewne siebie znalezisko przechodzi przez sędziego — sędzia jest modelem językowym, a model, który brzmi pewnie, to nie to samo co znalezisko, które jest prawdziwe. Sędzia korzystający z tego samego modelu co recenzent zgadza się z samym sobą, a przebieg staje się bezczynny, wciąż raportując sukces — dlatego dołączony przepis kieruje sędziego do innego modelu niż recenzent. A rubryka ważności jest celowo konserwatywna — „gdy wahasz się między dwoma poziomami, wybierz niższy” — co oznacza, że prawdziwy, ale warunkowy błąd częściej trafi jako zalecenie P2 niż jako blokujący P1. To właściwa kalibracja dla narzędzia, które nie może blokować wszystkiego, ale to tylko kalibracja: wymienia pominięte błędy blokujące na mniejszą liczbę fałszywych alarmów. Podsumowanie PR zawsze uwzględnia każde znalezisko, więc te wyciszone P2 wciąż są tam do przeczytania. Jeśli ten kompromis nie pasuje twojemu zespołowi, rubryka i próg sędziego to kwestia konfiguracji, a nie zgłoszenia wsparcia.

Najważniejsze

Dla zespołu, który już pracuje w GitHub Actions, narzędzie open-source to najtańszy sposób na automatyczny przegląd kodu w każdym PR: jeden plik workflow, jeden sekret, rachunek za tokeny skalujący się z ilością przeglądanego kodu oraz wybór modelu, który w pełni kontrolujesz. Kup produkt per stanowisko, gdy chcesz zero obsługi i dostawcę pod telefon — nie dlatego, że przegląd jest lepszy, ale dlatego, że kupujesz cudzy problem zamiast zajmować się własnym. A zanim cokolwiek skonfigurujesz, zapytaj, czy przegląd w ogóle zostanie przeczytany. Narzędzie może automatycznie wygenerować przegląd. Nie może jednak sprawić, że ktokolwiek go przeczyta.

Chcesz tego samego recenzenta bez uruchamiania go samodzielnie? OrcaCode Review uruchamia ten sam harness jako hostowaną aplikację GitHub — ta sama otwarta receptura, ta sama opłata za token, bez opłat za stanowiska.