Qodo, przegląd kodu i testy z AI

Qodo, czyli przegląd kodu, który dzieje się sam

Qodo zajmuje się dwiema rzeczami, których programiści nie lubią robić, a które decydują o jakości projektu: przeglądem zgłoszeń scalenia i pisaniem testów. Obok produktu istnieje otwarty silnik przeglądu, który da się uruchomić u siebie.

Narzędzie działa w dwóch miejscach. W repozytorium komentuje zgłoszenia scalenia, podsumowuje zmiany i wskazuje problemy przy konkretnych liniach. W edytorze pomaga pisać kod i generuje testy, sprawdzając przy okazji, czy funkcja robi to, co obiecuje jej nazwa.

Projekt działał wcześniej pod inną nazwą i zmienił ją pod koniec 2024 roku. Ta zmiana bywa źródłem zamieszania przy szukaniu materiałów, bo starsze wpisy i część odnośników nadal używają dawnej nazwy.

Otwarty rdzeń, czyli najciekawsza część

Istnieje otwarty silnik przeglądający zgłoszenia scalenia, wydany na licencji permisywnej i uruchamiany we własnej infrastrukturze. Zanim policzysz na tym oszczędności, trzeba jednak zrozumieć, czym on dziś jest, bo relacja między nim a produktem się zmieniła.

Projekt wyprowadzono spod skrzydeł firmy i jest dziś utrzymywany przez społeczność jako rozwiązanie zastane, a firma występuje w nim wyłącznie w roli sponsora. Twórcy piszą wprost, że to nie jest darmowy wariant produktu, tylko osobny projekt. Płatna oferta opiera się na innym, bogatszym w funkcje silniku, więc porównując oba warianty, porównujesz dwa różne narzędzia, a nie dwa sposoby wdrożenia tego samego.

Wariant zarządzany działa jako aplikacja podpięta do repozytorium, płatny według planu. Wariant otwarty uruchamiasz w kontenerze, podając własne klucze do modelu, i płacisz wyłącznie za zużycie modelu.

Ten drugi wariant bywa wyraźnie tańszy, natomiast koszt utrzymania spada na Ciebie: aktualizacje, obsługa zdarzeń z repozytorium i infrastruktura. Przy dwóch osobach w zespole ta praca kosztuje więcej niż abonament, przy dwustu proporcja się odwraca.

Warto policzyć oba warianty na własnym ruchu. Przy stu zgłoszeniach scalenia miesięcznie liczy się co innego niż przy tysiącu, a przy projekcie otwartym istnieje jeszcze osobna ścieżka bezpłatnego dostępu.

Wybór modelu przy wariancie własnym też należy do Ciebie i to on decyduje o rachunku. Ustawia się go w tym samym pliku konfiguracyjnym, razem z modelem zapasowym na wypadek niedostępności głównego.

[config]
model = "gpt-5.6"
fallback_models = ["gpt-5.6-terra"]
git_provider = "github"

Tu leży największa różnica kosztowa między wariantami. Model mocniejszy podnosi trafność uwag przy zmianach obejmujących wiele plików, a przy drobnych poprawkach nie wnosi nic poza rachunkiem, więc zejście na tańszy model przy prostych zgłoszeniach bywa skuteczniejsze niż jakiekolwiek strojenie reguł.

Wdrożenie u siebie ma też argument, który przy części firm przesądza sprawę niezależnie od kosztu: kod nie opuszcza infrastruktury poza wywołaniem modelu, a nawet to da się skierować do modelu uruchomionego lokalnie.

Sprawdzenie tego wariantu nie wymaga niczego poza kontenerem i dwoma kluczami, więc decyzję da się oprzeć na własnym repozytorium zamiast na opisie.

docker run --rm -it \
  -e OPENAI__KEY=$OPENAI_API_KEY \
  -e GITHUB__USER_TOKEN=$GITHUB_TOKEN \
  pragent/pr-agent:latest \
  --pr_url https://github.com/firma/projekt/pull/128 review

Uruchom to na kilku zamkniętych już zgłoszeniach i porównaj uwagi z tym, co faktycznie wyszło w przeglądzie przez człowieka. To jedyny sposób, żeby ocenić przydatność przed wdrożeniem, a kosztuje tyle co kilka wywołań modelu.

Okres próbny i model rozliczeń

Stałego planu darmowego tu nie ma i to pierwsza rzecz do sprawdzenia, bo starsze materiały opisują próg, którego dziś nie znajdziesz. Producent pisze o tym wprost w odpowiedziach na pytania przy cenniku. Każda przestrzeń robocza zaczyna od czternastodniowego okresu próbnego bez podawania karty, z nieograniczoną liczbą przeglądów i kredytów, a po jego zakończeniu przeglądy się zatrzymują, dopóki nie wybierzesz planu płatnego.

Rozliczenie idzie kredytami z jednej puli przypisanej do przestrzeni roboczej, a nie do osoby, więc liczba programistów nie podnosi rachunku wprost. Kredyt kosztuje 0,012 USD, a paczki układają się tak: 2500 kredytów za 30 USD miesięcznie, co dostawca szacuje na jakieś osiemnaście przeglądów, dalej 5000 kredytów na około trzydzieści sześć przeglądów i 20 000 kredytów na około sto czterdzieści cztery. Plan Pro Team rozlicza się miesięcznie, bez zobowiązania rocznego, i jest przewidziany dla zespołów do trzydziestu osób, a powyżej zaczyna się oferta korporacyjna z wyceną indywidualną.

Dwie rzeczy w tym modelu przesądzają o rachunku i łatwo je przeoczyć. Pierwsza: niewykorzystane kredyty przepadają na koniec każdego cyklu, cykl startuje z pełną pulą od nowa, więc paczka kupowana z dużym zapasem to pieniądze wyrzucone. Druga: po wyczerpaniu puli przeglądy nie stają w miejscu, tylko przechodzą w zużycie nadmiarowe rozliczane po tej samej stawce za kredyt, bez dopłaty karnej, do samodzielnie ustawionego miesięcznego limitu wydatku. Dopiero ten limit zatrzymuje przeglądy i to jego wysokość, a nie rozmiar paczki, wyznacza górną granicę rachunku.

Osobno istnieje bezpłatny program dla projektów otwartych, do którego trzeba się zgłosić i przejść kwalifikację. To jedyna ścieżka stałego darmowego dostępu do wariantu zarządzanego.

Przy wariancie własnym rachunek wygląda inaczej i jest przewidywalny: płacisz za wywołania modelu. Koszt jednego przeglądu zależy od rozmiaru zmiany i mieści się zwykle w granicach kilku do kilkudziesięciu centów, przy czym duże zgłoszenia są tu wyraźnie droższe, bo cały kontekst trafia do modelu.

Z tego wynika praktyczna wskazówka, przydatna niezależnie od narzędzia. Małe zgłoszenia scalenia są tańsze w przeglądzie automatycznym i lepsze w przeglądzie ludzkim, więc podział dużej zmiany na kilka mniejszych opłaca się podwójnie.

Przegląd zgłoszeń w praktyce

Po podpięciu do repozytorium narzędzie reaguje na nowe zgłoszenia samo albo na wywołanie poleceniem w komentarzu.

/review
/describe
/improve
/ask czy ta zmiana wplywa na wydajnosc zapytania?

Pierwsze polecenie uruchamia przegląd wskazujący problemy przy konkretnych liniach. Drugie generuje opis zmiany, co bywa najbardziej niedocenianą funkcją, bo opis napisany przez autora zwykle brzmi „poprawki", a opis wygenerowany z różnicy faktycznie mówi, co się zmieniło.

Trzecie proponuje konkretne poprawki jako gotowe zmiany do zaakceptowania jednym kliknięciem. Czwarte pozwala zadać pytanie o zmianę, i to jest funkcja szczególnie przydatna dla recenzenta wchodzącego w nieznany mu fragment kodu.

Konfiguracja opisuje, co ma się dziać automatycznie i na co narzędzie ma zwracać uwagę.

[pr_reviewer]
require_security_review = true
num_max_findings = 3

[pr_code_suggestions]
num_code_suggestions_per_chunk = 3
max_number_of_calls = 3

[pr_description]
publish_labels = true

Objętość reguluje się w dwóch miejscach, bo przegląd i propozycje poprawek to osobne polecenia z osobnymi limitami. Pierwszy klucz ogranicza liczbę uwag w przeglądzie, dwa kolejne liczbę propozycji, która w trybie rozszerzonym mnoży się przez liczbę przebiegów. Warto zejść z obiema wartościami do kilku najważniejszych pozycji, bo przegląd zwracający dwadzieścia uwag przy każdym zgłoszeniu przestaje być czytany po tygodniu, a to jest najczęstsza przyczyna porzucenia takiego narzędzia w zespole.

Drugą przyczyną jest brak ustalenia, czy uwagi są blokujące. Narzędzie komentujące zgłoszenie bez jasnej zasady, kiedy trzeba się do niego zastosować, zamienia się w szum, który wszyscy przewijają. Wybór jednej kategorii, na przykład bezpieczeństwa, jako blokującej i traktowanie reszty jako podpowiedzi działa lepiej niż udawanie, że wszystkie uwagi ważą tyle samo.

Testy i granice tego podejścia

Druga część oferty dotyczy testów, i tu warto postawić sprawę uczciwie.

Narzędzie potrafi wygenerować przypadki testowe dla funkcji, w tym warunki brzegowe, o których łatwo zapomnieć: pusta lista, wartość ujemna, brak wartości, przekroczenie zakresu. To jest realna wartość, bo właśnie te przypadki najczęściej wypadają z ludzkiego zestawu.

Ograniczenie jest zasadnicze i wynika z tego, jak takie narzędzie działa. Test wygenerowany z kodu sprawdza, że kod robi to, co robi, a nie że robi to, co powinien. Jeśli funkcja licząca rabat ma błąd w progu, wygenerowany test utrwali ten błąd jako oczekiwane zachowanie.

Wniosek praktyczny nie brzmi „nie używaj", tylko określa właściwą kolejność. Testy dla logiki biznesowej pisz sam, wychodząc od wymagań. Generowania używaj do pokrycia przypadków brzegowych wokół już poprawnej logiki oraz do kodu pomocniczego, gdzie oczekiwane zachowanie wynika wprost z implementacji.

To samo dotyczy przeglądu zgłoszeń. Narzędzie dobrze wyłapuje pominiętą obsługę błędu, brakującą walidację, zapytanie w pętli i literówkę w warunku. Nie oceni natomiast, czy w ogóle należało to zbudować i czy rozwiązanie pasuje do reszty systemu, a to są pytania, na które odpowiada recenzent znający projekt.

Qodo kontra alternatywy

Pierwsze kryterium to możliwość wdrożenia u siebie. Jeśli kod nie może opuścić infrastruktury firmy, otwarty rdzeń jest tu przewagą, której konkurencja zwykle nie oferuje.

Drugie to zakres kontekstu. Przegląd oparty na samej różnicy widzi zmianę, ale nie widzi, że zmieniona funkcja jest wywoływana w siedmiu innych miejscach. Narzędzia budujące model całego repozytorium radzą sobie z tym lepiej i to bywa różnica decydująca przy dużym projekcie.

Trzecie, najbardziej praktyczne: co już masz. Jeśli zespół płaci za pakiet zawierający przegląd, dokładanie drugiego narzędzia wymaga wykazania różnicy, a nie samego stwierdzenia, że jest lepsze.

Jak wprowadzić to w zespole

Narzędzie komentujące cudzą pracę wymaga ostrożniejszego wprowadzenia niż zwykła zależność, bo dotyka sposobu, w jaki ludzie ze sobą pracują.

Zacznij od jednego repozytorium i od trybu, w którym przegląd uruchamia się na żądanie, a nie automatycznie przy każdym zgłoszeniu. Przez dwa tygodnie zobaczysz, ile uwag jest trafnych, a ile to szum, i dopiero wtedy warto rozstrzygać o włączeniu automatu.

Ustal jasno, że uwagi narzędzia nie są poleceniami. Autor zgłoszenia decyduje, co przyjąć, i nie musi się tłumaczyć z pominięcia sugestii. Bez tego ustalenia przegląd automatyczny zamienia się w źródło niepotrzebnych sporów, a zespół zaczyna pisać kod pod narzędzie zamiast pod czytelność.

Skonfiguruj też, czego narzędzie ma nie robić. Uwagi o formatowaniu są zbędne, jeśli masz automatyczne formatowanie, a uwagi o stylu nazewnictwa mają sens tylko wtedy, gdy zespół ma spisaną konwencję. Wyłączenie kategorii, których i tak nie zamierzacie stosować, podnosi jakość reszty.

Mierz jedną rzecz: ile uwag zostało przyjętych. Jeśli po miesiącu przyjmowane jest kilka procent, konfiguracja wymaga zawężenia albo narzędzie nie pasuje do tego projektu. To prostsza miara niż jakakolwiek ankieta wśród zespołu, trudniej ją zmanipulować i widać ją wprost w historii zgłoszeń.

Co taki przegląd wyłapuje, a czego nie

Warto rozłożyć to na konkretne kategorie, bo od tego zależy, czego można się po narzędziu spodziewać i jak ustawić oczekiwania zespołu.

Dobrze wypada przy błędach lokalnych, widocznych w obrębie jednej zmiany. Pominięta obsługa wartości pustej, brak sprawdzenia zakresu, warunek odwrócony przez literówkę, zasób otwarty i niezamknięty, wyjątek połknięty pustym blokiem. To są rzeczy, które człowiek też wyłapuje, tylko rzadziej, bo czyta trzynasty przegląd tego dnia.

Nieźle wypada przy typowych pułapkach wydajnościowych, o ile widać je w zmienionym fragmencie. Zapytanie wewnątrz pętli, pobranie całej tabeli do pamięci, brak indeksu na kolumnie użytej do filtrowania w dodanym zapytaniu.

Słabo wypada wszędzie tam, gdzie potrzebna jest wiedza o systemie. Nie wie, że zmieniona funkcja ma trzech innych wywołujących o odmiennych założeniach. Nie wie, że pole, które właśnie usuwasz, jest odczytywane przez zadanie uruchamiane raz w miesiącu. Nie wie, że ten moduł jest planowany do usunięcia w przyszłym kwartale, więc ulepszanie go jest stratą czasu.

Nie wypada wcale przy pytaniach, które w przeglądzie ważą najwięcej: czy to rozwiązuje właściwy problem, czy pasuje do reszty architektury i czy nie da się tego zrobić prościej. Te pytania zadaje osoba znająca projekt i żadne narzędzie tego nie zastąpi.

Uczciwy wniosek brzmi tak: automat przejmuje warstwę mechaniczną, która zajmowała recenzentowi połowę uwagi, i dzięki temu zostaje mu ta uwaga na rzeczy, których automat nie ruszy. To jest realna wartość i zupełnie inna niż obietnica zastąpienia przeglądu.

Typowe błędy

Pierwszy to planowanie wdrożenia wokół planu darmowego, którego w wariancie zarządzanym nie ma. Do dyspozycji jest czternastodniowy okres próbny, a po nim trzeba wybrać plan płatny.

Drugi to kupowanie paczki kredytów z dużym zapasem. Niewykorzystana część przepada na koniec cyklu, a przekroczenie puli i tak kosztuje tyle samo za kredyt, więc zapas nie kupuje niczego poza wyższą fakturą.

Trzeci to generowanie testów dla logiki biznesowej. Test wygenerowany z kodu utrwala jego błędy jako oczekiwane zachowanie.

Czwarty to traktowanie przeglądu automatycznego jako zastępstwa dla ludzkiego. Narzędzie nie oceni, czy rozwiązanie pasuje do reszty systemu, ani czy w ogóle należało je budować w tej postaci.

Piąty to wysyłanie ogromnych zgłoszeń scalenia. Kosztują wyraźnie więcej w przeglądzie automatycznym i wypadają gorzej w ludzkim, więc podział na mniejsze opłaca się podwójnie.

Szósty to wdrożenie u siebie bez policzenia kosztu utrzymania. Przy małym zespole ta praca kosztuje więcej niż abonament, a dochodzi do niej obsługa aktualizacji i zdarzeń z repozytorium.

FAQ

Czy Qodo jest darmowe?

Wariant zarządzany nie ma stałego planu darmowego. Dostajesz czternastodniowy okres próbny bez karty, a potem płacisz za kredyty, licząc od 30 USD miesięcznie za paczkę 2500 kredytów. Bezpłatny dostęp mają zakwalifikowane projekty otwarte. Silnik przeglądający zgłoszenia jest też dostępny na licencji swobodnej do uruchomienia u siebie, wtedy płacisz wyłącznie za wywołania modelu.

Czym to się różni od dawnego CodiumAI?

To ten sam projekt po zmianie nazwy, przeprowadzonej pod koniec 2024 roku. Starsze materiały i część odnośników nadal używają dawnej nazwy, co bywa mylące przy szukaniu dokumentacji.

Czy wygenerowane testy można zaakceptować bez czytania?

Nie. Test wygenerowany z kodu sprawdza, że kod robi to, co robi, a nie że robi to, co powinien. Do logiki biznesowej pisz testy sam, wychodząc od wymagań, a generowania używaj do przypadków brzegowych wokół już poprawnej logiki.

Czy zastąpi przegląd wykonywany przez człowieka?

Nie, i nie do tego służy. Dobrze wyłapuje pominiętą obsługę błędów, brakującą walidację i typowe pułapki wydajnościowe, natomiast nie oceni, czy rozwiązanie pasuje do architektury systemu. Najlepiej sprawdza się jako pierwsze przejście przed przeglądem ludzkim.

Czy mogę uruchomić to u siebie?

Tak, otwarty silnik przeglądu uruchamia się w kontenerze z własnymi kluczami do modelu. Pamiętaj tylko, że to projekt utrzymywany przez społeczność, oddzielony od płatnej oferty, więc nie dostaniesz w nim tych samych funkcji co w wariancie zarządzanym. Policz też koszt utrzymania, bo przy małym zespole bywa wyższy niż abonament, a przy dużym proporcja się odwraca.

Dokumentacja stoi na stronie projektu, a kod otwartej części w repozytorium na GitHubie.